• The non-technical side of Java

    From =?UTF-8?Q?Arne_Vajh=c3=b8j?=@21:1/5 to All on Fri Jan 27 19:48:20 2023
    https://www.theregister.com/2023/01/27/oracle_java_licensing_change

    I predict increasing usage of OpenJDK in enterprises!

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?utf-8?B?SmFzb24gSA==?=@21:1/5 to All on Sat Jan 28 01:08:41 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=c3=b8j?=@21:1/5 to Jason H on Fri Jan 27 20:17:19 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From e.d.programmer@gmail.com@21:1/5 to All on Mon Jan 30 04:07:30 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jason H@21:1/5 to e.d.pro...@gmail.com on Fri Feb 3 13:00:34 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From e.d.programmer@gmail.com@21:1/5 to All on Fri Feb 3 09:22:36 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andreas Leitgeb@21:1/5 to e.d.pro...@gmail.com on Fri Feb 3 18:39:05 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From e.d.programmer@gmail.com@21:1/5 to All on Fri Feb 3 10:59:57 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=c3=b8j?=@21:1/5 to e.d.pro...@gmail.com on Fri Feb 3 14:04:38 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=c3=b8j?=@21:1/5 to Andreas Leitgeb on Fri Feb 3 14:01:52 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)