Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jaxrs-dev] Java version
Arjan,
>  So, indeed, the decisions for 8 vs 9 is a big one, but 11 vs 12, or 23 vs 24, will very likely not matter as much.

+1

Moving to the Java 9+ train is a major decision and should not be taken lightly.  Personally, I would stick with Java 8 as the prereq for any current work until the next LTS Java version becomes available (Java 11) and then re-evaluate going forward.

-- Kevin



On Mon, Apr 2, 2018 at 2:16 PM, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
Hi,

On Mon, Apr 2, 2018 at 7:30 PM, Markus KARG <markus@xxxxxxxxxxxxxxx> wrote:

They will definitively not upgrade to Java 9 just because of us, because of Payara, or because of JAX-RS.


I agree, they won't, but I think I mentioned above it's an industry wide issue. We (as in library vendors) all contribute a tiny bit.

Java 9 is a special case since it's such an invasive change. But after Java 9, with 10, 11, 12 etc, people may perceive versions as more fluid.

So, indeed, the decisions for 8 vs 9 is a big one, but 11 vs 12, or 23 vs 24, will very likely not matter as much.

Kind regards,
Arjan Tijms


 

Before that happens, they throw out us, Payara, and JAX-RS. So, it is definitively not that trivial as you say…

 

Another misunderstanding is that our customers use "old stuff". Windows 10 exists for 32 bit systems and is fully supported for years. There are cheap 32 bit industrial devices sold. Everything sold today will be used for many years. This is not "old". It is just not supported by Java 9.

 

But again, I am fine with Java 9, 10, whatever, in 2019.

 

-Markus

 

 

From: jaxrs-dev-bounces@xxxxxxxxxxx [mailto:jaxrs-dev-bounces@eclipse.org] On Behalf Of arjan tijms
Sent: Montag, 2. April 2018 19:01


To: jaxrs developer discussions
Subject: Re: [jaxrs-dev] Java version

 

Hi,

 

On Mon, Apr 2, 2018 at 6:28 PM, Santiago Pericas-Geertsen <santiago.pericasgeertsen@oracle.com> wrote:

 

 Because sometimes moving to a new version of Java is a company decision that affects multiple apps and services, whether they use JAX-RS or not.

 

Still, if a new version of Java is a company decision, a new version of JAX-RS likely is as well. I'm personally not really a fan of highly 'unbalanced' systems with respect to versioning, i.e. having a 20 year old OS version, running a 10 year old Java version, running the very latest feature release of some library.

 

If you want to stay on such an old OS, just keep using old versions of all software on top of it as well (within reason, of course, and excluding extended support for bug fixes such as still happen for e.g. Java 6). I do understand the desire to accommodate people supposedly stuck on old versions of something, but by accommodating, you also take a reason away for management to eventually green light an update of Java. Basically in a way you contribute on keeping them on such old Java versions, which is not really in the best interest of anyone, and certainly not in the best interest of Java itself.

 

That all said, the "version fear" could somewhat go away if Java SE versions are released even faster. The huge amount of anxiety, fear, stress and what have you to upgrade a major Java version may go away if there's a new major Java version every 3 months. People would be more in a continuous upgrade cycle, instead of going for a Big Bang upgrade every 6 years or so.

 

There can also be hardware issues (see Markus’ message), cloud provider problems, support contracts, etc.

 

But are these problems there if people just keep using the old version of, in this case, JAX-RS?

 

I don’t think this is a chicken and egg problem at all, platform developers always wanted to use the newer versions.

 

Application developers want to use the newer versions just as well, maybe even more.

 

Just my 2 cents though and an explanation of my general philosophy. I'm not saying at all that JAX-RS should move beyond Java 8 at all costs.

 

Kind regards,

Arjan Tijms

 

 

 

 

— Santiago






On Mar 31, 2018, at 1:16 PM, Christian Kaltepoth <christian@xxxxxxxxxxxx> wrote:

 

I would be fine with requiring Java 9 for JAX-RS 2.2. 

 

Java 9 has been release quite some time ago and Java 10 is the current version of Java. At the time JAX-RS 2.2 will be released, JDK 11 (the next LTS version) will most likely either be released already or will be available as soon as the first implementations support JAX-RS 2.2. It would be really bad if the next version will still not support the Flow API. If customers don't want to move beyond Java 8, they shouldn't expect to be able to use the latest version of the specification.

 

Just my 2 cents. ;-)

 

Am Sa., 31. März 2018 um 18:41 Uhr schrieb Markus KARG <markus@xxxxxxxxxxxxxxx>:

+1 for Flow API in 3.0, hence Java 9, 10 or 11

-1 for 2.2 enforcing Java 9 because we still have lots of customers who want to stick with 32 bit windows for another year 

-Markus

 

From: jaxrs-dev-bounces@eclipse.org [mailto:jaxrs-dev-bounces@xxxxxxxxxxx] On Behalf Of Ondrej Mihályi
Sent: Samstag, 31. März 2018 14:32
To: jaxrs developer discussions; jaxrs developer discussions
Subject: Re: [jaxrs-dev] Java version

 

Another new thing in Java 9 is the Flow API. For v2.1, SSE support aimed to support Flow API because it's a natutal fit. But because it's not in Java 8 and there was little time to discuss it, support for Flow API in SSE was postponed.

I would like to see support for Flow API in SSE. If you really like that JAX-RS 2.2 requires only Java 8, then at least 3.0 should require Java 9 and integreate SSE and rx with the flow API. Even better if that was done for v2.2

Ondro

From: jaxrs-dev-bounces@eclipse.org <jaxrs-dev-bounces@eclipse.org> on behalf of Guillermo González de Agüero <z06.guillermo@xxxxxxxxx>
Sent: Friday, March 30, 2018 3:10:21 PM
To: jaxrs developer discussions
Subject: Re: [jaxrs-dev] Java version

 

+1 for an automatic module name. 

 

Santiago, do you know if we'll be able to use the "java" namespace for the module name as this is an existing spec?

El vie., 30 mar. 2018 14:35, Markus KARG <markus@xxxxxxxxxxxxxxx> escribió:

Well there actually is one thing in Java 9 that does not exist in Java 8: Modules. The JAX-RS EG dropped modules support back in JAX-RS 2.1 as we had to release BEFORE Java 9 was there. Having a module-info is beneficial to clarify how JAX-RS API behaves when running on Java 9. OTOH we could simply provide Automatic-Module-Name instead.

-Markus

 

From: jaxrs-dev-bounces@eclipse.org [mailto:jaxrs-dev-bounces@xxxxxxxxxxx] On Behalf Of Niklas Mehner
Sent: Donnerstag, 29. März 2018 20:27
To: jaxrs developer discussions
Subject: Re: [jaxrs-dev] Java version

 

But is there anything in Java 9 that we actually need? We should probably build on Java 9 or 10 to verify that there are no problems with those, but dropping backwards compatibility without any need for it?

I guess it would be best to build JAX-RS 2.2 on Java 8 and 10.

 

2018-03-29 20:21 GMT+02:00 Christian Kaltepoth <christian@xxxxxxxxxxxx>:

I'm fine with adjusting the minimum Java version to 9 for JAX-RS 2.2.

 

But I think it is too early to talk about requirements for JAX-RS 3.0.

 

Am Do., 29. März 2018 um 20:12 Uhr schrieb Guillermo González de Agüero <z06.guillermo@xxxxxxxxx>:

AFAIK, *Oracle JDK 11* will be LTS, but at that point, only OpenJDK will remain free (which won't hace LTS).

 

So it's not Java 11 that will be LTS, but some specific implementations.

 

Btw, IBM already announced they plan to offer free LTS support for Eclipse OpenJ9 11.

 

Please correct me if I'm wrong.

El jue., 29 mar. 2018 20:07, Niklas Mehner <niklas.mehner@xxxxxxxxx> escribió:

Should this not be Java 11 instead of Java 10 for 3.0? 10 is not a long term supported version. Java 10 EOL is already in September (http://www.oracle.com/technetwork/java/eol-135779.html ).

Best regards,

  Niklas

 

 

2018-03-29 19:55 GMT+02:00 Markus KARG <markus@xxxxxxxxxxxxxxx>:

I think it would be a good thing to use Java 10 for 3.0 and Java 8 for 2.2. The reason is that people would think they can drop-in 2.2 where currently 2.1 runs -- which is Java EE 8 containers.

-Markus

 

From: jaxrs-dev-bounces@eclipse.org [mailto:jaxrs-dev-bounces@xxxxxxxxxxx] On Behalf Of Christian Kaltepoth
Sent: Donnerstag, 29. März 2018 07:28
To: jaxrs developer discussions
Subject: [jaxrs-dev] Java version

 

Hi all,

 

I'm currently preparing the Travis CI configuration. As part of that, we have to decide against which java versions we want to run the build. Please note that we can run multiple builds against different versions in parallel.

 

I just had a look at the pom and I'm a bit confused about this part. If I read it correctly, the source code version is basically set to the version of the executing JDK. Does this make sense? It seems a bit weird. Isn't the source (and target) version usually the minimum Java version supported?

 

Christian

 

-- 


_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jaxrs-dev

 

_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jaxrs-dev

_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jaxrs-dev


 

-- 


_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jaxrs-dev

 

_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jaxrs-dev

_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jaxrs-dev


 

-- 

_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jaxrs-dev

 


_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jaxrs-dev

 

_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jaxrs-dev

 


_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jaxrs-dev

 


_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jaxrs-dev



_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jaxrs-dev


Back to the top