1. 16

I may be being switched to a team that works with Java. I’ve written Go in the last 5 years exclusively, and looking at Java now makes my head spin. var foo = "bar" declarations seem the least of it, there’s also streams (they look good) and lambdas and all sorts else.

I have no idea where to start learning whatever Java looks like now. There are books for writing Java 11 and such for Java devs, there are introductory books for people that don’t know programming at all, but I can’t find any resources for current non-Java programmers to return to Java.

Effective Java only got to Java 9 so doesn’t include var declarations, but I don’t know if it’s missing something else really important that was introduced after 9.

  1.  

  2. 7

    I’ve written Java professionally for a few years now and continue to recommend Effective Java as a starting point. I originally read the second edition when I started writing Java professionally, and recommend the third edition to others in your shoes that I work with. It will bootstrap a lot of fundamental concepts into your knowledge that you would learn over your first six months or a year of writing Java.

    The third edition covers Java 9, and Java 10 + 11 haven’t introduced too much new stuff that really changes the ball-game of writing Java, especially for someone new to the language. I don’t think there’s anything I would consider critical knowledge in Java 10 + 11 (even var), and anything that is I think you’d quickly learn via code review etc.

    1. 4

      I’d second this. Java 8 introduced streams, which are probably the biggest change since Generics. Java 9 introduced modules, which have major implications for packaging, library compatibility and some other concerns like that. By comparison, Java 11 is pretty small stuff.

      I only read the second edition of Effective Java, but I’ve only heard good things about the third edition.

      1. 1

        Thanks both, I put in an order for the third edition :)

        1. 1

          Java 8 was really major imo: besides streams, 8 also introduced lambdas and the whole java.util.function hierarchy, which changes some codebases quite a bit. Suddenly it became easy to do things like sort by a custom sort order! I agree that 10/11 are pretty minor.

      2. 5

        I can’t specifically speak to Java 11 but I’d say this shouldn’t necessarily be your immediate goal unless you know that the code base you’ll be reading/contributing is using lots of features from Java 11. You should concentrate on learning the code base first so that you can be ramp up quicker. If there are idioms that seem foreign that’s when you go to Oracle docs/Google/Stack overflow/other coworkers.

        There’s two sites that might help with transitioning to another language

        Code Review RosettaCode

        Although Rosetta Code might not have the most idiomatic code.

        1. 4

          I can’t specifically speak to Java 11 but I’d say this shouldn’t necessarily be your immediate goal unless you know that the code base you’ll be reading/contributing is using lots of features from Java 11.

          This is a great point that speaks to something I didn’t mention before: the code we will be writing will be all new, there won’t be any previous code. So all the bells and whistles are available, as the golden rule of staying consistent doesn’t apply. The question is is which bells and which whistles should be thought about :)

          1. 4

            In that case, try to convince your team not to do green field development in an antiquated language.

            There are better JVM languages now, with near-perfect Java interop.

            1. 5

              Google is all in on Java for the JVM. Sadly Kotlin remains banned except for Android work.

              1. 4

                Just curious what the rationale for that is? Kotlin is used in Android but not on the server side?

                1. 7

                  Google is intensely conservative about server side code languages.

                  There are a few reasons that I can see:

                  • Readability: given the Google monorepo, you will depend on other peoples libraries a lot. It is very important you can read them, and that the documentation that there is is something you can understand. If you’ve only ever seen Kotlin, you have to do mental gymnastics to understand Java libraries or documentation, and no one wants to rewrite documentation/examples over and over in different languages.
                  • SRE support: SREs are the most conservative people on earth for good reason. They need to be able to jump into alien code they didn’t write understand it quickly, figure out what is happening and come up with a mitigation strategy under pressure. Language proliferation makes that much harder as you have to start splitting SREs over languages, and SREs are in short supply.

                  These are the two most obvious ones, I assume there are also plenty more about library support, running things reliably in production, security patching…

                  Kotlin is obviously an easier lift given it’s a JVM language and popular. I’d say it’s a 50:50 proposition it gets accepted in the next 5 years. It really depends on whether it can offer significant provable benefits to productivity over Java, and I think that jury remains out.

                  1. 5

                    Google can’t afford using expressive languages. Their hiring process results in having (enough of) developers thinking of themselves as being the smartest, infallible people on the planet which leads to overly smart, unreadable code in any language, but expressiveness exacerbates that. This is by the way why Go is so minimalist: the fewer variety, the better. Now imagine what damage they’re going to do in a language with five flavors of .let.

                    (This is all purely my speculation based on hearsay.)

                2. 1

                  I will say that if I were going to choose a language for the JVM–which I’m not, because I don’t have to, thankfully–I would still stick with Java. Groovy and Clojure are dynamically typed, Scala has serious readability and maintainability concerns, and in my experiments with Kotlin I ran into numerous surprising warts that led me to conclude that the benefits it gives aren’t worth it. Java is a verbose, annoying language, but its semantics are well-defined and well-understood, so despite its age it still seems like the best choice to me if you must target the JVM.