> A lot must have happened since then.

Yes. As others have said, 'java is stable' which means the old stuff still works. Which in turn means that a lot of people are still using it and still writing blog posts about it. That still makes these old things often obsolete, or needlessly complex and just 'lesser than'. They don't support certain nice features or support them very badly, or have other significant downsides - 25 years of experience does lead to insights, after all.

20 years ago, you loaded your JDBC driver with `Class.forName`. You _STILL_ see this in many examples (and it hasn't been necessary for 15+ years).

These days, you:

* Use a load balancer like hikari * Consider raw JDBC as basically nuts as far as an API goes, and you use JOOQ or JDBI. Or JPA/Hibernate of course, if you don't want SQL/want DB independence and don't think you'll need to performance-tweak queries too much. * You use serializable transaction levels and toss _all_ the code that interacts with DBs into a lambda so that the framework can handle retries for you.

And that's just DBs. As a general trend:

Libraries tend to wax and wane. Right now spring is _very_ popular. JSP is the kind of outdated crud that is just a straight up 'do not use this right now' (even if it still kinda works). For date stuff, use java.time. Libraries in general are more focussed on configure-via-java-code, and dip more into code generation and annotations (example: JOOQ). You don't use The JSONObject API, you use jackson or gson. The list is very long.

I have no particular advice on how to know all this stuff as someone not familiar with the (modern) java ecosystem, though. Just pointing out that 'stable' doesn't translate to 'not much new in the past 15 years'.

2 of 3 Gson maintaners say: "use Moshi". Source: Jake Wharton (1 of 3 Gson maintainers)

Baeldung has decently up-to-date tutorials.

Try kotlin instead of Java, and if you must use java, read the book Effective Java.

If you use kotlin, check out ktorm for db access, http4k for http api’s

Baeldung's content is IMO uniformly quite deficient. If you want examples of how to do things poorly, which examples may or may not compile, or if there's no other alternative, then I guess read the Baeldung article.

Try Scala instead of Kotlin, it's much more powerful, and you can safely avoid the mad Scala libraries jam-packed with symbol infix notation.

Wow, thanks for "JOOQ or JDBI"!

I'm the perfect case of what you sad re. old devs -- I've been using various JVM languages for ~15 years, but still didn't think of replacing JDBC :) Will check those out!

Everything is OpenJDK now, forget oracle. AWS put out LTS JRE's etc. Try and get your employer to pay for a jetbrains IDE, IntelliJ IDEA. Use Maven for builds. It's simple-ish. Use Spring for frameworks. Everything's been done so you wont be first with any problems here. And all the stuff from 12 years ago is probably what people know and do, so it's still on point. No one does inheritance anymore composition's all the rage. Not passing judgement on that, it's just a thing.

> Everything is OpenJDK now, forget oracle.

OpenJDK is the name of Oracle's (one and only) Java implementation project (take a look at the logo at http://openjdk.java.net/). Oracle JDK is the name of the commercially supported product built from OpenJDK, and Oracle also distributes the JDK under a 100% free license (http://jdk.java.net/).

While OpenJDK has been the open-source part of the Sun/Oracle JDK since 2007, Oracle recently completed open sourcing the entire JDK, so that there are no more paid features. The JDK used to be part-free and part commercial, and now it is completely free; you only pay Oracle -- or other companies --- for support if you want it. Other companies contribute to OpenJDK as well, but Oracle still contributes ~90% of the work, and all OpenJDK builds by all vendors are licensed by Oracle. So while you absolutely don't need to pay Oracle (or Sun, as you did before) for using the JDK any more now that it's 100% open, you should at least know that Oracle is the company that (primarily) funds and develops OpenJDK.

(I work on the JDK, i.e. OpenJDK, at Oracle)

There is so much risk associated with anything that Oracle touches, I suspect some very large organizations run the other way without really looking. Instead of Java, they switch to GoLang, and costs be damned.

The real damage that Oracle caused by their Android lawsuit, and by their JDK licencing scheme change, will reverberate for long time.

Well, Google itself heavily uses Oracle's OpenJDK internally (as do Apple, Amazon, Netflix, Facebook, Microsoft, Twitter and many, many others), and have even forked it, contributed to it, and spoke about it at a conference at the Oracle campus [1] -- all at the very height of the lawsuit -- so they clearly aren't concerned. Whatever you think of that lawsuit, the circumstances behind it were so extreme (one company copies over 10KLOC from another in order to directly compete with it in a very lucrative market) that nothing like that had never happened before nor has happened since in the software industry.

> and by their JDK licencing scheme change

The JDK licensing change was that Oracle changed the JDK from part-commercial part-open to 100% open for the first time in Java's history. On the commercial side, the change was from part-upfront, part-subscription to just subscription, which cut the price for customers by a factor of 5, I think.

What's important to remember about Java is that it's huge, and many companies make money off of it, and so companies have an interest creating FUD over Oracle's involvement. I can't speak for other parts of the company, but there's near consensus among Java users that Oracle has been a better steward of Java than Sun, both in terms of technical investment as well as licensing.

[1]: https://youtu.be/DjOcfkhTZkM

> Use Spring for frameworks.

Or Dropwizard if you want microservices that are more light weight and performant than Spring.

https://glennengstrand.info/software/performance/springboot/...

Or Vert.x or Play if you want to code reactive microservices.

https://glennengstrand.info/software/architecture/microservi...

> No one does inheritance anymore composition's all the rage.

Hmmm, that is oversimplification IMHO. When OOP first gained popularity, there was a lot of emphasis on inheritance. Inheritance got misused resulting in systems that became too rigid to change over time. The proverbial pendulum has swung the other way resulting in this sentiment of "no one does inheritance anymore" but inheritance is still very powerful and productive provided that you learn how to use it correctly. Think of inheritance as an advanced feature best left for more senior engineers to use.

Never use Play imo. Especially if your focus is Java (the language). It doesn't offer a modern workflow or java idioms at all. Not to mention it's dependence on scala and sbt which is its own special hell.

Reactive is probably a mistake with loom looming around the corner.

Personal anecdote: I am currently on the job hunt and literally every single position that requires Java also requires experience with Spring (Boot).

It might not be the trendiest, but it's definitely the most popular (as in "in demand").

Yeah, that’s horrible. It’s like Spring Boot is the holy grail or something. People should really invest time in researching other frameworks.

Spring Boot has historically been resource-hungry, but that's changing quite quickly.

Modulo usual caveats about not promising anything and safe harbours and forward-looking statements, VMware is interested in Spring efficiency up to a very high level in the org chart. Watch this space.

Disclosure: I work for VMware.

This is almost exactly my experience. IntelliJ is great, I would also add VSCode, MSFT has always made great dev tools. Spring is the standard everywhere basically. I almost never see features past Java 8-ish being used, so your 12 years ago remark is right on.

I find gradle nicer than maven, though it can be more complex.

Does maven still have issues with snapshot builds and classpaths?

I've managed to avoid Spring, everyone I know that's worked with it complains it's difficult to work with.

For microservices I like simple, single-purpose pieces like sparkjava.

As a counterexample, springboot is the quickest thing to get start and yet allows you to do complex stuff. I for one, love it.

> springboot is the quickest thing to get start

What do you mean by this? Startup times, or developer onboarding?

Because I've had this conversation before if the latter. To me, Spring seems like the last gasp of "Enterprise" Java. Too much is implicit and obscure (aspect-oriented programming is an anti-pattern, IMHO), too much is configured (yuck, XML).

Each to their own I guess.

Developer onboarding. Have not used XML for springboot in ages. And aspects - very very rarely if at all.

Other than Effective Java, I recommend looking at some of the Google libraries, specifically Guava [1] and Guice [2] for dependency injection.

Java is fundamentally a slow adopter of new techniques (it just got lambdas in JDK 8), but a lot of the Google libraries fill in the gaps.

Note that if you are learning Java for Android development, that's a whole different sub-discipline. In that case I recommend the Android tutorials since most of the work is dealing with the Android SDK.

[1] https://www.tutorialspoint.com/guava/index.htm

[2] https://www.baeldung.com/guice

> (it just got lambdas in JDK 8)

Interesting use of the word 'just'. At the risk of making readers feel old... Java 8 was released _6 and a half years ago_.

Point taken. For some reason, a lot of the code work i've encountered is tied to JDK 8. Might be due to it having LTS until 2018 [1].

It could be anecdotal, but I've found in practice vendors and companies are conservative about their JDK upgrades. I haven't seen anything prior to JDK 6 in a while, but I don't think the upgrade cycle is as fast as say, python minor version upgrades.

[1] https://en.wikipedia.org/wiki/Java_version_history

Maybe as a point of comparison (I wondered): C# got them in C# 3.0 in 2007.

Many Java shops are only just upgrading to JDK 8 though.

You're making me feel old, and I'm not even old. Or perhaps I should blame codebases that are still trying to be Java SE 1.6 compatible…

Java got lambdas in the most recent quarter of its development.

I would recommend against guava in any modern form of Java. It doesn't provide much over the standard library.

As for guice, my preference for reflective runtime injection is Weld since it's the standard reference implementation.

I would still recommend Guava for immutable collections, and for the caching classes, both of which are much better than trying to piece things together on your own.

There are a lot of features that have been subsumed into the JDK, and you should usually prefer the JDK implementation where available. Guava has deprecated the redundant functionality, so if you pay attention to your IDE you will be fine.

I'm not really obsessed with immutability. Does Collections.unmodifiable{List,Set,Map,Collection} not do it for you?

I did forget about the cache's though! Good call.

Guava's immutable collections are superior to Collections.unmodifiable which just wraps the collection in a delegating class that will throw an exception if any of the modifying methods are called. Guava's classes are their own implementations, this is particularly notable for Guava's ImmutableSet which has significantly better memory usage than HashSet. Partially owing to how lazily Java's HashSet is defined, which is a wrapper around Java's HashMap. Meaning that for each element in a HashSet you get an unnecessary Map.Entry wrapper, along with its references. The difference is quite noticeable if you have a set with ~400k Integers. At a certain point, you should also move on to something like Trove, but the guava immutable classes are nice in that you still get the collections interfaces.

JDK 8 was released march 2014, so "just got lambdas" should be read as over 6 years ago...

Yeah, it is up to JDK 15 now

Knowing what Guava offers is useful, but I try to avoid it, especially in libraries, because it has a history of breaking changes. The Apache Commons libraries are versioned better and a little more focused.

Protobuf (another Google Java product) also made big breaking changes in libraries between 2 and 3.

Broadly I agree, but JDK 8 was released in 2014, so while Java is certainly conservative you're overplaying it there.

The relatively recent adoption of the 6 monthly release cadence is helping a lot - particularly with the small feature additions that used to get stuck behind the release train.

As someone who recently did that after ~8 years, I found it useful to skim through Modern Java in Action. It should be pretty easy read if you've been doing more modern languages, but important to learn Java semantics and nuances. Also, I highly recommend Java Concurrency in Practice, but it's a tougher read.

That said, for most orgs, the biggest changes you might see would be in libraries and frameworks used. There will most likely be less XML, better build tools and more modular library usage than 12 years ago.

I was in a similar position a couple of years ago. I recommend the book "Core Java for the Impatient" by Cay Horstmann. The printed version is for Java 8 but there is a preview available for Java 11. It's a concise book but it covers all the important bits.

Regarding the "bite the bullet". I was also a bit afraid, but Java is a great language. Yes, it's a bit verbose but that's compensated by its amazing tooling, specially IntelliJ IDEA.

Tooling doesn't make the language great. Java is still objectively worse than many other languages, especially Kotlin.

Your "objective" view is very subjective... A comment from above (yagodragon): "I think that Java is seriously being downplayed by HN crowd."

There’s nothing that makes a programming language good or bad - they all can do the job. It’s a matter of personal preference - Java might be “objectively worse” for you, but it might the best language possible for thousands of other developers.

You'll find many good resources on https://www.baeldung.com/ it regularly comes up in search results and pages appear maintained and for modern versions of libraries.

Now that I have read all the responses in this thread (thank you!) and done some more digging of my own, here are a few more insights I have picked up as a Java-outsider / newbie:

- The current release of Java Standard Edition (SE) is 15; but many applications are still using version 8 or something in between.

- The enterprise version (EE) of Java is now called Jakarta and part of the Eclipse foundation [0] Focus on Cloud Native (Kubernetes, Docker ...)

- naming schemes: Java 1.8 is just Java 8, Java 1.11 is Java 11 etc.

- the versioning cadence of Java has changed with version 10 (in 2018) from "every few years" to "twice a year", that's how we got to version 15 in such a short period of time.

- The officially recommend way to build Android apps today is in Kotlin, but there is still support for Java.

- The JDK is used for developing apps in Java, the JRE just to run those apps. The two seem to be converging: everybody just downloads the JDK. The JDK contains a debugger, a shell, a document generator a compiler etc.

- OpenJDK: the project containing the Java source, is available in two builds OpenJDK and OracleJDK (the difference seems to be in commercial support from Oracle, not in code / functionality). Oracle is the primary contributor to OpenJDK [1][2]

[0] https://jakarta.ee/

[1] https://www.marcobehler.com/guides/a-guide-to-java-versions-...

[2] https://openjdk.java.net/faq/

> A lot must have happened since then.

Not really. That’s the point of Java. It’s stable.

Check the Wikipedia page on Java history to see the handful of new features then just look for tutorials on those that you need to use. Most of these features are things you can pick up as you go.

At least two significant things happened:

1) It finally got anonymous functions in Java 8, so you no longer have to use anonymous classes and complicated design patterns as substitutes.

2) The distribution model changed from targeting a preinstalled JRE to bundling your own runtime with jlink and jpackage (i.e. the same as native applications and .NET Core).

Right, these are both one-day study exercises I think to come up to speed. Java's designed like this - almost everything is additive and builds on the same principles.

I think it might take a little more than one day to fully understand Java 8's new features around lambdas and streams.

I recommend Effective Java, the third edition is updated for Java 9 I believe and Java Concurrency in Practice for the core parts of the language.

For Spring, Jakarta EE, Micronaut or Quarkus the docs of their respective websites is enough.

Here you go: https://news.ycombinator.com/item?id=24142626

Try https://www.baeldung.com/