Re: New Java 9 master

[Romain Manni-Bucau]

Ok, the behavior is a bit different with this flag or not transitively (a
named module will see these classes as belonging to a named module so using
them you looks SPI, RB etc... but not for their own usage) but it looks it
can work "good enough" short term.

Le 3 janv. 2018 22:42, "Andriy Redko"  a écrit :

Because it will be **always** named automatically, there is nothing we can
do about it. The only thing we can
do is to suggest the better name for automatic naming (which still keeps
module in unnamed category). I think the
good example may be a convincing argument towards go / no-go decision, will
try to find time to work on it this week.







RMB> Le 3 janv. 2018 18:28, "Andriy Redko"  a écrit :

RMB> As per my understading of the efforts required (I hope to be wrong
here), this is ideal but unrealistic for CXF. We either
RMB>  start build some foundation (following other projects), or embark on
transforming everything to named modules (and we will be
RMB>  affected by all our dependecies anyway, there is nothing we can do
about it). I see the first option doable, CXF won't
RMB>  able to embrace the migration at once untill all and every dependency
we use does the same. This might happen eventually
RMB>  but not any time soon for sure :-(




RMB> Why not keeping it unamed then? There are very few adherence on cxf
except in integrations, no?




 RMB>> This is my first point. Once named and fully migrated you hit both
issue: not default classloader and visibility
 RMB>> change. First is surely workaround-able but last impacts users so
better to let people migrate on java 9...only
 RMB>> once and not N times cause CXF didnt embrace it at once. This is my
big concern.

 RMB>> Le 3 janv. 2018 01:56, "Andriy Redko"  a écrit :

 RMB>> I don't think this is the case actually. If you use CXF as-is right
now in modular application, its components will
 RMB>>  be loaded as automatic modules, implicitly. The only step forward
we are taking is to hint JVM what the name of the
 RMB>>  automatic module should be (instead of relying on the automatic
conversions). Rules don't change, the presence
 RMB>>  of automatic module name in the manifest does not make the JAR a
named module, only module-info.java will do that
 RMB>>  (and this would be a large and risky change indeed). But the
presence of the better name would help us to do
 RMB>>  migration to module-info.java a bit more smoothly, since the module
name won't change but semantics of the module
 RMB>>  will (one by one they should become named modules).




  RMB>>> yep


  RMB>>> issue is exactly this one: automatic modules are a one way path,
you can't go back on manual modules since you
  RMB>>> exposed the world and would introduce a breaking change modifying
it.
  RMB>>> The other one I tried to mentionned is: what about all the cases
where CXF will be deployed on java 9 but not in
  RMB>>> the root classloader (tomcat to cite a random case) which doesnt
support the new SPI loading? You are broken :(


  RMB>>> Romain Manni-Bucau
  RMB>>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn

  RMB>>> 2018-01-02 14:54 GMT+01:00 Andriy Redko :

  RMB>>> I might be mistaken (sorry, haven't worked with Jigsaw closely
yet), but I think the service loader would work the same
  RMB>>>  way in case of named module and automaticaly named module. The
only differences would be contraints/rules/visibility: automaticaly
  RMB>>>  named module just implicitly open/export/import everything while
named module should be picky and precise.

RMB>RMB>>> Or the worst since you dont expose the "api" but all the
classes and breaks SPI since service loader loading is different in named
modules, no?



RMB>RMB>>> Le 31 déc. 2017 19:15, "Andriy Redko"  a
écrit :

RMB>RMB>>> I am not sure about plugin part, to be honest. I would
better craft the module-info.java by hand (but use
RMB>RMB>>>  the tooling, jdeps f.e., to get the initial list of
modules) and have it in the source tree for each module,
RMB>RMB>>>  so to keep the history, etc. That would be aligned with
Sergey's suggestion to have Java 9 master sometime
RMB>RMB>>>  in the future.

RMB>RMB>>>  But, by and large, you may be right and the plugin is the
viable option. Still, if 99% of the CXF dependencies are
RMB>RMB>>>  going to be automatic modules nonetheless, what it will buy
us? And looking into other projects, that seems to
RMB>RMB>>>  be the starting point for many. Anyway, I would prefer to
get it all and right now :-D but realistically, I see
RMB>RMB>>>  the automatic module name to be the less riskier approach
to begin with (just a manifest change), not necessarily
RMB>RMB>>>  the best one though.





RMB>RMB>>>  Best Regards,
RMB>RMB>>>  Andriy Redko



RMB>>RMB>>> Hmm, shout if I didn't get your comments properly and my
comment is obvious but I think 1 and 3 

Re: New Java 9 master

[Romain Manni-Bucau]

This is my first point. Once named and fully migrated you hit both issue:
not default classloader and visibility change. First is surely
workaround-able but last impacts users so better to let people migrate on
java 9...only once and not N times cause CXF didnt embrace it at once. This
is my big concern.

Le 3 janv. 2018 01:56, "Andriy Redko"  a écrit :

> I don't think this is the case actually. If you use CXF as-is right now in
> modular application, its components will
> be loaded as automatic modules, implicitly. The only step forward we are
> taking is to hint JVM what the name of the
> automatic module should be (instead of relying on the automatic
> conversions). Rules don't change, the presence
> of automatic module name in the manifest does not make the JAR a named
> module, only module-info.java will do that
> (and this would be a large and risky change indeed). But the presence of
> the better name would help us to do
> migration to module-info.java a bit more smoothly, since the module name
> won't change but semantics of the module
> will (one by one they should become named modules).
>
>
>
> RMB> yep
>
>
> RMB> issue is exactly this one: automatic modules are a one way path, you
> can't go back on manual modules since you
> RMB> exposed the world and would introduce a breaking change modifying it.
> RMB> The other one I tried to mentionned is: what about all the cases
> where CXF will be deployed on java 9 but not in
> RMB> the root classloader (tomcat to cite a random case) which doesnt
> support the new SPI loading? You are broken :(
>
>
> RMB> Romain Manni-Bucau
> RMB> @rmannibucau |  Blog | Old Blog | Github | LinkedIn
>
> RMB> 2018-01-02 14:54 GMT+01:00 Andriy Redko :
>
> RMB> I might be mistaken (sorry, haven't worked with Jigsaw closely yet),
> but I think the service loader would work the same
> RMB>  way in case of named module and automaticaly named module. The only
> differences would be contraints/rules/visibility: automaticaly
> RMB>  named module just implicitly open/export/import everything while
> named module should be picky and precise.
>
>  RMB>> Or the worst since you dont expose the "api" but all the classes
> and breaks SPI since service loader loading is different in named modules,
> no?
>
>
>
>  RMB>> Le 31 déc. 2017 19:15, "Andriy Redko"  a écrit :
>
>  RMB>> I am not sure about plugin part, to be honest. I would better craft
> the module-info.java by hand (but use
>  RMB>>  the tooling, jdeps f.e., to get the initial list of modules) and
> have it in the source tree for each module,
>  RMB>>  so to keep the history, etc. That would be aligned with Sergey's
> suggestion to have Java 9 master sometime
>  RMB>>  in the future.
>
>  RMB>>  But, by and large, you may be right and the plugin is the viable
> option. Still, if 99% of the CXF dependencies are
>  RMB>>  going to be automatic modules nonetheless, what it will buy us?
> And looking into other projects, that seems to
>  RMB>>  be the starting point for many. Anyway, I would prefer to get it
> all and right now :-D but realistically, I see
>  RMB>>  the automatic module name to be the less riskier approach to begin
> with (just a manifest change), not necessarily
>  RMB>>  the best one though.
>
>
>
>
>
>  RMB>>  Best Regards,
>  RMB>>  Andriy Redko
>
>
>
>   RMB>>> Hmm, shout if I didn't get your comments properly and my comment
> is obvious but I think 1 and 3 are fine - that's
>   RMB>>> why I proposed them - because you can create the module-info.java
> with java 8. This is what does the plugin I
>   RMB>>> mentionned, writing it directly with java 9 (long story short it
> has a module-info parser and writer).
>
>
>   RMB>>> Romain Manni-Bucau
>   RMB>>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn
>
>   RMB>>> 2017-12-31 16:58 GMT+01:00 Andriy Redko :
>
>   RMB>>> Hi Romain,
>
>   RMB>>>  I think there are 2 parts regarding modules: 1) using CXF from
> modularized
>   RMB>>>  applications and 2) release/redesign CXF in a modular fashion (I
> mean Java 9 modules).
>   RMB>>>  The 2nd part is where we are heading eventually but we won't be
> trully modular till
>   RMB>>>  all our dependencies are available as modules as well. The idea
> of adding
>   RMB>>>  automatic module name is helping out with the 1st part.
> Regarding your questions
>   RMB>>>  though:
>
>   RMB>>>  1. Adding module-info.java would mean, at least, to branch the
> artifacts (java9+ / java8).
>   RMB>>>  2. Yes, I think it makes sense, this is the recommended way, but
> we should better make a
>   RMB>>>  proposal first (as part of the JIRA Dennis created).
>   RMB>>>  3. I think this is the only way (as module-info.java won't
> compile with Java 8)
>
>   RMB>>>  Automatic modules is a good start (arguably, for sure), because
> from the efforts
>   RMB>>>  perspetive, it looks doable in a short time vs adding proper
> module-info.java to
>   RMB>>>  each 

Re: New Java 9 master

[Andriy Redko]

I might be mistaken (sorry, haven't worked with Jigsaw closely yet), but I 
think the service loader would work the same 
way in case of named module and automaticaly named module. The only differences 
would be contraints/rules/visibility: automaticaly 
named module just implicitly open/export/import everything while named module 
should be picky and precise. 

RMB> Or the worst since you dont expose the "api" but all the classes and 
breaks SPI since service loader loading is different in named modules, no?



RMB> Le 31 déc. 2017 19:15, "Andriy Redko"  a écrit :

RMB> I am not sure about plugin part, to be honest. I would better craft the 
module-info.java by hand (but use
RMB>  the tooling, jdeps f.e., to get the initial list of modules) and have it 
in the source tree for each module,
RMB>  so to keep the history, etc. That would be aligned with Sergey's 
suggestion to have Java 9 master sometime
RMB>  in the future.

RMB>  But, by and large, you may be right and the plugin is the viable option. 
Still, if 99% of the CXF dependencies are
RMB>  going to be automatic modules nonetheless, what it will buy us? And 
looking into other projects, that seems to
RMB>  be the starting point for many. Anyway, I would prefer to get it all and 
right now :-D but realistically, I see
RMB>  the automatic module name to be the less riskier approach to begin with 
(just a manifest change), not necessarily
RMB>  the best one though.




RMB>  Best Regards,
RMB>  Andriy Redko



 RMB>> Hmm, shout if I didn't get your comments properly and my comment is 
obvious but I think 1 and 3 are fine - that's
 RMB>> why I proposed them - because you can create the module-info.java with 
java 8. This is what does the plugin I
 RMB>> mentionned, writing it directly with java 9 (long story short it has a 
module-info parser and writer).


 RMB>> Romain Manni-Bucau
 RMB>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn

 RMB>> 2017-12-31 16:58 GMT+01:00 Andriy Redko :

 RMB>> Hi Romain,

 RMB>>  I think there are 2 parts regarding modules: 1) using CXF from 
modularized
 RMB>>  applications and 2) release/redesign CXF in a modular fashion (I mean 
Java 9 modules).
 RMB>>  The 2nd part is where we are heading eventually but we won't be trully 
modular till
 RMB>>  all our dependencies are available as modules as well. The idea of 
adding
 RMB>>  automatic module name is helping out with the 1st part. Regarding your 
questions
 RMB>>  though:

 RMB>>  1. Adding module-info.java would mean, at least, to branch the 
artifacts (java9+ / java8).
 RMB>>  2. Yes, I think it makes sense, this is the recommended way, but we 
should better make a
 RMB>>  proposal first (as part of the JIRA Dennis created).
 RMB>>  3. I think this is the only way (as module-info.java won't compile with 
Java 8)

 RMB>>  Automatic modules is a good start (arguably, for sure), because from 
the efforts
 RMB>>  perspetive, it looks doable in a short time vs adding proper 
module-info.java to
 RMB>>  each module, which would take significantly more. Thoughts?

 RMB>>  Best Regards,
 RMB>>  Andriy Redko


  RMB>>> Hi guys,

  RMB>>> Few random notes/questions:

  RMB>>> 1. Why not using 
https://github.com/moditect/moditect/blob/master/README.md
  RMB>>> and assume the moduleinfo instead of working it around with automatic
  RMB>>> module name?
  RMB>>> 2. For the naming it should really be someting like $group.$module IMO,
  RMB>>> probably with underscores instead of iphens for the module and maybe
  RMB>>> removing cxf from the module dince it is in the package
  RMB>>> 3. Is it possible to double relezse each module, one with the module 
info
  RMB>>> (if you do 1, or without the automatic module name if you dont) and a
  RMB>>> qualifier jdk9 and keep current ones as today until the whole stack is 
java
  RMB>>> 9 (transitively). Easy to break consumers otherwise.


  RMB>>> Le 31 déc. 2017 13:38, "Dennis Kieselhorst"  a écrit :


   > Exactly, that's the idea, updating the manifest with
   Automatic-Module-Name. We could also add a sample
   > project (this would be Java 9 based) to illustrate the basic usage of
   CXF from/within green field Java 9
   > modular project (although we may need to do more work here I suspect).
   Thanks.
   I've opened CXF-7600 for it. What should be the Automatic-Module-Name
   for cxf-core? Just org.apache.cxf? Or org.apache.cxf.core which doesn't
   match the package name structure?

   Regards
   Dennis

Re: New Java 9 master

[Romain Manni-Bucau]

Le 31 déc. 2017 19:15, "Andriy Redko"  a écrit :

I am not sure about plugin part, to be honest. I would better craft the
module-info.java by hand (but use
the tooling, jdeps f.e., to get the initial list of modules) and have it in
the source tree for each module,
so to keep the history, etc. That would be aligned with Sergey's suggestion
to have Java 9 master sometime
in the future.

But, by and large, you may be right and the plugin is the viable option.
Still, if 99% of the CXF dependencies are
going to be automatic modules nonetheless, what it will buy us? And looking
into other projects, that seems to
be the starting point for many. Anyway, I would prefer to get it all and
right now :-D but realistically, I see
the automatic module name to be the less riskier approach to begin with
(just a manifest change), not necessarily
the best one though.


Or the worst since you dont expose the "api" but all the classes and breaks
SPI since service loader loading is different in named modules, no?


Best Regards,
Andriy Redko



RMB> Hmm, shout if I didn't get your comments properly and my comment is
obvious but I think 1 and 3 are fine - that's
RMB> why I proposed them - because you can create the module-info.java with
java 8. This is what does the plugin I
RMB> mentionned, writing it directly with java 9 (long story short it has a
module-info parser and writer).


RMB> Romain Manni-Bucau
RMB> @rmannibucau |  Blog | Old Blog | Github | LinkedIn

RMB> 2017-12-31 16:58 GMT+01:00 Andriy Redko :

RMB> Hi Romain,

RMB>  I think there are 2 parts regarding modules: 1) using CXF from
modularized
RMB>  applications and 2) release/redesign CXF in a modular fashion (I mean
Java 9 modules).
RMB>  The 2nd part is where we are heading eventually but we won't be
trully modular till
RMB>  all our dependencies are available as modules as well. The idea of
adding
RMB>  automatic module name is helping out with the 1st part. Regarding
your questions
RMB>  though:

RMB>  1. Adding module-info.java would mean, at least, to branch the
artifacts (java9+ / java8).
RMB>  2. Yes, I think it makes sense, this is the recommended way, but we
should better make a
RMB>  proposal first (as part of the JIRA Dennis created).
RMB>  3. I think this is the only way (as module-info.java won't compile
with Java 8)

RMB>  Automatic modules is a good start (arguably, for sure), because from
the efforts
RMB>  perspetive, it looks doable in a short time vs adding proper
module-info.java to
RMB>  each module, which would take significantly more. Thoughts?

RMB>  Best Regards,
RMB>  Andriy Redko

 RMB>> Hi guys,

 RMB>> Few random notes/questions:

 RMB>> 1. Why not using https://github.com/moditect/
moditect/blob/master/README.md
 RMB>> and assume the moduleinfo instead of working it around with automatic
 RMB>> module name?
 RMB>> 2. For the naming it should really be someting like $group.$module
IMO,
 RMB>> probably with underscores instead of iphens for the module and maybe
 RMB>> removing cxf from the module dince it is in the package
 RMB>> 3. Is it possible to double relezse each module, one with the module
info
 RMB>> (if you do 1, or without the automatic module name if you dont) and a
 RMB>> qualifier jdk9 and keep current ones as today until the whole stack
is java
 RMB>> 9 (transitively). Easy to break consumers otherwise.


 RMB>> Le 31 déc. 2017 13:38, "Dennis Kieselhorst"  a écrit
:


 >>> > Exactly, that's the idea, updating the manifest with
 >>> Automatic-Module-Name. We could also add a sample
 >>> > project (this would be Java 9 based) to illustrate the basic usage of
 >>> CXF from/within green field Java 9
 >>> > modular project (although we may need to do more work here I
suspect).
 >>> Thanks.
 >>> I've opened CXF-7600 for it. What should be the Automatic-Module-Name
 >>> for cxf-core? Just org.apache.cxf? Or org.apache.cxf.core which doesn't
 >>> match the package name structure?

 >>> Regards
 >>> Dennis

Re: New Java 9 master

[Dennis Kieselhorst]

> Exactly, that's the idea, updating the manifest with Automatic-Module-Name. 
> We could also add a sample
> project (this would be Java 9 based) to illustrate the basic usage of CXF 
> from/within green field Java 9
> modular project (although we may need to do more work here I suspect). Thanks.
I've opened CXF-7600 for it. What should be the Automatic-Module-Name
for cxf-core? Just org.apache.cxf? Or org.apache.cxf.core which doesn't
match the package name structure?

Regards
Dennis

Re: New Java 9 master

[Andriy Redko]

Hey,

Exactly, that's the idea, updating the manifest with Automatic-Module-Name. We 
could also add a sample
project (this would be Java 9 based) to illustrate the basic usage of CXF 
from/within green field Java 9
modular project (although we may need to do more work here I suspect). Thanks.

Best Regards,
Andriy Redko

DK> Hey,

DK> I would simply apply Automatic-Module-Name to existing master as the
DK> Commons guys did.

DK> See also: https://github.com/jodastephen/jpms-module-names

DK> Merry xmas
DK> Dennis

Re: New Java 9 master

[Dennis Kieselhorst]

Hey,

I would simply apply Automatic-Module-Name to existing master as the
Commons guys did.

See also: https://github.com/jodastephen/jpms-module-names

Merry xmas
Dennis

Re: New Java 9 master

[Andriy Redko]

Hey guys,

It feels like a right time to resume the discussion around Java 9. The adoption 
of modules is slowly but is taking
off. I run into this article 
https://www.javaadvent.com/2017/12/automatic-module-name-calling-java-library-maintainers.html
 by
Sander Mak (co-author of Java 9 Modularity book) recently, he gives pretty 
pragmatic advice on how to start embracing the
modular applications. Indeed, the first steps are pretty low risk and 
straightforward, just updating the MANIFEST.MF files. 
Also, I have checked a couple of leading Java libraries (f.e. Spring Framework) 
and can confirm that they already did the 
relevant updates. Does it sound like a good idea? It does not require a 
dedicated Java 9 master but something with could 
do in the current one. Thanks.

Best Regards,
Andriy Redko

SB> Hi Jeff

SB> Good to hear from you, thanks for the feedback :-).

SB> I suppose there's some consensus that in the next few months the team 
SB> should probably spend more time with using Java 9 with CXF 3.2.x, and 
SB> really get a better appreciation of what Java 9 is and which tools are 
SB> available around (such as may be Maven Java 9 related as Dan indicated, 
SB> etc) as it's fair enough to say that some of us (incl. myself) are not 
SB> doing practical Java 9 at all at the moment...

SB> Hopefully that will help, perhaps another round of discussions will 
SB> follow afterwards, we'll see.

SB> Thanks, Sergey


SB> On 17/11/17 03:42, Jeff Genender wrote:


>>> On Nov 16, 2017, at 7:02 AM, Sergey Beryozkin  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 :
>> 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 

Re: New Java 9 master

[Sergey Beryozkin]

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  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 :

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 

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 

Re: New Java 9 master

[Christian Schneider]

2017-11-17 4:40 GMT+01:00 Jeff Genender :

>
>
> > On Nov 16, 2017, at 6:02 AM, Christian Schneider <
> ch...@die-schneider.net> wrote:
> >
> > I am not sure sure about the need for Java 9 modules. Currently I see no
> > user requesting this.
>
> We need a user to request it?  Whats wrong with us looking in a crystal
> ball?  Doesn’t one of our own committers count as a user requesting it?
>

Absolutely Sergeys request is surely valid. I just fear the additional
overhead and that a java 9 master might prevent some java 8 developers from
supplying patches as they would be forced to develop on java 9.
So I completely agree that we will have a java 9 master at some point ..
The question is only when. My approach to this is to switch as late as
possible while still allowing us to explore java 9.

>
> > It is also not yet fully clear how these modules
> > behave in OSGi.
>
> They are just jars with manifests, no?  I would believe they would both
> operate based on their own manifest file contents.  Let stay it and find
> out. ;-). No harm no foul.
>

Yes. I completely agree to try this. I would rather experiment with this in
a side branch though. The ideal solution would be a jar that is both a java
9 module and a regular java 8 jar. Not sure if that works though.
If Dans assumption is right that all our deps must be JAva 9 modules before
we switch this will take quite a while anyway. So I think the right time to
switch to add java 9 modules is when all dependencies are modules.
For other java 9 features we might want to provide support earlier though.

>
> >
> > 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.
> >
>
> But others do use it.  I'm one of those who did go all in JDK 9… call me a
> cutting edge person. ;-). I have people asking me all the time about this.
> Different strokes for different folks. ;-)
>
> > 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.
>
> And what did that reluctancy buy us except people wondering what is taking
> so long.  Why not get ahead of the curve this time instead of being
> dinosaurs and the last ones to the table.
>
> Whats the harm in doing it?  Its just a git repo that has zero impact on
> the Java 8 code base.  Everything will feed it as an upstream code base.
>

The harm is that every change in CXF will be coded and tested on the Java 9
master first then. Additionally it would need to be backported to the older
branches. So we would force all CXF developers to switch to Java 9.
This is the price and it will be especially high while most people are
still on Java 8.

On the other hand the gain is that Java 9 developers can already work with
Java 9 features. At the start this gain is very low. It will grow over time
when people migrate to Java 9.

So the question is simply when there is the right time for this switch.

Christian


-- 
-- 
Christian Schneider
http://www.liquid-reality.de


Computer Scientist
http://www.adobe.com

Re: New Java 9 master

[Jeff Genender]

> On Nov 16, 2017, at 7:02 AM, Sergey Beryozkin  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 :
 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 
>>> 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> --

Re: New Java 9 master

[Jeff Genender]

> On Nov 16, 2017, at 6:02 AM, Christian Schneider  
> wrote:
> 
> I am not sure sure about the need for Java 9 modules. Currently I see no
> user requesting this.

We need a user to request it?  Whats wrong with us looking in a crystal ball?  
Doesn’t one of our own committers count as a user requesting it?

> It is also not yet fully clear how these modules
> behave in OSGi.

They are just jars with manifests, no?  I would believe they would both operate 
based on their own manifest file contents.  Let stay it and find out. ;-). No 
harm no foul.

> 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.

How is this any different than what we have done in the past with our multiple 
versions? CXF for JDK9 with modules… perhaps a CXF 4?
> 
> 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.
> 

But others do use it.  I'm one of those who did go all in JDK 9… call me a 
cutting edge person. ;-). I have people asking me all the time about this.  
Different strokes for different folks. ;-)

> 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.

And what did that reluctancy buy us except people wondering what is taking so 
long.  Why not get ahead of the curve this time instead of being dinosaurs and 
the last ones to the table.

Whats the harm in doing it?  Its just a git repo that has zero impact on the 
Java 8 code base.  Everything will feed it as an upstream code base.

I’m not getting why the pushback..

Jeff


> 
> Christian
> 
> 2017-11-16 13:31 GMT+01:00 Sergey Beryozkin :
> 
>> 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 
> 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
> 
> 
>>> 
> 
> 
> -- 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> 
> 
> Computer Scientist
> http://www.adobe.com

Re: New Java 9 master

[Andriy Redko]

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  wrote:
>> 
>> Hi
>> 
>> Should we open a new Java 9 only master soon enough ?
>> 
>> Thanks, Sergey

Re: New Java 9 master

[Jeff Genender]

Well I don’t necessarily agree about anyone moving to Java 9 anytime soon.  I’m 
beginning to see companies do it, albeit small companies/start ups… but they 
are moving.

I think the necessity for moving to JDK 9 is the modules.  We should think 
about making the jars not only OSGi compliant, but able to work with Jigsaw.  I 
think more and more people will be moving to that since it has become a part of 
the JVM.

Just my ,02.

Jeff


> On Nov 16, 2017, at 9:58 AM, Daniel Kulp  wrote:
> 
> 
> 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.
> 
> That said, at some point soon, I’d like to make master more “Java 9 Friendly” 
> and hopefully release a 3.3 at some point in the future that supports java8, 
> but may be more friendly for Java9.Not 100% sure what that would entail, 
> but I would definitely be open to the idea of releases being done with Java9 
> that would allow additional modules for Java9 users.
> 
> 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 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 the normal src/main/java directories was all Java5/6 with JAX-WS 2.1.   
> However, we had a separate src/man/jaxws22 source directory that contained 
> the additional classes and such that were needed for JAX-WS 2.2.   At release 
> time, we had to make sure we used the appropriate JDK/Profile to get that 
> included.   
> 
> Now, what does “Java 9 Friendly” entail?   Not really sure.  Off the top of 
> my head, I would definitely start by including dependencies for all the 
> javax.* API’s.   Example, core depends on JAXB so add the jaxb-api jar.
> This would definitely reduce the amount of “patch-module” things that are 
> needed to use CXF on Java9.   However, it’s not 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” thing.As part of this, we’d also update to as many dependencies 
> that are module friendly as possible.  We could also have additional 
> source dirs or similar to the tree for Java 9 “cool things”, providing we can 
> still compile with —target=1.8.Another example could possibly be an 
> update to the http client transport to use the Java9 HttpClient.   If run on 
> Java8, we’d stick with URLConnection, on Java9, use HttpClient. 
> 
> 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.
> 
> Dan
> 
> 
> 
> 
>> On Nov 15, 2017, at 6:47 AM, Sergey Beryozkin  wrote:
>> 
>> Hi
>> 
>> Should we open a new Java 9 only master soon enough ?
>> 
>> Thanks, Sergey
> 
> -- 
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
> 

Re: New Java 9 master

[Daniel Kulp]

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.

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

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 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 the 
normal src/main/java directories was all Java5/6 with JAX-WS 2.1.   However, we 
had a separate src/man/jaxws22 source directory that contained the additional 
classes and such that were needed for JAX-WS 2.2.   At release time, we had to 
make sure we used the appropriate JDK/Profile to get that included.   

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

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.

Dan




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

-- 
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Re: New Java 9 master

[Sergey Beryozkin]

Well, personally I'd like to see CXF being live rather than staying 
stale. CXF 3.2.x was open for more than a year and it has not gone off 
track.
Java 9 will have Flow, which despite your or mine preferences, will 
attract users who would rather work with standard Java 9 API as opposed 
to the popular but specific to the libs RxJava2 and/or Reactor, so it is 
a massive feature...
IMHO CXF dev community is large enough now for the Java 9+ only branch 
to succeed


Sergey
On 16/11/17 16:10, Christian Schneider wrote:

I mean simple in regard to everyday work on the code. The effort would be
mainly in setting up this build once.

I simply had bad experiences in the past with a master that is never
released for a long time. For example there was a camel 3 master for a long
time and it deteriorated more and more over time as people concentrated on
the code that was going into the releases they use on a daily basis. So no
one really cared about a master that everyone knew is not released anytime
(soon).

Personally I even prefer to simply stay on a java 8+9 master until a big
percentage of people switched to java 9. This will not allow us to use java
9 features until then but honestly I personally have no intention to ever
switch to java 9. I will probably wait if java 10 brings anything
convincing.

Christian

2017-11-16 16:57 GMT+01:00 Sergey Beryozkin :


Sorry, looks like a pretty messy and non convincing plan to me.
Simple for users and us ? Seriously ? This would be Java 9 only branch
would be released probably once in at least a year time from now.

Cheers, Sergey

On 16/11/17 15:42, Christian Schneider wrote:


So lets make this a little more concrete. What do we expect that people do
in the Java 9 master?

Java 9 modules -> As Andriy explained this only works when all our
dependencies are Java 9 modules. So this will not be near term.
Java 9 reactive streams. Could be interesting but there is already rxjava
and project reactor. So people have the reactive capabilities already. So
I
am not sure how many people are really interested in this. We can do kind
of a poll on the user list.
I do not think there are any other Java 9 features that are really an
incentive for a java 9 only branch.

So I think the Java 9 only code could be limited to only a few modules.
For
example we could have a REST client with java 9 Flow support.
So how about having a build that checks if the developer has a jdk8. If
yes
then we skip the java 9 modules in the build. If the developer has java 9
we build all modules. We could then do our release with Java 9 but make
sure that most modules can run with java 8 and only the few java 9 modules
require java 9. Not sure if that is possible but it would make our and the
users life a lot simpler than a pure java 9 master.

Christian


2017-11-16 15:02 GMT+01:00 Sergey Beryozkin :

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.

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.

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

Re: New Java 9 master

[Christian Schneider]

I mean simple in regard to everyday work on the code. The effort would be
mainly in setting up this build once.

I simply had bad experiences in the past with a master that is never
released for a long time. For example there was a camel 3 master for a long
time and it deteriorated more and more over time as people concentrated on
the code that was going into the releases they use on a daily basis. So no
one really cared about a master that everyone knew is not released anytime
(soon).

Personally I even prefer to simply stay on a java 8+9 master until a big
percentage of people switched to java 9. This will not allow us to use java
9 features until then but honestly I personally have no intention to ever
switch to java 9. I will probably wait if java 10 brings anything
convincing.

Christian

2017-11-16 16:57 GMT+01:00 Sergey Beryozkin :

> Sorry, looks like a pretty messy and non convincing plan to me.
> Simple for users and us ? Seriously ? This would be Java 9 only branch
> would be released probably once in at least a year time from now.
>
> Cheers, Sergey
>
> On 16/11/17 15:42, Christian Schneider wrote:
>
>> So lets make this a little more concrete. What do we expect that people do
>> in the Java 9 master?
>>
>> Java 9 modules -> As Andriy explained this only works when all our
>> dependencies are Java 9 modules. So this will not be near term.
>> Java 9 reactive streams. Could be interesting but there is already rxjava
>> and project reactor. So people have the reactive capabilities already. So
>> I
>> am not sure how many people are really interested in this. We can do kind
>> of a poll on the user list.
>> I do not think there are any other Java 9 features that are really an
>> incentive for a java 9 only branch.
>>
>> So I think the Java 9 only code could be limited to only a few modules.
>> For
>> example we could have a REST client with java 9 Flow support.
>> So how about having a build that checks if the developer has a jdk8. If
>> yes
>> then we skip the java 9 modules in the build. If the developer has java 9
>> we build all modules. We could then do our release with Java 9 but make
>> sure that most modules can run with java 8 and only the few java 9 modules
>> require java 9. Not sure if that is possible but it would make our and the
>> users life a lot simpler than a pure java 9 master.
>>
>> Christian
>>
>>
>> 2017-11-16 15:02 GMT+01:00 Sergey Beryozkin :
>>
>> 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.
>>>
>>> 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.
>>>
>>> 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.

Re: New Java 9 master

[Sergey Beryozkin]

If we follow this line of reasoning then we should simply have a single 
branch only in CXF where we'd check Java9, Java 8 and Java 7 modules and 
then do Java 9 or Java 8 or Java 7 releases only from the same branch

and may be this will be simple for the users and for us...

Sergey
On 16/11/17 15:57, Sergey Beryozkin wrote:

Sorry, looks like a pretty messy and non convincing plan to me.
Simple for users and us ? Seriously ? This would be Java 9 only branch 
would be released probably once in at least a year time from now.


Cheers, Sergey
On 16/11/17 15:42, Christian Schneider wrote:
So lets make this a little more concrete. What do we expect that 
people do

in the Java 9 master?

Java 9 modules -> As Andriy explained this only works when all our
dependencies are Java 9 modules. So this will not be near term.
Java 9 reactive streams. Could be interesting but there is already rxjava
and project reactor. So people have the reactive capabilities already. 
So I

am not sure how many people are really interested in this. We can do kind
of a poll on the user list.
I do not think there are any other Java 9 features that are really an
incentive for a java 9 only branch.

So I think the Java 9 only code could be limited to only a few 
modules. For

example we could have a REST client with java 9 Flow support.
So how about having a build that checks if the developer has a jdk8. 
If yes

then we skip the java 9 modules in the build. If the developer has java 9
we build all modules. We could then do our release with Java 9 but make
sure that most modules can run with java 8 and only the few java 9 
modules
require java 9. Not sure if that is possible but it would make our and 
the

users life a lot simpler than a pure java 9 master.

Christian


2017-11-16 15:02 GMT+01:00 Sergey Beryozkin :


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.


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.


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 :

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 

Re: New Java 9 master

[Sergey Beryozkin]

Sorry, looks like a pretty messy and non convincing plan to me.
Simple for users and us ? Seriously ? This would be Java 9 only branch 
would be released probably once in at least a year time from now.


Cheers, Sergey
On 16/11/17 15:42, Christian Schneider wrote:

So lets make this a little more concrete. What do we expect that people do
in the Java 9 master?

Java 9 modules -> As Andriy explained this only works when all our
dependencies are Java 9 modules. So this will not be near term.
Java 9 reactive streams. Could be interesting but there is already rxjava
and project reactor. So people have the reactive capabilities already. So I
am not sure how many people are really interested in this. We can do kind
of a poll on the user list.
I do not think there are any other Java 9 features that are really an
incentive for a java 9 only branch.

So I think the Java 9 only code could be limited to only a few modules. For
example we could have a REST client with java 9 Flow support.
So how about having a build that checks if the developer has a jdk8. If yes
then we skip the java 9 modules in the build. If the developer has java 9
we build all modules. We could then do our release with Java 9 but make
sure that most modules can run with java 8 and only the few java 9 modules
require java 9. Not sure if that is possible but it would make our and the
users life a lot simpler than a pure java 9 master.

Christian


2017-11-16 15:02 GMT+01:00 Sergey Beryozkin :


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.

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.

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 :

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 

Re: New Java 9 master

[Christian Schneider]

So lets make this a little more concrete. What do we expect that people do
in the Java 9 master?

Java 9 modules -> As Andriy explained this only works when all our
dependencies are Java 9 modules. So this will not be near term.
Java 9 reactive streams. Could be interesting but there is already rxjava
and project reactor. So people have the reactive capabilities already. So I
am not sure how many people are really interested in this. We can do kind
of a poll on the user list.
I do not think there are any other Java 9 features that are really an
incentive for a java 9 only branch.

So I think the Java 9 only code could be limited to only a few modules. For
example we could have a REST client with java 9 Flow support.
So how about having a build that checks if the developer has a jdk8. If yes
then we skip the java 9 modules in the build. If the developer has java 9
we build all modules. We could then do our release with Java 9 but make
sure that most modules can run with java 8 and only the few java 9 modules
require java 9. Not sure if that is possible but it would make our and the
users life a lot simpler than a pure java 9 master.

Christian


2017-11-16 15:02 GMT+01:00 Sergey Beryozkin :

> 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.
>
> 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.
>
> 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 :
>>
>> 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 

Re: New Java 9 master

[Sergey Beryozkin]

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.


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.


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 :


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 

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> --

Re: New Java 9 master

[Andriy Redko]

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 :

>> 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 
> 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> -- 

Re: New Java 9 master

[Sergey Beryozkin]

Obvious typo there, that yes in a Java 9 only master it won;t work with 
Java 8.


To be honest I don't understand why would CXF dev would be effectively 
frozen which would be the case if no Java 9 master is not opened


Sergey
On 16/11/17 13:09, Sergey Beryozkin wrote:
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 :


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 

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










--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Re: New Java 9 master

[Sergey Beryozkin]

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 :


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 

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

Re: New Java 9 master

[Christian Schneider]

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 :

> 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 
 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


>>


-- 
-- 
Christian Schneider
http://www.liquid-reality.de


Computer Scientist
http://www.adobe.com

Re: New Java 9 master

[Sergey Beryozkin]

Hi Freeman

OK, thanks. So we already have 3.2.1 meeting a Java9 + Java8 
requirement, which is great. I haven't even tried to build CXF master 
with Java 9 :-), will try asap...


Cheers, Sergey
On 16/11/17 12:23, Freeman Fang wrote:

Hi Sergey,

Yep, it’s about to use Java9 to build and run CXF 3.2.x with classical java 
“classpath” way. To fully adapt the CXF to use jigsaw module, I think we need a 
JDK9 only branch to work with.

Btw, it’s already in current CXF master(3.2.x-SNAPSHOT). We can build and pass 
all tests with latest  JDK 9.0.1. So CXF 3.2.x have it already. I guess what we 
would do next is fork a 3.2.x-fixes branch based on current master, and change 
the master version to 4.0.0-SNAPSHOT, and this master branch could be the one 
we can experiment with pure JAVA9 new features.

Cheers.
－
Freeman(Yue) Fang

Red Hat, Inc.
FuseSource is now part of Red Hat




On Nov 16, 2017, at 6:26 PM, Sergey Beryozkin  wrote:

Hi Freeman

By the way, what is status of your Java 9 branch, I understand it was really 
about using Java 9 to compile and load CXF 3.2.x ? If so then may be it can be 
merged to 3.2.x ?

Cheers, Sergey


On 16/11/17 06:17, Freeman Fang wrote:

+1
If next CXF major release(3.3 or 4.0) are not going to support JDK8 anymore, 
it’s about the time to create master branch which is for Java9(and the 
successor JDK version which is not very far away). And this also would be easy 
for us to adjust CXF to use the jigsaw module eventually, like to add 
module-info.java  to see how is it going on there.
Best Regards
－
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat

On Nov 16, 2017, at 1:03 PM, Andy McCright  wrote:

Hi Sergey,

I'm in favor of the idea.  One thing worth noting is that Java 9 is a very
limited support release.  According to Oracle's support strategy [1], Java
9 will only be supported until March 2018, then they will be releasing Java
10 (aka 18.3) which also will have a short shelf-life.  The next long-term
support release is 18.9 which releases in September.  We'll probably want
the new Java 9 master branch to work with 18.3 as well, then maybe consider
a new master branch for 18.9 some time next year. What do you think?

Thanks,
Andy

[1] http://www.oracle.com/technetwork/java/eol-135779.html

On Wed, Nov 15, 2017 at 5:47 AM, Sergey Beryozkin 
wrote:


Hi

Should we open a new Java 9 only master soon enough ?

Thanks, Sergey

Re: New Java 9 master

[Sergey Beryozkin]

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  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

Re: New Java 9 master

[Freeman Fang]

Hi Sergey,

Yep, it’s about to use Java9 to build and run CXF 3.2.x with classical java 
“classpath” way. To fully adapt the CXF to use jigsaw module, I think we need a 
JDK9 only branch to work with.

Btw, it’s already in current CXF master(3.2.x-SNAPSHOT). We can build and pass 
all tests with latest  JDK 9.0.1. So CXF 3.2.x have it already. I guess what we 
would do next is fork a 3.2.x-fixes branch based on current master, and change 
the master version to 4.0.0-SNAPSHOT, and this master branch could be the one 
we can experiment with pure JAVA9 new features.

Cheers.
－
Freeman(Yue) Fang

Red Hat, Inc. 
FuseSource is now part of Red Hat



> On Nov 16, 2017, at 6:26 PM, Sergey Beryozkin  wrote:
> 
> Hi Freeman
> 
> By the way, what is status of your Java 9 branch, I understand it was really 
> about using Java 9 to compile and load CXF 3.2.x ? If so then may be it can 
> be merged to 3.2.x ?
> 
> Cheers, Sergey
> 
> 
> On 16/11/17 06:17, Freeman Fang wrote:
>> +1
>> If next CXF major release(3.3 or 4.0) are not going to support JDK8 anymore, 
>> it’s about the time to create master branch which is for Java9(and the 
>> successor JDK version which is not very far away). And this also would be 
>> easy for us to adjust CXF to use the jigsaw module eventually, like to add 
>> module-info.java  to see how is it going on there.
>> Best Regards
>> －
>> Freeman(Yue) Fang
>> Red Hat, Inc.
>> FuseSource is now part of Red Hat
>>> On Nov 16, 2017, at 1:03 PM, Andy McCright  
>>> wrote:
>>> 
>>> Hi Sergey,
>>> 
>>> I'm in favor of the idea.  One thing worth noting is that Java 9 is a very
>>> limited support release.  According to Oracle's support strategy [1], Java
>>> 9 will only be supported until March 2018, then they will be releasing Java
>>> 10 (aka 18.3) which also will have a short shelf-life.  The next long-term
>>> support release is 18.9 which releases in September.  We'll probably want
>>> the new Java 9 master branch to work with 18.3 as well, then maybe consider
>>> a new master branch for 18.9 some time next year. What do you think?
>>> 
>>> Thanks,
>>> Andy
>>> 
>>> [1] http://www.oracle.com/technetwork/java/eol-135779.html
>>> 
>>> On Wed, Nov 15, 2017 at 5:47 AM, Sergey Beryozkin 
>>> wrote:
>>> 
 Hi
 
 Should we open a new Java 9 only master soon enough ?
 
 Thanks, Sergey
 

Re: New Java 9 master

[Andriy Redko]

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  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
>> 

Re: New Java 9 master

[Sergey Beryozkin]

Hi Freeman

By the way, what is status of your Java 9 branch, I understand it was 
really about using Java 9 to compile and load CXF 3.2.x ? If so then may 
be it can be merged to 3.2.x ?


Cheers, Sergey


On 16/11/17 06:17, Freeman Fang wrote:

+1

If next CXF major release(3.3 or 4.0) are not going to support JDK8 anymore, 
it’s about the time to create master branch which is for Java9(and the 
successor JDK version which is not very far away). And this also would be easy 
for us to adjust CXF to use the jigsaw module eventually, like to add 
module-info.java  to see how is it going on there.

Best Regards
－
Freeman(Yue) Fang

Red Hat, Inc.
FuseSource is now part of Red Hat




On Nov 16, 2017, at 1:03 PM, Andy McCright  wrote:

Hi Sergey,

I'm in favor of the idea.  One thing worth noting is that Java 9 is a very
limited support release.  According to Oracle's support strategy [1], Java
9 will only be supported until March 2018, then they will be releasing Java
10 (aka 18.3) which also will have a short shelf-life.  The next long-term
support release is 18.9 which releases in September.  We'll probably want
the new Java 9 master branch to work with 18.3 as well, then maybe consider
a new master branch for 18.9 some time next year. What do you think?

Thanks,
Andy

[1] http://www.oracle.com/technetwork/java/eol-135779.html

On Wed, Nov 15, 2017 at 5:47 AM, Sergey Beryozkin 
wrote:


Hi

Should we open a new Java 9 only master soon enough ?

Thanks, Sergey

Re: New Java 9 master

[Sergey Beryozkin]

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


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


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


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


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


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

On 2017-11-16 07:27, Christian Schneider  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

Re: New Java 9 master

[Sergey Beryozkin]

Hi Andy

Right, somewhere around March 2018 would be fine, though, I suppose, 
given this master would be open for a long time, it would be just a 
matter of updating to 18.3 and then to 18.9, I guess by the time a would 
be CXF 4.0.0 gets released at least 18.3  will have already been 
released as well :-)


Cheers, Sergey
On 16/11/17 05:03, Andy McCright wrote:

Hi Sergey,

I'm in favor of the idea.  One thing worth noting is that Java 9 is a very
limited support release.  According to Oracle's support strategy [1], Java
9 will only be supported until March 2018, then they will be releasing Java
10 (aka 18.3) which also will have a short shelf-life.  The next long-term
support release is 18.9 which releases in September.  We'll probably want
the new Java 9 master branch to work with 18.3 as well, then maybe consider
a new master branch for 18.9 some time next year. What do you think?

Thanks,
Andy

[1] http://www.oracle.com/technetwork/java/eol-135779.html

On Wed, Nov 15, 2017 at 5:47 AM, Sergey Beryozkin 
wrote:


Hi

Should we open a new Java 9 only master soon enough ?

Thanks, Sergey

Re: New Java 9 master

[Dennis Kieselhorst]

On 2017-11-16 07:27, Christian Schneider  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

Re: New Java 9 master

[Christian Schneider]

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?

Christian

2017-11-15 12:47 GMT+01:00 Sergey Beryozkin :

> Hi
>
> Should we open a new Java 9 only master soon enough ?
>
> Thanks, Sergey
>



-- 
-- 
Christian Schneider
http://www.liquid-reality.de


Computer Scientist
http://www.adobe.com

Re: New Java 9 master

[Freeman Fang]

+1

If next CXF major release(3.3 or 4.0) are not going to support JDK8 anymore, 
it’s about the time to create master branch which is for Java9(and the 
successor JDK version which is not very far away). And this also would be easy 
for us to adjust CXF to use the jigsaw module eventually, like to add 
module-info.java  to see how is it going on there.

Best Regards
－
Freeman(Yue) Fang

Red Hat, Inc. 
FuseSource is now part of Red Hat



> On Nov 16, 2017, at 1:03 PM, Andy McCright  
> wrote:
> 
> Hi Sergey,
> 
> I'm in favor of the idea.  One thing worth noting is that Java 9 is a very
> limited support release.  According to Oracle's support strategy [1], Java
> 9 will only be supported until March 2018, then they will be releasing Java
> 10 (aka 18.3) which also will have a short shelf-life.  The next long-term
> support release is 18.9 which releases in September.  We'll probably want
> the new Java 9 master branch to work with 18.3 as well, then maybe consider
> a new master branch for 18.9 some time next year. What do you think?
> 
> Thanks,
> Andy
> 
> [1] http://www.oracle.com/technetwork/java/eol-135779.html
> 
> On Wed, Nov 15, 2017 at 5:47 AM, Sergey Beryozkin 
> wrote:
> 
>> Hi
>> 
>> Should we open a new Java 9 only master soon enough ?
>> 
>> Thanks, Sergey
>> 

Re: New Java 9 master

[Andy McCright]

Hi Sergey,

I'm in favor of the idea.  One thing worth noting is that Java 9 is a very
limited support release.  According to Oracle's support strategy [1], Java
9 will only be supported until March 2018, then they will be releasing Java
10 (aka 18.3) which also will have a short shelf-life.  The next long-term
support release is 18.9 which releases in September.  We'll probably want
the new Java 9 master branch to work with 18.3 as well, then maybe consider
a new master branch for 18.9 some time next year. What do you think?

Thanks,
Andy

[1] http://www.oracle.com/technetwork/java/eol-135779.html

On Wed, Nov 15, 2017 at 5:47 AM, Sergey Beryozkin 
wrote:

> Hi
>
> Should we open a new Java 9 only master soon enough ?
>
> Thanks, Sergey
>