8 ms·
Slightly tangential, but due to a new job I'll have bite the bullet and learn Java. When googling tutorials, I see the same material I found 12 years ago. A l
by mxschumacher 6y ago
Slightly tangential, but due to a new job I'll have bite the bullet and learn Java.
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.
- ivanr 6y agoHere you go: https://news.ycombinator.com/item?id=24142626 https://news.ycombinator.com/item?id=24142626
- krisgenre 6y agoTry https://www.baeldung.com/ https://www.baeldung.com/
- cordite 6y agoYou'll find many good resources on https://www.baeldung.com/ https://www.baeldung.com/ it regularly comes up in search results and pages appear maintained and for modern versions of libraries.
- chrisseaton 6y ago> 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.
- ptx 6y agoAt 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).
- chrisseaton 6y agoRight, 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.
- saagarjha 6y agoI think it might take a little more than one day to fully understand Java 8's new features around lambdas and streams.
- _old_dude_ 6y agoI 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.
- gonzo41 6y agoEverything 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.
- gengstrand 6y ago> 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/dropwizard https://glennengstrand.info/software/performance/springboot/... Or Vert.x or Play if you want to code reactive microservices. https://glennengstrand.info/software/architecture/microservice/vertx/play 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.
- vips7L 6y agoNever 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.
- jacques_chester 6y agoSpring 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.
- ceronman 6y agoI 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.
- dunefox 6y agoTooling doesn't make the language great. Java is still objectively worse than many other languages, especially Kotlin.
- bluedevil2k 6y agoThere’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.
- pulse7 6y agoYour "objective" view is very subjective... A comment from above (yagodragon): "I think that Java is seriously being downplayed by HN crowd."
- nullspace 6y agoAs 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.
- lchengify 6y agoOther 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 https://www.tutorialspoint.com/guava/index.htm [2] https://www.baeldung.com/guice https://www.baeldung.com/guice
- dcminter 6y agoBroadly 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.
- rzwitserloot 6y ago> (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_.
- bird_monster 6y agoJava got lambdas in the most recent quarter of its development.
- ThePadawan 6y agoMaybe as a point of comparison (I wondered): C# got them in C# 3.0 in 2007.
- lchengify 6y agoPoint 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 https://en.wikipedia.org/wiki/Java_version_history
- rzwitserloot 6y ago> 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'.
- scns 6y ago2 of 3 Gson maintaners say: "use Moshi". Source: Jake Wharton (1 of 3 Gson maintainers)
- pabl0rg 6y agoBaeldung 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
- sk5t 6y agoBaeldung'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.
- mxschumacher 6y agoNow 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/ https://jakarta.ee/ [1] https://www.marcobehler.com/guides/a-guide-to-java-versions-and-features#_java_distributions https://www.marcobehler.com/guides/a-guide-to-java-versions-... [2] https://openjdk.java.net/faq/ https://openjdk.java.net/faq/