https://www.theregister.com/2023/01/27/oracle_java_licensing_change

I predict increasing usage of OpenJDK in enterprises!

Arne

People still give money to Oracle for Java?

--
Newsy for iOS
Download on the App Store:
https://itunes.apple.com/app/newsy/id598711199

Arne Vajhøj wrote:
>https://www.theregister.com/2023/01/27/oracle_java_licensing_change
>
>I predict increasing usage of OpenJDK in enterprises!
>
>Arne

On 1/27/2023 8:08 PM, Jason H wrote:
> Arne Vajhøj wrote:
>> https://www.theregister.com/2023/01/27/oracle_java_licensing_change
>>
>> I predict increasing usage of OpenJDK in enterprises!

> People still give money to Oracle for Java?

I believe there are still a significant number of companies that
pay Oracle for Java.

To get support (support way after support for the free versions
has expired).

Or just tradition.

Arne

> I believe there are still a significant number of companies that
> pay Oracle for Java.
>
> To get support (support way after support for the free versions
> has expired).
>
> Or just tradition.
>
> Arne
One way or the other, companies pay for support. Bigger businesses are less likely to use Java from another source. Either they pay for Java directly, or receive support by paying for another Oracle Java based product.
I've encouraged my employer to upgrade, we're currently running Java 8.

On 1/30/23 12:07, e.d.pro...@gmail.com wrote:
>> I believe there are still a significant number of companies that
>> pay Oracle for Java.
>>
>> To get support (support way after support for the free versions
>> has expired).
>>
>> Or just tradition.
>>
>> Arne
> One way or the other, companies pay for support. Bigger businesses are less likely to use Java from another source. Either they pay for Java directly, or receive support by paying for another Oracle Java based product.
> I've encouraged my employer to upgrade, we're currently running Java 8.

Call it a bias but I think it is generally good practice to expunge
Oracle wherever feasible. That doesn't mean not paying support to
anyone. Some of our larger customers were already expressing a
preference for supported RedHat, for example, before we were effectively
forced out of using Centos (by RedHat, oddly enough), so the assurance
of Java support comes with that, along with a lot more.

Java 8 is very sticky. Best of luck.

> Java 8 is very sticky. Best of luck.
So far the only issue I've seen with Java 8 is compatibility. At least a handful of third party dependencies are requiring Java 11 if not 17, so we are recommending using Java 17, I think might get approved soon.
I have tested all our code on 17 and it literally required no changes. At least I haven't seen any security flaws from the dependencies for using the latest version they had compiled for Java 8 so far which is the top issue.

e.d.pro...@gmail.com <e.d.programmer@gmail.com> wrote:
>> Java 8 is very sticky. Best of luck.
> So far the only issue I've seen with Java 8 is compatibility. At least
> a handful of third party dependencies are requiring Java 11 if not 17,
> so we are recommending using Java 17, I think might get approved soon.
> I have tested all our code on 17 and it literally required no changes. At
> least I haven't seen any security flaws from the dependencies for using the
> latest version they had compiled for Java 8 so far which is the top issue.

Server java is likely mostly unaffected.

Java running on a client pc from webstart was "pita" to upgrade to 11.

I had to do it a few years ago. It kind of worked, but in the
end, we're still using Java 8 with IcedTeaWeb from a non-Oracle
support vendor now.

The java 11 compiler (running on solaris) no longer knew about
Windows L&F-classes, and most client dialogs had lots of cosmetic
bugs, where Java didn't work well with desktop enlargement settings:
specifically anything larger than "100%" caused spurious pixel lines
to appear over the dialogs.
Some TextBoxes showed just the middle row of pixels of each character,
etc... The reason might have been a mixture of Swing and AWT, but in
Java 8 that same mixture just wasn't ever a problem.

No budget was offered so far to re-try with some Java >11.

> Java running on a client pc from webstart was "pita" to upgrade to 11.
>
> I had to do it a few years ago. It kind of worked, but in the
> end, we're still using Java 8 with IcedTeaWeb from a non-Oracle
> support vendor now.
>
> The java 11 compiler (running on solaris) no longer knew about
> Windows L&F-classes, and most client dialogs had lots of cosmetic
> bugs, where Java didn't work well with desktop enlargement settings:
> specifically anything larger than "100%" caused spurious pixel lines
> to appear over the dialogs.
> Some TextBoxes showed just the middle row of pixels of each character,
> etc... The reason might have been a mixture of Swing and AWT, but in
> Java 8 that same mixture just wasn't ever a problem.
>
> No budget was offered so far to re-try with some Java >11.
Yeah Java 8 > 11 > 17 has very little issue for the back end of a web server, but Java 8 to 11 is huge for a couple things.
Webstart is sort of dead. The company I used to work for still has everything in webstart and is still running Java 8. The third party software they use, which they haven't upgraded, has their newer stuff on Java 11 with iced tea. Now with Java 17, and adoptopenjdk moving to adoptium, I'm not sure how well iced tea is supported. It seems the whole technology is just not recommended anymore, everyone wants browser based.
Another huge change from Java 8 to 11, I actually developed an offline Swing app that runs as an executable with an embedded JRE. Compiled with Java 8, it was over 70MB, in Java 11 it was about half the size.
Swing has always had issues where video was not 100% scaling. I think newer Java has improved support there, but I haven't done a lot of testing with it.

On 2/3/2023 1:39 PM, Andreas Leitgeb wrote:
> e.d.pro...@gmail.com <e.d.programmer@gmail.com> wrote:
>>> Java 8 is very sticky. Best of luck.
>> So far the only issue I've seen with Java 8 is compatibility. At least
>> a handful of third party dependencies are requiring Java 11 if not 17,
>> so we are recommending using Java 17, I think might get approved soon.
>> I have tested all our code on 17 and it literally required no changes. At
>> least I haven't seen any security flaws from the dependencies for using the
>> latest version they had compiled for Java 8 so far which is the top issue.
>
> Server java is likely mostly unaffected.
>
> Java running on a client pc from webstart was "pita" to upgrade to 11.
>
> I had to do it a few years ago. It kind of worked, but in the
> end, we're still using Java 8 with IcedTeaWeb from a non-Oracle
> support vendor now.
>
> The java 11 compiler (running on solaris) no longer knew about
> Windows L&F-classes, and most client dialogs had lots of cosmetic
> bugs, where Java didn't work well with desktop enlargement settings:
> specifically anything larger than "100%" caused spurious pixel lines
> to appear over the dialogs.
> Some TextBoxes showed just the middle row of pixels of each character,
> etc... The reason might have been a mixture of Swing and AWT, but in
> Java 8 that same mixture just wasn't ever a problem.
>
> No budget was offered so far to re-try with some Java >11.

Java Swing desktop apps is a very small piece of the Java market
today.

Sounds like it was not well tested for Java 11.

Arne

On 2/3/2023 1:59 PM, e.d.pro...@gmail.com wrote:
>> Java running on a client pc from webstart was "pita" to upgrade to
>> 11.
>>
>> I had to do it a few years ago. It kind of worked, but in the end,
>> we're still using Java 8 with IcedTeaWeb from a non-Oracle support
>> vendor now.
>>
>> The java 11 compiler (running on solaris) no longer knew about
>> Windows L&F-classes, and most client dialogs had lots of cosmetic
>> bugs, where Java didn't work well with desktop enlargement
>> settings: specifically anything larger than "100%" caused spurious
>> pixel lines to appear over the dialogs. Some TextBoxes showed just
>> the middle row of pixels of each character, etc... The reason might
>> have been a mixture of Swing and AWT, but in Java 8 that same
>> mixture just wasn't ever a problem.

> Yeah Java 8 > 11 > 17 has very little issue for the back end of a web
> server, but Java 8 to 11 is huge for a couple things. Webstart is
> sort of dead. The company I used to work for still has everything in
> webstart and is still running Java 8. The third party software they
> use, which they haven't upgraded, has their newer stuff on Java 11
> with iced tea. Now with Java 17, and adoptopenjdk moving to adoptium,
> I'm not sure how well iced tea is supported. It seems the whole
> technology is just not recommended anymore, everyone wants browser
> based. Another huge change from Java 8 to 11, I actually developed an
> offline Swing app that runs as an executable with an embedded JRE.
> Compiled with Java 8, it was over 70MB, in Java 11 it was about half
> the size. Swing has always had issues where video was not 100%
> scaling. I think newer Java has improved support there, but I haven't
> done a lot of testing with it.

Browser based is the standard today.

Alternatively switch to Android devices for users and continue
with Java/Kotlin.

Arne