Hi Michael, All,
I'll (somehow) give my (not opinionated) opinion in the ASF way.
I don't want to be polemical, rather to complete this discussion. The more
brains on it the better.
So I'll try to gather some facts and let people have their own opinions
Inline...
Le 15/04/2019 à 10:46, Michael Brohl a écrit :
Hi Scott, all,
yes, Adopt Open JDK 8 LTS is supported at least untile September 2023 [1]
And weirdly JDK 11 LTS at least until September 2022 (one year less???). I
guess all is in the at least :)
Thinking about this a bit more I second to stay with Open JDK 8 LTS for release
branches 17.12, 18.12 and trunk for now.
I understand concerns for releases, but for the trunk I don't see the necessity
to wait. Even for R18, after OFBIZ-10757, the switch is so simple:
Index: build.gradle
===================================================================
-sourceCompatibility = '1.8'
-targetCompatibility = '1.8'
+sourceCompatibility = '11'
+targetCompatibility = '11'
It's a bit harder when you have to maintain different OFBiz versions (using different Java versions) on the same machine. You have to switch Java.
Anyway, that can be automated, as Taher suggested.
Professional users/ companies have a very conservative update strategy for base technologies like the JDK and we should support it as long as it is
reasonable.
Should our behaviour on base technologies be conditioned by our users?
So, my suggestion would be to introduce Adopt Open JDK 11 LTS with the release branch 21.x, meaning that we change to JDK 11 right before the
release branch will be created. This gives us plenty of time to test with Java 11 and we can introduce Java 11 features in the trunk after that. So
release branch 22.x would be the first to depend on Java 11.
What do you think?
As a gut feeling, I think it's unreasonably too conservative :) How do you test Java 11 and related changes (with plenty of time) if you don't
introduce it in at least trunk?
BTW, we have not yet released R17 (for reasonable reasons I'll not discuss here) and I agree it should stay with Java 8, which I must remind started 5
years ago, because R17 will be our next stable for years.
If we want to test Java 11 nothing better than switching to it ASAP. The more we will use and demonstrate (think demos, the spiders bots are working
for us there) it the more confident we will be (if ever we have concerns, I have not much, if not none).
In other words I don't the see need to wait for years for trunk and maybe R18.
Now some facts and reminders:
1. We know Java 8+ versions don't add much from a language perspective (thanks
Mathieu for the detailed list).
The module thing is important but not from a language perspective. It's
important for production, bandwidth, disk space and RAM. The rest is
almost anecdotal, isn't?
2. It's easy to switch locally, Taher give us an example, we can use something
similar on Windows
3. We could use the same in demos which is the only location where we really
stay or not with Open JDK 8 LTS. The rest is virtual (people do what
they want)
With all that said, the devil is in the details and it's obviously easier and more comfortable to stay with Java 8. At least as long as nothing proves
the contrary. I think about security, the module thing could prove to be useful in the futur on that aspect[1]. You never know what hackers will be up to.
So as you can see I have not a strong opinion, just that I find hard to swallow
waiting 2 years more.
I'm not sure why I have this feeling (is that childish? Is the Java community
childish wanting to push new things?). So on the other hand why not waiting?
@All, of course I wait your arguments :)
[1] https://www.oracle.com/corporate/features/understanding-java-9-modules.html
notably:
Strong encapsulation—The packages in a module are accessible to other
modules only if the module explicitly exports them. Even then, another
module cannot use those packages unless it explicitly states that it
requires the other module’s capabilities. This improves platform security
because fewer classes are accessible to potential attackers. You may find
that considering modularity helps you come up with cleaner, more logical
designs.
Jacques
Best regards,
Michael Brohl
ecomify GmbH - www.ecomify.de
[1] https://adoptopenjdk.net/support.html
Am 15.04.19 um 00:07 schrieb Scott Gray:
My understanding was that openjdk would support java 8 until 2023.
In the past our strategy used to be that we should ensure the code base
would operate on newer java versions but keep our minimum required version
as low as possible. That effectively allows users to run whatever version
they like. So unless there are some compelling new features in java
9/10/11 that we think we must have, I'd prefer it if we kept our minimum
supported version as low as possible.
For myself, all client projects are still running java 8 (openjdk) so
before I could continue contributing to OFBiz I would have to figure out
how to run both versions on my machine with minimal disruption. Since I
don't have a huge amount of spare time, I would probably just put it off
for quite a while and work on other things.
I'm not trying to veto the idea, if the community wants to proceed then it
should but I doubt I'm the only contributor we'd be putting another hurdle
in front of.
Regards
Scott
On Mon, 15 Apr 2019 at 09:09, Taher Alkhateeb <slidingfilame...@gmail.com>
wrote:
Well, I could be mistaken but it seems EOL for java 8 is coming soon (2019
commercial 2020 personal) [1]. This seems to be the case because the new
LTS is out which is java 11.
Also this new release model from oracle seems to be annoying which is
pushing developers to adopt the openjdk instead. So I guess the reason for
the upgrade is to strike two birds with one stone: upgrade java and switch
to openjdk.
With that being said, I don't have a firm opinion on upgrading and I just
wanted to highlight things, I leave it to other folks to decide.
[1] https://www.oracle.com/technetwork/java/java-se-support-roadmap.html
On Sun, Apr 14, 2019, 10:38 PM Scott Gray <scott.g...@hotwaxsystems.com>
wrote:
That would probably halt any further contributions from me in the short
to
medium term.
Can I ask why we need to require 11 when 8 is supported through to 2023?
Regards
Scott
On Sun, 14 Apr 2019, 23:37 Jacques Le Roux, <
jacques.le.r...@les7arts.com>
wrote:
If nobody disagree, I'll make the last move (ie ask for Java 11 in
build.gradle) in 3 days
Jacques
Le 13/04/2019 à 12:34, Nicolas Malin a écrit :
On 13/04/2019 11:47, Jacques Le Roux wrote:
I just tested, without surprise the trunk HEAD works with Java 11
I did the same with 18.12, works fine
Nicolas
