oracle / graal

GraalVM compiles Java applications into native executables that start instantly, scale fast, and use fewer compute resources 🚀
https://www.graalvm.org
Other
20.38k stars 1.64k forks source link

Future proposal: have "javac" directly support graalvm + (static) native image creation #8940

Closed rubyFeedback closed 5 months ago

rubyFeedback commented 5 months ago

This is a feature request. It is not related to a problem. (I am just going through the default template right now.)

I am usually writing ruby code, but since a few years I also write in Java, though I still consider myself to be a semi-noob in Java. Today I ported a commandline tool I wrote in ruby, into java. I even managed to download the content of a HTML page and stored it into a String, in java. \o/

Next thing I did was to capture information from the webpage, such as the title and so forth. It is for NCBI's taxonomy database (e. g. the thing they have to store ids, matching to species, such as ID 9606 representing humans https://www.ncbi.nlm.nih.gov/Taxonomy/Browser/wwwtax.cgi?mode=Undef&name=Homo+sapiens&lvl=0&srchmode=1&keep=1&unlock and so forth).

As I am just about to be done with that class in Java (https://i.imgur.com/SSDbOcE.png - it really is super-simple, proof of concept to extend this for the commandline, and also for use in a webpage eventually; I like to solve both in one, e. g. commandline stuff and display on the web); my next goal is to finish the java variant. And then, the next logical step would be to turn that into a standalone binary (for java), which I hope will be faster than ruby. Then next step is to use graalvm and ideally a statically compiled variant (at the least on linux; while I try to write portable code, including windows, I am fine having things work on linux first and foremost).

So, I know how to turn the binary into a graalvm binary; usually I use a helper class in ruby that runs "javac -d" and so forth for me, properly. So this part is fine for me personally - all works well. I can automate the whole procedure already.

I had a look at the javac --help output and I could not find any entry related to graalvm or static binaries. I assume this may be because graalvm is not an "official" part of java/javac.

Then I thought ... "wouldn't it be great if javac directly supports the creation of such a binary?"

For instance via:

javac -d . ParseTaxonomy.java --compile-statically
javac -d . ParseTaxonomy.java --statically
javac -d . ParseTaxonomy.java --static

I am just giving some examples for the commandline; of course other ways to invoke it could be used.

My point is more about ... why does javac not support creation of native images that are statically compiled?

So, the answer may be "because this is not the job of javac, but of graalvm". Ok, this I can understand .. but would it not be more CONVENIENT if javac would support that?

I am not saying it should be supported by default for ALL java installations or java devkits. I am saying that, IF graalvm is available on the target computer (perhaps checking for native-image or some other binary on that computer), THEN it would be nice if javac, as well as javac --help, would show more convenience options; perhaps a new section near the end, starting with:

These are the options for graalvm:

--static
--awesome # well, the name does not matter, just that we are listing more options here

And so on and so forth. The idea here is that users could use javac directly, quickly, via a simple flag, rather than having to use native-image or some other binary, for creating this.

Now, you may also say "this should be filed at oracle instead for java/javac", but I feel that it would probably have 0% chance of being supported there, whereas here the chance may be at 2%. :D

It's also ok to have this as some long distance goal, mind you. I remember that only just recently, I think graalvm and openjdk (or something?) sync releases and changes more consistently now. So perhaps we could have ALL of java (or at the least as much as makes sense), together, and make features that work, available for all of the java ecosystems out there, rather than fragment it. (I also understand that, most likely, for solid support into javac, graalvm's support for native images needs to work better, possibly on windows, so it is ok if this is a distant goal - I just wanted to suggest it, perhaps nobody thought about it so far.)

Anyway - this is not a good issue request as it may involve too many different people, so it is ok to close it. It would be nice if someone from the graalvm dev pool could comment his or her thoughts on this before closing this, though, so that we know how likely or unlikely this may be to see implemented one day. Thanks for reading!

PS: I also means this in regards to the polyglot functionality, e. g. say you'd have a .py file and a .java file that inter-relate to one another, and then a simple "javac" --flag that would easy peasy lemon squeezy support the creation of a new binary, but without having to call native-image with tons of flags to make it work. So another part of this suggestion to have this all be SIMPLE for the user; I can work around via ruby + flags I send to system() (Kernel.system()) so for me the problem is solved, sort of - but a simple flag would still be nice to have, in particular on windows, where things are a bit more annoying than on Linux (in my opinion at the least).

PSS: Or, javac could show extended options that then include graalvm too, via "javac --extend-help" or something like that.

sgammon commented 5 months ago

Relevant material: There is Project Galahad which involves upstreaming certain GraalVM features into OpenJDK.

selhagani commented 5 months ago

Thank you for your detailed feature request and for sharing your experiences and ideas.

After careful consideration, we have decided not to implement the proposed integration of GraalVM options directly into javac. While we understand the convenience this might offer, we believe that the benefits to our broader user base would be limited at this time.

We appreciate your enthusiasm for improving the Java development experience and your thoughtful suggestions.