Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Initial Spike to support JDK 9 #1994
I do not believe so. What todays experiments have shown me leads me to think that there is no way that a warnings == fatal project can have a source base that compiles cleanly under both JDK 8 & 9. It seems that the javac compiler is much more strongly-conforming in 9 than 8.
OK, here's a breakdown of what's in the PR, so you know which bits you might want:
.gitignore - just ignore vi swap files : SAFE for both 8 & 9
I know this isn't a great story for you, but please consider how you might support 9 going forwards. Vavr is a great project, and as it has so few dependencies, it could be made into a set of explicit modules, which would be great to see. Thanks for all the work so far!
thank you for the PR. It is great to see a JCP member here!
So far, I haven't found a reason to bump Vavr's binary code to the upcoming Java version. JDK9 doesn't offer any features that will enhance our API. If we would use modules under the hood, we would just ensure that we expose the right things to the outside. Currently we use workarounds for that purpose, like auxiliary classes and package private classes (I know, even if they are not part of the contract, they are currently discoverable via reflection).
However, it is important that Java 9 applications are able to use the Vavr binaries compiled with Java 8. This is one thing that has to be investigated. I haven't found the time to get my hands on Java 9, yet (besides jshell - I love it).
Thank you also for your summary. One thing I don't like to see is that GWT will not be able any more to find the package-private
It really surprises me that
Is it the exhaustiveness you address? Could you please elaborate on this?
Did you already filed a bug on Oracles bug-tracker?
I think I have to dive deeper into Java 9 in order to understand what went wrong with Lazy and Match. Your investigation makes perfectly sense. We will see how we can benefit from Java modules. At the latest we will jump to the next binary version with Java 10, there are a lot of interesting features we are waiting for.
Hi Daniel - thanks for the comments on the PR. We are making progress on this - including having collaborated to help get a version of maven-compiler-plugin (I think it will be 3.6.2) that works with 9. Currently, having problems with maven-bundle-plugin. The problem seems to be in bndtools - and some folk from the OSGi community are helping us look at the issue.
I think the current issue we're facing is related to this thread - #1225 - is there a workaround that doesn't involve using the maven-bundle-plugin ? - as apparently it will be a while before it gets updated to handle JDK 9.
I started a thread about this here: https://groups.google.com/forum/#!forum/bndtools-users - maybe you could come & join?
Will respond to the API and other points in a separate comment - getting the build working is my top priority because of the time-sensitivity.
Just to follow up on this:
There are now fixes in place for maven-compiler-plugin and BndTools that have progressed the build. However, the test cases are still failing to compile. The issue appears to be within Vavr itself, to do with the generated test cases.
As I'm not too familiar with the source generation that Vavr does yet - if someone has some cycles to help me look at this, it would be greatly appreciated.
@kittylyst thank you for all your effort! Currently I'm on vacation (until end of June). Then I will help you on this issue. Currently I have to catch up with all the pending comments and pull requests...
I have some questions:
However, I think I need to get my hands dirty in order to understand the impact :)
Good job, though I would definitely separate it into multiple pull requests, as it obviously cannot be merged in this way (e.g. it's not Java 8 compatible).