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

Java 11 support #651

Closed
xbotuk opened this issue Sep 3, 2018 · 29 comments
Closed

Java 11 support #651

xbotuk opened this issue Sep 3, 2018 · 29 comments
Assignees

Comments

@xbotuk
Copy link

@xbotuk xbotuk commented Sep 3, 2018

As Java 8-10 will be obsolete very soon, GraalVM should support Java 11 also.

@dougxc

This comment has been minimized.

Copy link
Member

@dougxc dougxc commented Sep 3, 2018

We're working on this and aim to have it ready by the end of the year.

@renannprado

This comment has been minimized.

Copy link

@renannprado renannprado commented Sep 25, 2018

@dougxc awesome news!

@Kindrat

This comment has been minimized.

Copy link

@Kindrat Kindrat commented Dec 7, 2018

Any news, guys?

@dougxc

This comment has been minimized.

Copy link
Member

@dougxc dougxc commented Dec 7, 2018

We're continuing to make progress but it looks like it won't be ready as soon as I predicted.

@Kindrat

This comment has been minimized.

Copy link

@Kindrat Kindrat commented Dec 7, 2018

Any ETA? Just for not to ping you too often.

@dougxc

This comment has been minimized.

Copy link
Member

@dougxc dougxc commented Dec 7, 2018

It's really hard to say but I think end of Feb 2019 is a safe bet.

@JAremko

This comment has been minimized.

Copy link

@JAremko JAremko commented Dec 9, 2018

Java 11 seems really interesting for native-images since it has Epsilon GC that can be great option for short-lived CLI tools 🙀

@olpaw

This comment has been minimized.

Copy link
Member

@olpaw olpaw commented Dec 10, 2018

@JAremko unfortunately that's not how it works. Epsilon GC is a JVM component that cannot be built into a native-image. All native images contain a special SVM GC implementation that's entirely written in Java (necessary requirement to bake it into a native image). //CC @Peter-B-Kessler

@JAremko

This comment has been minimized.

Copy link

@JAremko JAremko commented Dec 10, 2018

@olpaw What a pity. 😞
But thank you for clearing that up. ❤️

@mageddo

This comment has been minimized.

Copy link

@mageddo mageddo commented Dec 12, 2018

Are you working only for java 11 support or java 12 it's also included for that release?

@christianwimmer

This comment has been minimized.

Copy link
Member

@christianwimmer christianwimmer commented Dec 13, 2018

We will support 11 and 12, and all future versions. There are only minor differences between 11 and 12, so that will not be much work.

@kaspernielsen

This comment has been minimized.

Copy link

@kaspernielsen kaspernielsen commented Dec 13, 2018

What kind of support will there be for MethodHandles? direct method handlers only, or some way to store predefined non-direct method handles as well?

@abcfy2

This comment has been minimized.

Copy link

@abcfy2 abcfy2 commented Jan 12, 2019

Any roadmap for this issue? Which version will support Java 11?
Thanks.

@dougxc

This comment has been minimized.

Copy link
Member

@dougxc dougxc commented Jan 12, 2019

There are a number of moving pieces in getting Java 11 support completed. This is work is being performed in parallel with continued development on Java 8. We want to get it out there as much as anyone else but it's just too hard to predict when it will be ready (as shown by my failed earlier attempt to do so). That said, we will not be shy about it when it is ready!

@lkwg82

This comment has been minimized.

Copy link

@lkwg82 lkwg82 commented Jan 12, 2019

The question is, can you be transparent about how close you are?

@mikx

This comment has been minimized.

Copy link

@mikx mikx commented Feb 26, 2019

Any update on this? Thanks!

@trnl

This comment has been minimized.

Copy link

@trnl trnl commented Mar 12, 2019

Grateful if you can provide any ETA, at least in QQQs for 2019.

@bobmcwhirter

This comment has been minimized.

Copy link
Contributor

@bobmcwhirter bobmcwhirter commented Apr 3, 2019

@dougxc any branch or place we can experiment with the JDK11+ support, and contribute to help things along?

@dougxc

This comment has been minimized.

Copy link
Member

@dougxc dougxc commented Apr 3, 2019

There's no active branch of development apart from what's here on GitHub.

These are some of the larger pieces no one has spent time on yet:

  • Implement Truffle and Graal isolation from the application in terms of module access control instead of class loaders. That is, use modules to do what we currently do with the JVMCI class loader (i.e. -XX:+UseJVMCIClassLoader).
  • Modify the JDK 11 build system to build the jdk.internal.vm.compiler and jdk.internal.vm.compiler.management modules from GitHub Graal sources. This will be based on the updategraalinopenjdk script. In addition, the Truffle and GraalSDK modules also need to be added to the build.
  • Figure out how to implement the graal-updater. It needs to add "components" to the GraalVM by modifying a JDK in-place. On JDK8 we do that with trusted directories (like the jre/ext mechanism). In JDK11+, there are at least these 2 possibilities:
    • Reproduce the JDK8 model and add trusted directories by programmatically loading modules and adding exports etc.
    • Use jlink to modify the JDK to add new modules and exports. I'm not sure this is possible given my rudimentary understanding of jlink where I believe it's primarily for deriving a new JDK image from an existing JDK image.

As stated, we will work on these as our focus shifts from 8 to 11 (or 13). Until then, contributions towards any of these tasks is very welcome.

@christianwimmer

This comment has been minimized.

Copy link
Member

@christianwimmer christianwimmer commented Apr 4, 2019

The current status for Native Image generation on JDK 11 is "something in the middle": you can build the source tree and build non-trivial native images with JDK 11. However, new Java APIs added after JDK 8 are only supported on a basic level. For example, we "support" the module system by always just returning the same singleton Module instance when you ask a class for its module.

As Doug said, all our our JDK 11 work is merged in master, there is no work that we have internally but not pushed out yet. Our current focus is more on stabilizing the JDK 8 support, but we welcome any external contributions that improve JDK 11 support.

@SchulteMarkus

This comment has been minimized.

Copy link

@SchulteMarkus SchulteMarkus commented Apr 4, 2019

Thanks for updates, @dougxc and @christianwimmer

@Azbesciak

This comment has been minimized.

Copy link

@Azbesciak Azbesciak commented Jul 6, 2019

Any update?

@pquiring

This comment has been minimized.

Copy link

@pquiring pquiring commented Jul 27, 2019

In the mx build script for substratevm you can see references to JDK 11,13 and 14.
https://github.com/oracle/graal/blob/master/substratevm/mx.substratevm/mx_substratevm.py#L169
Not sure why JDK12 is not listed there so I added it to try and compile it, but still get other errors under Windows.
I would suspect that after JDK-13 is released we would see an updated version of GraalVM that targets it.

@pquiring

This comment has been minimized.

Copy link

@pquiring pquiring commented Sep 20, 2019

19.3 will support Java 11 to be released in Oct.

https://www.infoworld.com/article/3439839/oracle-pits-graalvm-against-google-go.html

@cemo

This comment has been minimized.

Copy link

@cemo cemo commented Sep 20, 2019

How about JDK13?

@thomaswue

This comment has been minimized.

Copy link
Member

@thomaswue thomaswue commented Sep 20, 2019

The article is off by 1 month, because 19.3 is scheduled for release on Nov-19 as shown at https://www.graalvm.org/docs/release-notes/version-roadmap/

We are discussing the possibility of also releasing a JDK-latest version (which would be JDK13 currently) in parallel, but it is unlikely to happen before early next year.

@matteobertozzi

This comment has been minimized.

Copy link

@matteobertozzi matteobertozzi commented Sep 21, 2019

we had to go back from jdk11 to jdk8, because when using nashorn we discovered a memory leak (which is not fixed yet) https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8229011

I'll give it a try to see if graal.js and jdk11 suffer of the same problem

@thomaswue

This comment has been minimized.

Copy link
Member

@thomaswue thomaswue commented Sep 21, 2019

Graal.js does not dynamically generate bytecodes, so it is highly unlikely that it would be affected by this. In any case, let us know if it indeed is.

@cemo

This comment has been minimized.

Copy link

@cemo cemo commented Nov 20, 2019

This can be closed @thomaswue :) Congrats!

PS: Is there a benchmark results?

@boris-spas boris-spas closed this Jan 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.