Hi Jeff
Good to hear from you, thanks for the feedback :-).
I suppose there's some consensus that in the next few months the team
should probably spend more time with using Java 9 with CXF 3.2.x, and
really get a better appreciation of what Java 9 is and which tools are
available around (such as may be Maven Java 9 related as Dan indicated,
etc) as it's fair enough to say that some of us (incl. myself) are not
doing practical Java 9 at all at the moment...
Hopefully that will help, perhaps another round of discussions will
follow afterwards, we'll see.
Thanks, Sergey
On 17/11/17 03:42, Jeff Genender wrote:
On Nov 16, 2017, at 7:02 AM, Sergey Beryozkin <sberyoz...@gmail.com> wrote:
Indeed it will take a long time for a team with the limited resources to have
CXF embracing Java 9. Postponing the start of this long process for 2 years or
so and wait for the users to come in and say, when will CXF will do what
SpringBoot with Java 9 can do, is not strategically right move IMHO.
+1000!!!!
Have the Java 9 branch, let people spend as much time as needed to play there,
keep going with Java 8+9 in 3.2.1. I don't see where the conflict is
+1,000,000!!!
Jeff
Cheers. Sergey
On 16/11/17 13:53, Andriy Redko wrote:
Modules are really far away in the future (IMHO). As per my understanding, we
could think about real modules only when all our dependencies are modularized,
which would take quite a lot of time I suppose. The Reactive Streams part is
really appealing *BUT* even there we **could** keep the same master for 8 and 9
(http://openjdk.java.net/jeps/238).
Honestly, I am not 100% sure we have to branch off the new master and keep it
Java 9 only right now. May be the good moment will be when we discountinue
3.1.x so at least the code will be much easier to cherry-pick?
Best Regards,
Andriy Redko
CS> I am not sure sure about the need for Java 9 modules. Currently I see no
CS> user requesting this. It is also not yet fully clear how these modules
CS> behave in OSGi. As far as I understood as soon as we start with this we
CS> have code that is not working in Java 8. As we require every change to be
CS> done in master first this means we have a lot of back port work. A Java 9
CS> only master will also make it much harder for Java 8 users to supply pull
CS> requests as they have to develop and test on java 9 which is not their
CS> production system.
CS> So I think the current situation with a master that works on Java 9 and
CS> Java 8 is a pretty good situation that we should keep for as long as
CS> possible.
CS> I am not sure how attractive the other Java 9 features are. Personally I
CS> were really eager to adopt Java 8 because of the closures but I see no real
CS> need for myself to rush to java 9.
CS> When I remember how reluctant we were when it came to adopting the previous
CS> java versions like 7 and 8 as minimal requirement I think it makes sense to
CS> do this rather slowly.
CS> Christian
CS> 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
CS> --
