Yes, in a Java 9 only master it will be expected that it won't work with Java 9. I guess it's also about trying to anticipate what the users will ask. If someone prefers to avoid Java 9 only then they'd just stay for a long time with 3.2.x

Sergey
On 16/11/17 13:02, Christian Schneider wrote:
I am not sure sure about the need for Java 9 modules. Currently I see no
user requesting this. It is also not yet fully clear how these modules
behave in OSGi. As far as I understood as soon as we start with this we
have code that is not working in Java 8. As we require every change to be
done in master first this means we have a lot of back port work. A Java 9
only master will also make it much harder for Java 8 users to supply pull
requests as they have to develop and test on java 9 which is not their
production system.

So I think the current situation with a master that works on Java 9 and
Java 8 is a pretty good situation that we should keep for as long as
possible.
I am not sure how attractive the other Java 9 features are. Personally I
were really eager to adopt Java 8 because of the closures but I see no real
need for myself to rush to java 9.

When I remember how reluctant we were when it came to adopting the previous
java versions like 7 and 8 as minimal requirement I think it makes sense to
do this rather slowly.

Christian

2017-11-16 13:31 GMT+01:00 Sergey Beryozkin <sberyoz...@gmail.com>:

Hi Andriy

I'm only presuming that yes, a Java 9 only master would have to support
the new Java 9 modules system, so I'd say a lot of exciting work would
await for the CXF dev community :-)

Cheers, Sergey

On 16/11/17 12:19, Andriy Redko wrote:

Hey Sergey,

Do we have a goal to support Java 9 modules (aka Jigsaw) for
the new master branch? Or we just looking to benefit from the
latest changes in stardand library (as you mentioned, Flow & Co,
collections are also a good example)? Is our current master JDK9
compatible actually (haven't seen successfull builds from
https://builds.apache.org/job/CXF-Master-JDK9) ?

Best Regards,
      Andriy Redko

SB> It's pretty simple really. It's about having a new impetus for the CXF
SB> development.

SB> Without a Java 9 only master CXF will be about fixing the bugs only.
SB> JAX-WS is done long time ago, next version of JAX-RS will take N
amount
SB> of time to materialize.

SB> Java 9 with its Flow class will let CXF do new work around Reactive
SB> support. It will have new features that only work with Java 9 and may
SB> give new ideas for the contributions.

SB> 3.2.x is at the start of its life-cycle and will have a couple of
years
SB> at least for it to retire, giving Java 8 support.

SB> 3.1.x has probably 6 months or so left in it, and after it's gone we
SB> will have 3.2.x and 4.0.x or whatever new version is preferred.

SB> Sergey
SB> On 16/11/17 08:15, Dennis Kieselhorst wrote:

On 2017-11-16 07:27, Christian Schneider <ch...@die-schneider.net>
wrote:

I dont think we can already predict when users move to Java 9.
So creating a Java 9 only branch at this time means we have to
maintain two
main branches over a long time.

What is the rationale behind a Java 9 only branch compared to being
Java 9
and Java 8 compatible on master?


I also don't see a good reason to do that at the moment. Let's release
the XJC plugin and users should be able to use CXF with Java 9 or am I
missing something?

Cheers
Dennis





Reply via email to