Re: Oracle Java release model changes and consequences for the project

[Michael Brohl]

Hi Jacopo,

an alternative would be https://adoptopenjdk.net/ which provides prebuild packages. The scripts for package building are Apache 2.0 licensed and they are providing Java 8 and 11 LTS versions.

Seems a good fit to me.



Best regards,

Michael


Am 13.02.19 um 11:06 schrieb Jacopo Cappellato:

Since Java 8 is LTS there, we do not necessarily have to upgrade OFBiz for the use of Java 11.

Considering that now Oracle JDKs are no more free for commercial use, I
think that as a community we should make it a priority to suggest a
different Java build in the README and other public documents.
The simplest alternative (because it is the closest to Oracle JDK) is the
Open JDK 11 maintained by Oracle and distributed from:
https://jdk.java.net/11/

In my opinion our README should point to it rather than:
http://www.oracle.com/technetwork/java/javase/downloads/index.html
as it is now.
However, before we can do it, we have to resolve:
https://issues.apache.org/jira/browse/OFBIZ-10757
which should not be too difficult to achieve.

Just my two cents,

Jacopo


On Wed, Oct 24, 2018 at 2:21 PM James Yong <jamesy...@apache.org> wrote:

Answering my last question.
 From the download page for Oracle JDK 11, demo purpose is allowed.

On 2018/10/24 07:38:19, James Yong <jamesy...@apache.org> wrote:

Hi all,

Will the release model and licensing changes impact our demos hosted

with Apache Software Foundation?

Regards,
James

On 2018/10/24 06:54:05, James Yong <jamesy...@apache.org> wrote:

Hi all,

OFBiz can be used as an application framework and not all business

use-case justify the yearly price-tag of Oracle JDK. Given that more
products(1) are moving to support OpenJDK, should OFBiz follow?

Regards,
James

(1) See plan of Atlasians product to support OpenJDK

https://community.atlassian.com/t5/Jira-discussions/Java-11-and-OpenJDK-support-for-Atlassian-Server-amp-Data-Center/m-p/872998#M4575

On 2018/07/31 06:35:46, Jacques Le Roux <jacques.le.r...@les7arts.com>

wrote:

Hi Michael,

How (by which mean) do you envision to "actively inform users about

our roadmap", blog, wiki or embedded documentation?

It seems the blog is not reaching all our users (needs attention).

Maybe an initial statement could be used there though.

The wiki is slowly deprecating in favour of the embedded

documentation. So I guess we will use the embedded documentation for
lasting information, right?

BTW All, I want to close OFBIZ-9226 "Check that OFBiz runs and

compile with Oracle JDK 9 (Java 9)" as unresolved and create a new similar
issue for

Java 11, what do you think?

Jacques


Le 28/07/2018 à 13:29, Michael Brohl a écrit :

Hi Mathieu,

my goal is to actively inform users about our roadmap and provide

information on how the project will deal with the new Java release model.
Users

testing OFBiz for their needs in a professional environment also

check if a project has answers to these questions so I am wrapping my mind
around it.

This is just to make clear that I am not eager to switch to newer

Java versions just for the sake of it.

Am 28.07.18 um 12:54 schrieb Mathieu Lirzin:

I wonder if we should base the OFBiz 17.12 release on Java 8 or

Java

11. We have no fixed release date yet so we might have time to

do it.

Another way would be to make a new branch which will support

Java 11.

What do people think?

I think OFBiz should be conservative in its choices.

I agree!

Given the fact Java 11 is not release yet or is about to be

released,

Java 11 will be released as GA in Sept 18. At the same time,

non-subscribed users will get no updates for Java 8 any more.

OFBiz should keep compatibity with the previous LTS release

meaning java 8.  Of course

Yes, you are right. If you focus on subscribed users, they will

get Java 8 support until September 2023 (2026 for extended subscription).

So following my thoughts to assume that users will subscribe, we

can stay with Java 8 for a while.

On the other hand, if we test Java 11 and find that we will have

few issues we can easily handle, it could be a good idea to make the switch
with

release 17.12.

I am open to both (or other) models and would like to hear more

opinions about that.

This does not mean that OFBiz should not be tested with more

recent Java

releases too.

Having an extra branch has a maintenance burden that should be

balanced

with the benefits it provides.  What benefits do you see in

having a

Java 11 branch?

This is just an alternative to the Java 11 update of the next

branch. I do not favor this because of the extra maintenance burden you
mentioned.

In conclusion, we can stick to Java 8, informing our users that

they have to subscribe for further updates.

If we do this, we should think about a roadmap/ process to change

to Java 11 in the future. This could be, for example, set up during the
release

branch 21.x or 22.x to give us enough time.

We should also, in my opinion, check/test for Java 11 and

following versions compatibility in the next months to be able to inform
users about

compatibilities/incompatibilities with this version. Maybe we can

provide some compatibility matrix or else.

Thanks for your thoughts,
Michael

smime.p7s
Description: S/MIME Cryptographic Signature