Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
rubyFeedback opened this issue May 17, 2024 · 2 comments
Labels

Comments

@rubyFeedback
Copy link

rubyFeedback commented May 17, 2024

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
Copy link

sgammon commented May 18, 2024

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

@selhagani
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants