Would it be fair to conclude that for the next couple of months it would
make sense to keep master in "8+9" state, while gradually explore the
real need to introduce the new master (Java 9 only)? I would be curious
to see how RxJava2 and/or Reactor would provide the integration with Java 9
Flow API (https://github.com/ReactiveX/RxJava/wiki/Reactive-Streams) ...

   "The plan is to also support Java 9 j.u.c.Flow types by leveraging new Java
   multi-versioned jars to support this when using RxJava 2.x in Java 9 while
   still working on Java 8."

I have heard that multi-versioned jars are **not** straigthfoward, but perhaps
better than keeping two masters.

DK> I’d much rather keep master a “8+9” type of thing for a while.    I don’t 
see ANYONE moving to Java 9 for production stuff any time soon.

DK> That said, at some point soon, I’d like to make master more “Java 9 
Friendly” and hopefully release a 3.3 at some
DK> point in the future that supports java8, but may be more friendly for 
Java9.    Not 100% sure what that would
DK> entail, but I would definitely be open to the idea of releases being done 
with Java9 that would allow additional modules for Java9 users.

DK> It’s kind of similar to how we moved from JAX-WS 2.1 to 2.2.    Until we 
went Java7 only, we had a separate profile
DK> that added additional src directories and such for JAX-WS 2.2.   On Java 
5/6, we had to do JAX-WS 2.1 so the code in
DK> the normal src/main/java directories was all Java5/6 with JAX-WS 2.1.   
However, we had a separate src/man/jaxws22
DK> source directory that contained the additional classes and such that were 
needed for JAX-WS 2.2.   At release time,
DK> we had to make sure we used the appropriate JDK/Profile to get that 
included.   

DK> Now, what does “Java 9 Friendly” entail?   Not really sure.  Off the top of 
my head, I would definitely start by
DK> including dependencies for all the javax.* API’s.   Example, core depends 
on JAXB so add the jaxb-api jar.    This
DK> would definitely reduce the amount of “patch-module” things that are needed 
to use CXF on Java9.   However, it’s not
DK> something to do on 3.2.x as it adds a ton of dependencies that users may 
need/want to exclude so not a “patch”
DK> thing.    As part of this, we’d also update to as many dependencies that 
are module friendly as possible.      We
DK> could also have additional source dirs or similar to the tree for Java 9 
“cool things”, providing we can still
DK> compile with —target=1.8.    Another example could possibly be an update to 
the http client transport to use the
DK> Java9 HttpClient.   If run on Java8, we’d stick with URLConnection, on 
Java9, use HttpClient. 

DK> I know Java9 supports the “Multi-Release JAR”, but I’m not sure if Maven 
can handle/generate those yet.   Something else to look into.

DK> Dan




>> On Nov 15, 2017, at 6:47 AM, Sergey Beryozkin <[email protected]> wrote:
>> 
>> Hi
>> 
>> Should we open a new Java 9 only master soon enough ?
>> 
>> Thanks, Sergey


Reply via email to