I predict increasing usage of OpenJDK in enterprises!
Arne
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 thatOne 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.
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 thatOne 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.
pay Oracle for Java.
To get support (support way after support for the free versions
has expired).
Or just tradition.
Arne
I've encouraged my employer to upgrade, we're currently running Java 8.
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.
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.
Java running on a client pc from webstart was "pita" to upgrade to 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.
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.
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.
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 494 |
Nodes: | 16 (2 / 14) |
Uptime: | 36:47:24 |
Calls: | 9,741 |
Calls today: | 1 |
Files: | 13,741 |
Messages: | 6,183,534 |