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
Initial Spike to support JDK 9 #1994
Conversation
Reimplemented Collections.scan methods
Moved not-null check to some helper methods, ordered methods by name
Updated pom version to 2.1.0
…hods) on my local machine
Moved javaslang gwt
Expand TupleTest for Tuple7 and Tuple8
Add autogenerated Tuple narrow methods for issue #1663
General `Vector` speedup
Added Stream.concat() methods
introduces Ordered interface #1495
Implement Seq.shuffle()
If we compile this code, will it work with Java8? (i.e. backward compatible on bytecode level) |
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. |
Shouldn't then we keep our primary JDK version at 8, so that we can use it both in JRE8 and 9? I guess at least the bytecode compiled with JDK8 will be forward compatible with JDK9. Or am I wrong? |
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! |
Hi Ben, 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. |
Fixed Jigsaw args sent to maven compiler in the child POMs
Update pom.xml
Move sources to correct level
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. |
The 3.4.0-SNAPSHOT build will not fail on module-info.class files.
Use latest Bnd snapshot
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 :) |
pom.xml
Outdated
<jmh.version>1.18</jmh.version> | ||
<junit.version>4.12</junit.version> | ||
<gwt.version>2.8.0</gwt.version> | ||
<maven.build-helper.version>1.12</maven.build-helper.version> | ||
<maven.bundle.version>3.2.0</maven.bundle.version> | ||
<maven.bundle.version>3.3.0</maven.bundle.version> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you separate these in another PR - so that it stays Java 8 & 9 compatible - I'm sure that will be merged :)
This PR is important! Currently it is not priority 1 but it will flow into the master at some point... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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).
pom.xml
Outdated
@@ -87,8 +87,26 @@ Note: The maven build currently needs to be started from the vavr root dir | |||
<maven.exec.version>1.5.0</maven.exec.version> | |||
<maven.gwt.plugin>1.0-rc-6</maven.gwt.plugin> | |||
<scala.maven.version>3.2.2</scala.maven.version> | |||
<scala.version>2.11.7</scala.version> | |||
</properties> | |||
<scala.version>2.12.2</scala.version> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(code generation crashed otherwise anyway)
vavr/src/main/java/io/vavr/Lazy.java
Outdated
@@ -101,7 +101,7 @@ private Lazy(Supplier<? extends T> supplier) { | |||
*/ | |||
public static <T> Lazy<Seq<T>> sequence(Iterable<? extends Lazy<? extends T>> values) { | |||
Objects.requireNonNull(values, "values is null"); | |||
return Lazy.of(() -> Vector.ofAll(values).map(Lazy::get)); | |||
return Lazy.of(() -> Vector.ofAll(values).map(Lazy<? extends T>::get)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think this is a bug in both the JDK and in Idea, they report different things for every variation of the code
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An alternative suggestion that Idea accepts also:
@SuppressWarnings("Convert2MethodRef") // TODO fixme on Java 9
public static <T> Lazy<Seq<T>> sequence(Iterable<? extends Lazy<? extends T>> values) {
Objects.requireNonNull(values, "values is null");
return Lazy.of(() -> Vector.ofAll(values).map(v -> v.get()));
}
@@ -27,6 +27,7 @@ public static ClassAssert assertThat(Class<?> clazz) { | |||
this.clazz = clazz; | |||
} | |||
|
|||
@SuppressWarnings("deprecation") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
instead of this I would recommend using the new canAccess
method, something like:
public void isNotInstantiable() {
try {
Assertions.assertThat(clazz.getDeclaredConstructor().canAccess(null)).isFalse();
} catch (NoSuchMethodException e) {
throw new AssertionError("no default constructor found");
}
}
Edit: This isn't java 8 compatible, my mistake
assertThat(actual).isEqualTo("Some(1)::List(Some(2.0))"); | ||
} | ||
|
||
// @SuppressWarnings("UnnecessaryLocalVariable") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@danieldietrich, tomorrow is the release date of JDK 9, this commit solves most of the compile problems (I basically recreated everything to validate it, good job, guys (there are two commiters, apparently).
If you could fix these (it's weird generics magic that I didn't have the courage to understand), we could get on the Java 9 wave(r).
.gitignore
Outdated
@@ -29,3 +29,6 @@ hs_err_pid* | |||
|
|||
# -- Emacs | |||
.#* | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seems unrelated
pom.xml
Outdated
@@ -66,15 +66,15 @@ Note: The maven build currently needs to be started from the vavr root dir | |||
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> | |||
<assertj.core.version>3.6.2</assertj.core.version> | |||
<eclipse.lifecycle.mapping.version>1.0.0</eclipse.lifecycle.mapping.version> | |||
<java.version>1.8</java.version> | |||
<java.version>9</java.version> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It won't be merged this way, since it has to be Java 8 compatible also.
vavr/src/main/java/module-info.java
Outdated
@@ -0,0 +1,7 @@ | |||
module io.vavr { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this still Java 8 compatible?
@danieldietrich do we need a separate, modularized Java 9 release also?
pom.xml
Outdated
<maven.clean.version>3.0.0</maven.clean.version> | ||
<maven.install.version>2.5.2</maven.install.version> | ||
<maven.compiler.version>3.6.0</maven.compiler.version> | ||
<maven.compiler.version>3.6.2-SNAPSHOT</maven.compiler.version> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
3.7.0
is already available and it solves the compiler exception also
// public void shouldDecomposeListWithNonEmptyTail() { | ||
// final List<Option<Number>> intOptionList = List.of(Option.some(1), Option.some(2.0)); | ||
// final String actual = Match(intOptionList).of( | ||
// Case($Cons($Some($(1)), $Cons($Some($(2.0)), $())), (x, xs) -> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The following seems to work:
Case($Cons($Some($(1)), $Cons($Some($(2.0)), $())),
(Some<Number> x, List<Option<Number>> xs) -> x + "::" + xs)
pom.xml
Outdated
@@ -279,6 +297,13 @@ Note: The maven build currently needs to be started from the vavr root dir | |||
</goals> | |||
</execution> | |||
</executions> | |||
<dependencies> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why was this needed?
0e8e6a2
to
4d275ff
Compare
This patch is a first step to supporting Java 9. It fixes some compile errors that the tighter Java 9 compiler insists upon, and refactors classes into the module structure. More work is still needed though - so it may be better on a branch rather than mainline.