As with everything, the final 10% is 90% of the work.
Hey, you know a feature which I would love to see (and maybe it's already in there) -- would be the ability to "orchestrate" Java code. In other words, to be able to add external event hooks from functions/procedures/methods -- at runtime...
These event hooks, when encountered, would be able to do such things as:
* Print/pipe a debug message to an external program or log or log viewer;
* The debug printer should contain the function/procedure/method name, parameter names, and parameter values automatically (there should be functionality to have them in both the invocation and after the function/procedure/method's code is complete, prior to returning to the caller, so two possible places per function/procedure/method...);
* The ability to selectively turn on/off such events at runtime;
* The ability to add additional code which could be evaluated for every such event (also at runtime), and make the determination if the event should be processed or skipped;
* The ability to do all of the above programmatically, via API...
* Some sort of GUI which automatically imports all function/procedure/method names of a running Java program at runtime, then gives the user the ability to track/log whichever ones they want, by simply selecting them to a secondary listbox of tracked function/procedure/methods...
Now, maybe some or all of that -- is already baked in there. I didn't look at the codebase long enough to know...
But if it is in there, that's awesome! And if one or more of those features are missing, then maybe a future version maintainer or forked version maintainer might be persuaded to add them in there...
(Side note: It would be nice to have the above functionality for all programming languages!)
Anyway, as said previously, looks very cool!
I tried to run a Java 11 jar on my M1 Mac with $JAVA_HOME pointed at a temurin-11.0.20 JVM but no such luck:
$ ./jacobin -jar my.jar
Class Format Error: Class has two package names: apple/security and com/sun/crypto/provider
detected by file: cpParser.go, line: 241
ParseAndPostClass: error parsing classes/module-info.class. Exiting.
Class Format Error: Invalid access flags of MethodParameters attribute #1 in main
detected by file: methodParser.go, line: 333
Class Format Error:
detected by file: methodParser.go, line: 109
ParseAndPostClass: error parsing my.Main. Exiting.Nonetheless, if you'd be kind enough to post the above error and the class you used into the GitHub Issues tracker [0], we'll definitely include it in our test suite and make sure whatever the problem is, it'll be corrected.
> This code will not result in an error message. This surprising feature is used primarily by code generators, which might create an array and then discover there are no values to place in it.
What? How can someone at Oracle have written this?
Zero-length arrays are used all the time when you call a function asking for an array of "the latest stuff" and it needs to be an array, not an ArrayList say (maybe it's an array of bytes). If there's no stuff, you get a zero-length array of course. The myriad foo.toArray(...) functions in Java's library do this for example.
I must've read this sentence at least 7 times, but don't understand what this means. Can anyone illuminate?
“For example,
strangePoints = new int[3][4][0][2]
In this declaration, all dimensions after the zero-size dimension are ignored. So, the result of this declaration is equivalent to a two-dimensional array of ints.
”This is just plain wrong. It’s a four-dimensional array of ints, just one that cannot contain more than zero ints, because one of the dimensions is zero.
To illustrate,
int[][] a = strangePoints[0][0];
will typecheck while int b = strangePoints[0][0];
will not (which however it should if the author’s claim that strangePoints is a two-dimensional array of ints was true).The talk about Object having no size() method and arrays having therefore a length field is also confused. Arrays have distinct types (and classes, in the sense of getClass()), and therefore could very well have a size() method. It’s merely a stylistic choice of Java that they opted for the simpler .length syntax.
The article is so misguided as to be harmful.
> Object having no size() method and arrays having therefore a length field is also confused. Arrays have distinct types (and classes, in the sense of getClass()), and therefore could very well have a size() method. It’s merely a stylistic choice of Java that they opted for the simpler .length syntax.
What's the "confused" part? Again, my description is accurate and you're simply saying that Java could have chosen a different way to do the same thing, but decided not to.
[0] https://docs.oracle.com/javase/specs/jvms/se16/html/jvms-6.h...
[0] jacobin.org