Topics

Oracle commercializing Java?

dst_cmp
 

The installer for the new release of Java SE 1.8.0_171 has a link to an Oracle Notice about the Java Roadmap.

The notice states the following (bolded by Oracle):

Public updates for Oracle Java SE 8 will remain available for individual, personal use through at least the end of 2020. 

Public updates for Oracle Java SE 8 released after January 2019 will not be available for business, commercial or production use without a commercial license.

The full notice can be found at https://www.java.com/en/download/release_notice.jsp

What impact might this have on JMRI, LCC and other model railroad products running Java?

David

James Koretsky
 

David,

I suspect that this notice is only applicable to version 8, as it reaches end of life, and we move to version 9.

Those whom have written apps on java 8, that wont work on 9 for the example can license patches for Java 8 after it broad-based support has ended.

The company i work for pays for updates for Java 7, the current version is 7.181 for those that have a valid support agreement.

Regards

James


On Jun 9, 2018, at 9:46 PM, dst_cmp <d.s.taylor@...> wrote:

The installer for the new release of Java SE 1.8.0_171 has a link to an Oracle Notice about the Java Roadmap.

The notice states the following (bolded by Oracle):

Public updates for Oracle Java SE 8 will remain available for individual, personal use through at least the end of 2020. 

Public updates for Oracle Java SE 8 released after January 2019 will not be available for business, commercial or production use without a commercial license.

The full notice can be found at https://www.java.com/en/download/release_notice.jsp

What impact might this have on JMRI, LCC and other model railroad products running Java?

David

Steve Haas
 

 

>>>> I suspect that this notice is only applicable to version 8, as it reaches end of life, and we move to version 9. <<<<

 

>>>> Those whom have written apps on java 8, that wont work on 9 for the example can license patches for Java 8 after it broad-based support has ended. <<<<

>>>> The company i work for pays for updates for Java 7, the current version is 7.181 for those that have a valid support agreement. <<<<

 

To expand a bit on what James states above, this is a very normal step in the evolution of software.  As newer versions are released, _support_ for older versions of the software is eventually withdrawn.  This doesn’t mean that the software itself stops running, rather, it usually means that if a client runs into a problem with the older version of the software there is no longer any support from the software vendor.  This isn’t a problem if the customer’s version of the software is running problem free on their hardware.  

 

You would be surprised to learn how many tens of thousands of small to medium size businesses run on “un-supported” older levels of software.  What they have does what they need it to do and has done so for many, many years.  Given the stability of the software in their environment and the costs of pursuing the appropriate upgrades to other software, many businesses adopt the philosophy of “If it ain’t broke, don’t fix it!”.

 

As Oracle deprecates support for Java 8, the JMRI development team will undoubtably compare and contrast the features between releases 8 and 9.  Unless a particular feature used by JMRI is itself deprecated, the JMRI development team will identify and implement the changes (if any) needed to JMRI to run under release 9.  It is possible that the team will base further JMRI development on the release 9 platform.

 

At any rate, it is nothing for the JMRI user community to worry about.  If/when the time comes, the JMRI team will let you know in plenty of time it is necessary to update your computer to Java 9.

 

Best regards,

 

Steve

 

Steve Haas

Snoqualmie, WA

 

MacRat
 

Hi Steve, James, David, group

For Java 9 it is probably a bit late. Java 9 reached end of support in March 2018. Oracle changed the way Java versions are released. 

The next long term Java release will be Java 11 that is planned to be available in September 2018. Long term means 5 years public support. And after that Java 17.

I found this article giving a bit more information: https://www.azul.com/think-moving-jdk-9-sometime-next-year-think/



Kind regards
Matthias


Am 10.06.2018 um 05:32 schrieb Steve Haas <Goatfisher2@...>:

<snip> 

At any rate, it is nothing for the JMRI user community to worry about.  If/when the time comes, the JMRI team will let you know in plenty of time it is necessary to update your computer to Java 9.
 
Best regards,
 
Steve
 
Steve Haas
Snoqualmie, WA 
 

Mike Dunn
 

Hi Steve H,

 

You say “it usually means that if a client runs into a problem with the older version of the software there is no longer any support from the software vendor.  This isn’t a problem if the customer’s version of the software is running problem free on their hardware. ”; you run the risk that when you move to newer hardware it will fail to work properly or even at all.  This is something I have recently experienced in moving anin-house app off old Sun hardware (it uses Java 6 IIRC) to new Oracle hardware (but still Sparc to Sparc).  While it functions correctly, the speed of operations within the Java aspects have plummeted.  Investigations are underway to find what the latest Java version is we can upgrade to without requiring the app itself needing to be revised.  One would have hoped that the Devs in charge of this would have kept their dependencies updated when making functional revisions, but … !  Another piece of software on the same server (using another version of Java, 7 I think) fails to start at all; fortunately, the company providing that app have replacement code (including an updated version of Java) we can move to quite painlessly.

 

While I agree broadly with you on “Given the stability of the software in their environment and the costs of pursuing the appropriate upgrades to other software, many businesses adopt the philosophy of “If it ain’t broke, don’t fix it!” ”, you seem to minimise the increasing risk of running with old and unsupported software …  While not too bad at the start, it increases greatly as time progresses.  One difference is whether you are buying the code (as in an external application) or developing it in-house.  The former can become something extremely expensive, for example replacing a thousand copies of Office with the next version ; with the latter, then the Devs should be keeping on top of updated dependencies.  It all depends on what you’re dealing with … if mission-critical – keep the thing updated; if not, it’s just a pain when you have issues, not a disaster.

 

Anyway – as the JMRI team seem to keep relatively up-to-date with Java, this is pretty much O/T  J  And even if they weren’t – running model railway is hardly mission-critical !  J

 

Mike


Virus-free. www.avast.com

dst_cmp
 

Thanks to all for the replies, I now understand the intent of the Oracle notice.

It seems software and language versions are changing at an increasing pace to cope with security and technology demands. Tough for developers to keep their apps up-to-date.

David

Michael Piazza
 

The elephant in the room that no one seems to have addressed and was possibly part or all of the intent of the original question is the aspect of the "commercial" license requirement.  In the context of JMRI does that mean that anyone doing JMRI software development require a "commercial" license and even more to the point what will be the cost of the commercial license?

I'm asking this for two reasons.  First, how would that affect open source development? Does that mean there may be costs for you folks working on the core JMRI code? How would you recoup those costs?  Secondly, on a similar vein, Im working on a more up to date throttle app on Android in Java and if I now will have to pay Oracle for the privilege of distributing my app Ill skip the java development and go right to my Rad Studio development where I can use one codebase and generate both Android and IOS apps in native ARM code.  Over the years Ive had to shake my head at Oracle's outrageous greedy pricing strategies and the governments willingness to keep Larry Ellison in new boats.  I knew this day was coming.

Regards,

Mike Piazza

On Sun, Jun 10, 2018, 03:10 Mike Dunn <mike@...> wrote:

Hi Steve H,

 

You say “it usually means that if a client runs into a problem with the older version of the software there is no longer any support from the software vendor.  This isn’t a problem if the customer’s version of the software is running problem free on their hardware. ”; you run the risk that when you move to newer hardware it will fail to work properly or even at all.  This is something I have recently experienced in moving anin-house app off old Sun hardware (it uses Java 6 IIRC) to new Oracle hardware (but still Sparc to Sparc).  While it functions correctly, the speed of operations within the Java aspects have plummeted.  Investigations are underway to find what the latest Java version is we can upgrade to without requiring the app itself needing to be revised.  One would have hoped that the Devs in charge of this would have kept their dependencies updated when making functional revisions, but … !  Another piece of software on the same server (using another version of Java, 7 I think) fails to start at all; fortunately, the company providing that app have replacement code (including an updated version of Java) we can move to quite painlessly.

 

While I agree broadly with you on “Given the stability of the software in their environment and the costs of pursuing the appropriate upgrades to other software, many businesses adopt the philosophy of “If it ain’t broke, don’t fix it!” ”, you seem to minimise the increasing risk of running with old and unsupported software …  While not too bad at the start, it increases greatly as time progresses.  One difference is whether you are buying the code (as in an external application) or developing it in-house.  The former can become something extremely expensive, for example replacing a thousand copies of Office with the next version ; with the latter, then the Devs should be keeping on top of updated dependencies.  It all depends on what you’re dealing with … if mission-critical – keep the thing updated; if not, it’s just a pain when you have issues, not a disaster.

 

Anyway – as the JMRI team seem to keep relatively up-to-date with Java, this is pretty much O/T  J  And even if they weren’t – running model railway is hardly mission-critical !  J

 

Mike


Virus-free. www.avast.com

Bob Jacobsen
 

JMRI has to navigate between several things:

1) Lots and lots of JMRI users want to keep using it on their existing hardware, much of which can only be updated so far. For example, lots of layout PCs can’t go beyond Windows XP.

2) Some JMRI users have or get new hardware, which comes with new versions of software: A user’s new touch-screen layout PC is going to be running Windows 10; I don’t think it’s even possible to run Windows 98 and/or Java 1.6 on it.

3) New versions of Java often have features that make it easier to write code for new features or to fix nagging problems. JMRI went from Java 6 to Java 8 in large part because it wasn’t otherwise practical to provide some of the web and handheld features we now have.

Generally, the JMRI developer community tends to be pretty slow at moving the Java version forward. We stuck with Java 6 until development was _really_ painful because there were Windows 98 and early Mac users who wouldn’t be able to follow to Java 7 or 8. (Java 6 was available in 2006 and supported by Sun until 2014; Java 7 was available in 2011; JMRI moved to Java 8 in July of 2015)

I don’t know what the next step for JMRI will be. As far as I know, no current developers are greatly inconvenienced by sticking with Java 8 for now (though there are a couple things that would make some minor work easier in Java 9 and 10). The earliest JMRI might move to a later version is Fall 2019, and even that might not be likely.

For more information:

http://jmri.org/help/en/html/doc/Technical/TechRoadMap.shtml

Bob

On Jun 9, 2018, at 8:32 PM, Steve Haas <Goatfisher2@...> wrote:

You would be surprised to learn how many tens of thousands of small to medium size businesses run on “un-supported” older levels of software. What they have does what they need it to do and has done so for many, many years. Given the stability of the software in their environment and the costs of pursuing the appropriate upgrades to other software, many businesses adopt the philosophy of “If it ain’t broke, don’t fix it!”.

As Oracle deprecates support for Java 8, the JMRI development team will undoubtably compare and contrast the features between releases 8 and 9. Unless a particular feature used by JMRI is itself deprecated, the JMRI development team will identify and implement the changes (if any) needed to JMRI to run under release 9. It is possible that the team will base further JMRI development on the release 9 platform.
--
Bob Jacobsen
@BobJacobsen

Bob Jacobsen
 

People will have to form their own opinions on all these questions. More information can help:

http://www.oracle.com/technetwork/java/javase/overview/faqs-jsp-136696.html

http://www.oracle.com/technetwork/java/javase/terms/products/index.html

http://www.oracle.com/technetwork/java/javase/eol-135779.html

The key take-away (in my opinion) is from the first link: "The current version of Java - Java SE 9 as well as Java SE 8 - is free and available for redistribution for general purpose computing. Java SE continues to be available under the Oracle Binary Code License (BCL) free of charge. “

JMRI doesn’t use any of the “Commercial Features” that Oracle separately licenses for Java, and I very much doubt it ever will.

I have no idea about best practices for Android development, though I’m sure there are better places than here to get answers on that.

Bob

On Jun 10, 2018, at 9:54 AM, Michael Piazza via Groups.Io <mpiazza2007=googlemail.com@groups.io> wrote:

The elephant in the room that no one seems to have addressed and was possibly part or all of the intent of the original question is the aspect of the "commercial" license requirement. In the context of JMRI does that mean that anyone doing JMRI software development require a "commercial" license and even more to the point what will be the cost of the commercial license?

I'm asking this for two reasons. First, how would that affect open source development? Does that mean there may be costs for you folks working on the core JMRI code? How would you recoup those costs? Secondly, on a similar vein, Im working on a more up to date throttle app on Android in Java and if I now will have to pay Oracle for the privilege of distributing my app Ill skip the java development and go right to my Rad Studio development where I can use one codebase and generate both Android and IOS apps in native ARM code. Over the years Ive had to shake my head at Oracle's outrageous greedy pricing strategies and the governments willingness to keep Larry Ellison in new boats. I knew this day was coming.

Regards,

Mike Piazza

On Sun, Jun 10, 2018, 03:10 Mike Dunn <mike@...> wrote:
Hi Steve H,



You say “it usually means that if a client runs into a problem with the older version of the software there is no longer any support from the software vendor. This isn’t a problem if the customer’s version of the software is running problem free on their hardware. ”; you run the risk that when you move to newer hardware it will fail to work properly or even at all. This is something I have recently experienced in moving anin-house app off old Sun hardware (it uses Java 6 IIRC) to new Oracle hardware (but still Sparc to Sparc). While it functions correctly, the speed of operations within the Java aspects have plummeted. Investigations are underway to find what the latest Java version is we can upgrade to without requiring the app itself needing to be revised. One would have hoped that the Devs in charge of this would have kept their dependencies updated when making functional revisions, but … ! Another piece of software on the same server (using another version of Java, 7 I think) fails to start at all; fortunately, the company providing that app have replacement code (including an updated version of Java) we can move to quite painlessly.



While I agree broadly with you on “Given the stability of the software in their environment and the costs of pursuing the appropriate upgrades to other software, many businesses adopt the philosophy of “If it ain’t broke, don’t fix it!” ”, you seem to minimise the increasing risk of running with old and unsupported software … While not too bad at the start, it increases greatly as time progresses. One difference is whether you are buying the code (as in an external application) or developing it in-house. The former can become something extremely expensive, for example replacing a thousand copies of Office with the next version ; with the latter, then the Devs should be keeping on top of updated dependencies. It all depends on what you’re dealing with … if mission-critical – keep the thing updated; if not, it’s just a pain when you have issues, not a disaster.



Anyway – as the JMRI team seem to keep relatively up-to-date with Java, this is pretty much O/T J And even if they weren’t – running model railway is hardly mission-critical ! J



Mike


Virus-free. www.avast.com


--
Bob Jacobsen
@BobJacobsen

R Morningstar
 

Another reason to keep current with Java is the availability of the quarterly Critical Patch Updates.   The CPUs address security weaknesses and vulnerabilities found in Java.   Many but not all of the issues fixed address Java on the desktop.

Staying current is sound practice, but actually doing it can be very painful for the developers and organizations that need to protect their computing infrastructure but cannot afford to do regression testing every 3 months to test the viability of the latest Oracle CPU.  

What you don't want to do is get so far behind the power curve that you have to fork over $$$ to Oracle to get the CPUs via their extended support contracts.   Our organization is actively investigating moving some of our critical apps off of Oracle Java to OpenJDK.    The time and expense of staying current with Oracle Java is overwhelming. 

We all knew this day was going to come after Sun Micro disappeared into the Oracle fold,  somebody has to pay for Larry Ellison's alimony payments......