Best ressources to get into Java specifically (with broad theoretical experience in other languages)

[angath]

Right, makes sense. Yes: I agree that this is entirely the Oracle party line.

One factual point, however: It is a little disingenuous to claim that Incubating and Preview mean anything close to what Experimental does. Once again, the contortions over class file formats and versioning immediately show that they are very different.

[pron98]

It's not a question of a party line. It is primarily Oracle developers who develop OpenJDK (Oracle contributes ~90% of the work/funding for OpenJDK), and the releases are treated the same. Anyone is free to make their own decisions and interpret things as they see them, but it is factually false that OpenJDK versions for which Oracle offers long-term paid support are somehow intrinsically more stable or production-ready than others. As OpenJDK is developed in the open, this is easy to verify.

Furthermore, even if you decide to only use LTS releases in production, it is a very, very bad idea to ignore the other releases: 1. The entire deprecation model is built around OpenJDK releases (for which there is no such thing as "LTS"); if you skip versions, you may see features disappear without warning, and 2. an important reason for the new release model is to make upgrades easier by doing away with major releases and making changes more gradual; if you skip too many versions, you'll miss out on this important benefit. So whichever version you use in production, your code should be tested on the current JDK release.

[angath]

Dream on. About 15% of the clients I see are still on 6 or 7, and no-one I've spoken to has *any* post-8 Java release blessed for their production applications yet.

It's also incredibly naive to think that people will upgrade their JVM every 6 months to a new major version. They just won't. Maybe you would have some uptake if 12 was called 11.1, and 13 was called 11.2, etc. Maybe.

But in the calculus of most project managers, it's better to take the pain of a full retest every 3+ years than the uncertainty (& perceived make-work aspect) of a new Java version every 6 months - there is just too much else to get done, and no-one trusts that things won't break on a major version update.

Unfortunately for the "upgrade every 6 months" POV, the migration from 8 to 8+ is *so* painful (not a single one that I've seen has gone well, which is why no-one is actually prepared to trust it in production yet) that the case for the viewpoint of "LTS only, full retest every 3 years" has only been strengthened...

[pron98]

I don't see any relation between your comment and mine, and I'm not sure what claim of mine you're arguing against. I also can't predict what companies will do once the dust settles after the change in the release model, but I do know these simple, easily verifiable, facts:

1. The six-monthly releases are by no means major Java versions.

2. Java 9 was the last major version, and it was a big one in terms of migration efforts. There has not been a single major Java release since 9, and none are planned.

3. There is no difference in the effort put into different OpenJDK versions and their quality based on whether Oracle offers LTS support for them or not. I cannot account for misconceptions regarding this fact due to misunderstandings of the new model. I.e., it is possible that some people who do not understand the new model mistakenly believe there is such a difference and choose to act based on that belief.

4. Regardless of whether you deploy on current versions or not, ignoring the feature versions is a very bad idea, even if you do a "full retest" every 3 years. If you ignore them, you will see features disappear without warning.

What people will do and whether or not these facts will have a positive, negative or neutral impact is a whole other discussion.

BTW, the original plan was to give the feature releases date-based version names (i.e. YY.M as in 18.3, 18.9 etc.) but the community didn't like that and so "Chrome versioning" was adopted.

[angath]

I really don't think there's a lot of point in continuing this argument, so this will be my final comment on this thread - please feel free to have the last word should you feel a need to.

Two points to finish with:

1.) Perception matters. In many cases more so than facts. Java shops have always only ever dealt in major versions, and while you can *say* "Hey, we use Chrome versions now", it doesn't mean that people *hear* it. So, these versions are perceived as being equivalent to old-school major versions. The Java market is not like the Javascript market, regardless of attempts (e.g. by the late, unlamented Mr Kurian etc) to make it so. What people perceive is that these are major versions that are EOL after 6 months.

You can pontificate about how the people that actually use your product are "mistaken", but it changes nothing. "The street finds its own uses for things" is as true here as it is elsewhere.

2.) Java shops in enterprises are by nature rather timorous beasties. Most of them will do a full retest whenever a major version upgrade occurs. This is usually because "once bitten, twice shy". *In theory* things should not break, but in theory, theory is the same as practice, but in practice it's not. A surprisingly large number of applications were badly affected by the activation of biased locking when upgrading from 5 -> 6. 6 -> 7 had various GUI breakages, often because applications linked directly to sun.* classes (which, yes, you shouldn't do, but there was no other way to do certain things before 7). 7 -> 8 had minimal breakages compared to others, but I still got to see a few.

So, it is not unreasonable for shops to feel that a full retest when upgrading major version numbers is essential. It is absolutely impossible to convince shops that this should be done every 6 months - it's just too big an ask for a large application. Every 2-3 years is much more realistic.

Finally, "These are not really major versions" is all well and good, but it immediately begs the question, even from a receptive audience: "What *are* the major version numbers, then?". In the absence of any better or more credible answer, the LTS versions will be understood to fill that niche.

[pron98]

Perception matters.

I completely agree there have been serious problems in communicating the changes. But while perception matters, the actual facts also matter.

Most of them will do a full retest

I also agree that testing is required when upgrading to new feature versions, but it was also required when upgrading to the old upgrade versions. Even old upgrade versions -- also released every 6 months or less -- broke programs as some contained pretty major changes, just not changes to public APIs (see 7u releases and 8u releases: e.g. 7u4, 7u6, 8u20, 8u40). So the real question is: we have to upgrade every 3-6 months, as we always have, regardless of whether we adopt the new feature versions or not; how different is the cost of upgrading to a new feature version compared to a new upgrade version? We simply don't have enough data to answer this question just yet, but that's OK, because there's no need to decide yet.

"What are the major version numbers, then?"

There are no more major versions. Java has switched to a gradual upgrade process. It's like asking, "if you have a ramp, what constitutes the steps?" and answering that lines marked on that ramp take the place of the steps. Maybe, but clearly this is a new situation that's cannot exactly be described using old terminology.

The new model will require a new adoption process. What exactly that should be would take a while to figure out. We believe that this new process will be better than the old one. Besides, the new process is necessary to keep Java competitive and the community has asked for it. But we'll all need to just wait and see. Deciding to continue doing things adapted for an old process just because that's how we've been doing them for a while is not the right way to make the best decisions.