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 <[email protected]>: > 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 <[email protected]>: >> >> 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 <[email protected]>: >>>> >>>> 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 <[email protected]> >>>> >>>>> >>>>>>>> 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> -- >>>> >>>> >>>> >> >> -- -- Christian Schneider http://www.liquid-reality.de <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de> Computer Scientist http://www.adobe.com
