When googling tutorials, I see the same material I found 12 years ago. A lot must have happened since then.
What's a good resource to learn Java for somebody who already knows how to program? I'm interested in ecosystem, tooling, best practices, common pitfalls etc.
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'.
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
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.
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!
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.
Reactive is probably a mistake with loom looming around the corner.
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.
It might not be the trendiest, but it's definitely the most popular (as in "in demand").
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)
The real damage that Oracle caused by their Android lawsuit, and by their JDK licencing scheme change, will reverberate for long time.
> 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.
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.
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.
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.
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.
Interesting use of the word 'just'. At the risk of making readers feel old... Java 8 was released _6 and a half years ago_.
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.
As for guice, my preference for reflective runtime injection is Weld since it's the standard reference implementation.
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 did forget about the cache's though! Good call.
Protobuf (another Google Java product) also made big breaking changes in libraries between 2 and 3.
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.
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.
- 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]
[1] https://www.marcobehler.com/guides/a-guide-to-java-versions-...
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.
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).
For Spring, Jakarta EE, Micronaut or Quarkus the docs of their respective websites is enough.