Oracle Java release model changes and consequences for the project
Locked
12
12
Re: Oracle Java release model changes and consequences for the project
 
|
Hi Taher,
I would prefer if you start a new thread for this because it's a complete new topic. If it turns out that the community wants to work on a Java 11 update, I would file an umbrella task for it and your issue OFBIZ-9972 would be a sub-task (not the only one I think) of this. Thanks you, Michael Brohl ecomify GmbH www.ecomify.de Am 28.07.18 um 11:29 schrieb Taher Alkhateeb: > I see. well this means we have to do multiple things: > > - First we need to upgrade gradle > - I have no preference with release 17 Java version support > > Now the problem with upgrading gradle in a nutshell is that you can no > longer have spaces in server commands. So ./gradlew "ofbiz --start" > will not work because of the space between "ofbiz" and "--start" and > that's why I created a JIRA for this issue [1]. I'm not sure what is > the best solution, one idea that came to me is perhaps to pass the > args to a string. So for example: > > ./gradlew ofbiz -Pcmd1="--load-data readers=seed" ofbiz > -Pcmd2="--start --portoffset=10000" > > Maybe another option is to just run one "ofbiz" task and then pass > multiple commands each in a project paramter -Pcmd1= -Pcmd2= -Pcmd3= > ... Another option is to hard wire all commands like we did back in > Ant days. > > I'm not sure what is the best solution there, and I don't mean to > hijack this thread, but one thing depends on another thing. Should we > start a new thread for that? Collect ideas from the community? > > [1] https://issues.apache.org/jira/browse/OFBIZ-9972 > > On Sat, Jul 28, 2018 at 11:47 AM, Michael Brohl > <[hidden email]> wrote: >> Because OpenJDK is the base for the Oracle JDK and Oracle is working on Open >> JDK, I assume we will have the same problems. It can also be that the two >> will be one product soon. Why should Oracle support Open JDK with long term >> updates for free? >> >> I did not find a clear roadmap for Open JDK so it's unclear to me how long >> the versions will be supported. >> >> I think Linux distributions will follow the LTS release cycle also, because >> of the same reasons. Here's a statement for Red Hat: >> https://access.redhat.com/articles/1299013 (at the bottom). >> >> Most sources of information describe the Open JDK as a reference >> implementation which is less stable than the Oracle JDK. >> >> Personally, I have almost no experience using Open JDK in productive, >> professional environments. There were problems years ago which I do not >> remember exactly and we use Oracle JDK since then. >> >> I think we should support Oracle JDK because professional users most likely >> will use it and it would be a bad sign if OFBiz shows no official support >> for it. >> >> I also don't like the release model but the costs are moderate and using the >> LTS version, there is no headache feature wise. Java 11 LTS will be stable >> until 2023 or 2026 if you choose the extended subscription. Lots of time to >> prepare for the next LTS version... >> >> Best regards, >> >> Michael Brohl >> ecomify GmbH >> www.ecomify.de >> >> >> Am 28.07.18 um 10:06 schrieb Taher Alkhateeb: >> >>> I am beginning to wonder if we should consider moving to OpenJDK. I think >>> I >>> really dislike this release model with all the extra costs and headache >>> involved. >>> >>> Are we stuck with Oracle JDK? Does anyone know of limitations or problems >>> with OpenJDK? I vaguely remember font problems with the BIRT plugin but I >>> cannot recall any serious issues. >>> >>> On Sat, Jul 28, 2018, 10:56 AM Michael Brohl <[hidden email]> >>> wrote: >>> >>>> Hi devs, >>>> >>>> a quick heads up for this topic. >>>> >>>> After following the release strategy and thinking more about it, I think >>>> that most users will go with a subscription model and subscribe for an >>>> LTS version. The costs are moderate [1] and I assume that few users will >>>> go through a repeating 6 month "early access - update - test - go live" >>>> circle for free Java versions. >>>> >>>> Java 11 EA is available [2] so we could start to test with it. >>>> >>>> The latest Intellij Idea already has support for Java 11, I suppose that >>>> it will come for Eclipse Photon shortly also. >>>> >>>> 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? >>>> >>>> Best regards, >>>> >>>> Michael Brohl >>>> ecomify GmbH >>>> www.ecomify.de >>>> >>>> >>>> [1] >>>> >>>> >>>> http://www.oracle.com/technetwork/java/javaseproducts/overview/javasesubscriptionfaq-4891443.html >>>> >>>> [2] http://jdk.java.net/11/ >>>> >>>> >>>> >>>> >>>> Michael Brohl >>>> Geschäftsführer >>>> >>>> Fon +49 521 448 157-91 >>>> Fax +49 521 448 157-99 >>>> Mobil +49 160 3664918 >>>> Xing xing.com/profile/Michael_Brohl >>>> LinkedIn linkedin.com/in/michaelbrohl >>>> >>>> Company and Management Headquarters: >>>> ecomify GmbH, Gustav-Winkler-Str. 22, 33699 Bielefeld, Deutschland >>>> Fon: +49 521 448157-90, Fax: +49 521 448157-99, www.ecomify.de >>>> >>>> Court Registration: Amtsgericht Bielefeld HRB 41683 >>>> Chief Executive Officer: Martin Becker, Michael Brohl >>>> >>>> Am 29.01.18 um 17:21 schrieb Michael Brohl: >>>>> Hi devs, >>>>> >>>>> this is just an initial information and dicussion starter to make >>>>> everyone aware of this: >>>>> >>>>> the Oracle Java release model is changing from a feature based to a >>>>> time based model [1]. One major drawback is that there will be no more >>>>> public patch releases for older versions once a new release is >>>>> published, if I understand correctly. >>>>> >>>>> We'll have to discuss if this affects the project in terms of support >>>>> for the latest public Java releases. If we want to stay up-to-date >>>>> according to the public releases, we'll have to establish a process to >>>>> early check the new features and changes of a coming release and maybe >>>>> release more often. >>>>> >>>>> We might even have to support the latest Java release along with the >>>>> current LTS release to cover both users with and without commercial >>>>> support? I'm not sure. >>>>> >>>>> What do you think? >>>>> >>>>> Best regards, >>>>> >>>>> Michael >>>>> >>>>> [1] https://www.azul.com/java-stable-secure-free-choose-two-three/ >>>>> >>>>> >>>>> >>>> >> |
smime.p7s (5K)
Re: Oracle Java release model changes and consequences for the project
|
|
Re: Oracle Java release model changes and consequences for the project
|
|
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 |
Re: Oracle Java release model changes and consequences for the project
|
|
Re: Oracle Java release model changes and consequences for the project
Administrator
|
Re: Oracle Java release model changes and consequences for the project
|
|
Re: Oracle Java release model changes and consequences for the project
|
|
Re: Oracle Java release model changes and consequences for the project
|
|
Re: Oracle Java release model changes and consequences for the project
|
|
Re: Oracle Java release model changes and consequences for the project
|
|
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. Since Java 8 is LTS there, we do not necessarily have to upgrade OFBiz for the use of Java 11. Best regards, Michael Am 13.02.19 um 11:06 schrieb Jacopo Cappellato: > 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> >> 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> |
Re: Oracle Java release model changes and consequences for the project
|
Re: Oracle Java release model changes and consequences for the project
|
|
Re: Oracle Java release model changes and consequences for the project
|
|
Re: Oracle Java release model changes and consequences for the project
|
|
Re: Oracle Java release model changes and consequences for the project
|
Administrator
|
Re: Oracle Java release model changes and consequences for the project
|
Administrator
|
| Free forum by Nabble | Edit this page |