• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Rob Spoor
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Henry Wong
  • Liutauras Vilda
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Tim Holloway
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Mikalai Zaikin
  • Piet Souris

Is Java moving too quickly for the open source market.

 
Ranch Hand
Posts: 294
Mac Eclipse IDE Safari
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
With the new release schedule for Java is has become very apparent to me that it's becoming almost impossible to keep pace with it. Like many people, I have an Open Source project which depends on a lot of 3rd party libraries and I have to upgrade your java JDK in line with the lowest version of Java required by my dependencies.

For one I have only just managed to migrate from Java 8 to Java 11 and while I was doing that long and painful migration another 2-3 versions of Java were released.

Perhaps the migration from 8 to 11 was the biggest change I will have to encounter - but I have to admit at this stage I don't know.

When you look at various sources for the most common version of Java being used I think Java 8 is still top which kinda reinforces my concern.

Should backwards compatibility be more important?

I was wondering what other people's opinions are.

Dave
 
Saloon Keeper
Posts: 8589
71
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Java has, for the last 6+ years released version in an orderly fashion in a plan that was published. In September version 17 is due for release and that will be an LTS (long term support) version. As of now, that's the last "planned" release documented in Wikipedia. I'm sure others will follow but the path is not clear to me.

I'm one of those that always downloads the latest when it's available. It has meant that my various projects only require minor tweaks (if any) rather than one catastrophic event. Keeping up with the learning curve has been more difficult though. A drawback to doing this is that anywhere that my projects are needed to run will require that the latest be installed.

Should backwards compatibility be more important?

Do you mean being able to run your Java programs on older versions, like 11? Depends somewhat on how much influence you have on the run-time environments. If it is up to remote customers, they'd never want to upgrade. It would seem reasonable to me to expect an environment to have whatever was the latest LTS version, which is 11 now and will be 17 in September.

Another issue is that the licensing agreement changed along the way. It didn't impact me because I consult, but it does impact project managers. Which version may become a business decision.
 
David Garratt
Ranch Hand
Posts: 294
Mac Eclipse IDE Safari
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I would like to run my application under the latest java versions, but I'm not able to at the moment. I actually bundle the JRE with my application so I am not dependent on the users system - but it does mean I cannot keep abreast of the latest JDK features which is a shame.
 
Carey Brown
Saloon Keeper
Posts: 8589
71
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
 
David Garratt
Ranch Hand
Posts: 294
Mac Eclipse IDE Safari
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I use a lot of 3rd party libraries but one good example would be JasperReports which includes a huge number of jars.
 
Saloon Keeper
Posts: 13280
292
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To take away some of your worries, 8 to 11 WAS a huge upgrade. Java 9 was delayed several times because vendors of application containers couldn't adapt so quickly. Java 11 to Java 17 will be much much smaller in comparison.

With the start of Java 9, they release a new version of the language every six months. As Carey pointed out, most of those are small updates that don't have long term support. If you don't want to use non-LTS versions, that's fine. In fact, I would strongly recommend against requiring non-LTS versions in your project if it's meant for redistribution. Think of non-LTS versions as open betas where developers have the chance to play with the new features before they're released "for real".

Pick a platform and choose your dependency versions accordingly. Don't choose a platform based on your dependency versions.
 
Saloon Keeper
Posts: 7100
165
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm involved with an open source web app, and we're targeting Java 8. The reason being, the software will often be used in a shared hosting environment where Java 8 is frequently the newest platform available. That is slowly changing towards Java 11, though, so maybe by next year we'll make that the baseline.
 
David Garratt
Ranch Hand
Posts: 294
Mac Eclipse IDE Safari
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

the software will often be used in a shared hosting environment where Java 8 is frequently the newest platform available



You have touched on an issue which I am facing as well. My app has many components, a swing desktop app, background services and also a servlet for mobile scanners. As far as I know it's not possible to specify a private JRE for Apache Tomcat. I would like to run 2  instances of my Servlet (old and new) with Apache Tomcat using Java 8 on one of them and Java 11 on the other. My desktop app uses a private JRE so I can accommodate it there - it's just the web side which is a bit of a problem.

Dave
 
Stephan van Hulst
Saloon Keeper
Posts: 13280
292
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's probably easiest if you run two separate Tomcat instances.
 
Saloon Keeper
Posts: 24325
167
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The Java ecosystem was designed NOT to be goldfish-style, a là Microsoft, but stable, like IBM mainframe COBOL. If you're being forced to upgrade compilers because of dependencies, your project is probably incorrectly defined, There's a reason why Maven and Gradle project definitions have a version identifier for each dependency. You should never define dependency versions open-ended.

Thanks to the backwards compatability of Java, I normally expect that I can take source for a project built for Tomcat 4 under Java 5 10 years ago, run a build, get a clean compile and probably have it execute unmodified under Tomcat 9.

Tomcat, incidentally, like every JEE server product, runs each instance in a separate JVM and unless it's running embedded (Spring Boot, for example), is the sole owner of that JVM. Networking constraints mandate that each running Tomcat instance own a different set of network ports, but once that is allowed for, you can run as many Tomcat instances on a single machine as you can cram in.

It's good to keep up with progress in the Java language - and libraries - but that should be something done on your schedule, and not because you've been forced to because you're running the "Red Queen's Race".

 
Marshal
Posts: 22453
121
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:With the start of Java 9, they release a new version of the language every six months. As Carey pointed out, most of those are small updates that don't have long term support. If you don't want to use non-LTS versions, that's fine. In fact, I would strongly recommend against requiring non-LTS versions in your project if it's meant for redistribution. Think of non-LTS versions as open betas where developers have the chance to play with the new features before they're released "for real".


The only difference between an LTS version and a non-LTS version is the period of time during which patches are released. For non-LTS versions like 12 to 16 that's 6 months with probably 1 or 2 patches; for LTS versions that's (at least) 3 years with more patches (current patch for Java 11 is 11).

New features come in three variants:

1) Small library features. These are well thought through (with sometimes long mailing-list discussions before they are integrated), and therefore can be shipped when they're ready. Examples: Stream.toList() (since Java 16), InputStream.transferTo(OutputStream) (since Java 9).

2) Larger library features (often complete modules). These go into a jdk.incubator.xxx module; that was done with java.net.http (incubator status in 9 and 10, final in 11) and jdk.jpackage (incubator status in 14 and 15, final in 16), and is now done with jdk.incubator.foreign (incubator status in 14 to 16, final in 17?) and jdk.incubator.vector (incubator status in 16).

3) Language features like switch expressions are delivered as experimental features for (at least) 2 releases, during which they must be explicitly enabled using compiler and JVM flags. This period of at least 1 year gives Oracle the time to let developers test those features, and make improvements where needed. After this "open beta" period the feature is upgraded to non-experimental or final, and everybody can start using them. Right now only sealed classes have an experimental status; records and instanceof pattern matching have just been made final.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic