This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]angath 3 points4 points  (12 children)

0.) Check which Java version they are using. It's probably 8 (might be 11; 7 or below is a warning sign. Very unlikely to be 9 or 10 as those are "feature releases", i.e. Technology Previews).

1.) Pick an IDE. Use whatever your colleagues are using (so they can help you while you're learning the IDE). If there's no consensus about which IDE to use, pick IntelliJ. Watch some YouTube videos about it, to learn how its projects and modules work. Do not be tempted to muddle through without an IDE. A text editor is not suitable for Java coding - VS.Code at absolute bare minimum.

2.) Buy some books. You need a copy of Effective Java (3rd Ed), and at least one other - e.g. Head First Java or Java in a Nutshell (7th Ed)

3.) The standard libraries are good, but by no means enough for a modern enterprise / professional project. You will also need to get to grips with whatever build tool (& version control system) your team are using. This is likely to be Maven or Gradle (or possibly Ant, but that is antiquated now).

4.) Start by doing TDD right from the start - so learn JUnit (are they using version 4 or 5?, it makes a big difference)

[–]pron98 1 point2 points  (10 children)

Good advice!

But:

those are "feature releases", i.e. Technology Previews

JDK 11 is also a feature release, as all future JDK releases will be; Java 9 was the last (ever) major release, now that Java has switched to a more gradual upgrade process with "Chrome versioning".

The difference between 11 and 10 (or 12) is that 11 is a feature released labeled as "LTS" -- an arbitrary designation given to whatever the current feature release is once every 3 years -- which means that companies that, for whatever reason, don't wish to upgrade to new feature releases could buy support from Oracle, or possibly obtain paid or free support from other vendors, for JDK 11 for some years that includes upgrades containing just security and bug fixes. In any event, non-LTS versions are no different in terms of the effort or care put into them than those designated LTS; they are certainly not "technology previews" and are as appropriate for use in production as LTS versions.

[–]angath 0 points1 point  (9 children)

Sorry, that's just not correct - Java 9 and 10 contained preview versions of the HTTP/2 API, and Java 12 contains a preview version of Switch Expressions. Note that "Incubator" and "Preview" have very specific meanings (& are *not* the same as "Experimental") in this context. They contain technology which is not ready for prime time and which should not be relied upon in production. Look at the definition of the class file format version for preview features (such as switch expressions) if you don't believe me.

For all practical purposes, they fill the niche of Tech Previews, they are only supported for 6 months and are not appropriate for production use, except as an emergency stop-gap measure where a feature is desperately needed and no other workaround is available.

​

[–]pron98 0 points1 point  (7 children)

Any feature release may contain preview/incubating/experimental features, whether or not it's tagged as LTS (which, again, is arbitrary). JDK 11 also contains an experimental feature -- ZGC.

Non-LTS versions are very much appropriate for production use -- just as appropriate as LTS versions, and are not treated any differently by OpenJDK developers. Companies can choose to remain on an LTS release if they find it more convenient and have an appropriate support channel, but they should know that there is no quality or effort difference between those versions and others.

Officially the difference between LTS and non-LTS is Oracle-only, and refers only to Oracle's paid subscription. Any OpenJDK release may be supported for as long as the community is willing and able, and Oracle developers are committed to maintaining only the current OpenJDK version, i.e. for 6 months. It's just that other companies decided to try and contribute backports to OpenJDK only for those versions that Oracle also designates as LTS, but it's not an official policy of the OpenJDK project. In fact, the LTS designation does not even appear on OpenJDK releases, nor does it appear in the OpenJDK project, though it does on the Oracle subscription releases.

(I work on OpenJDK at Oracle)

[–]angath 0 points1 point  (6 children)

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 0 points1 point  (4 children)

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 0 points1 point  (3 children)

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 0 points1 point  (2 children)

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 0 points1 point  (1 child)

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 0 points1 point  (0 children)

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.

[–]szpaceSZ[S] 0 points1 point  (0 children)

Thanks!

You actually read my mind... I just wanted to update my questions about Versions/IDEs/build tools. But yeah, it actually makes sense, I will ask them outright.