Lately, German publisher dpunkt.verlag reached out to me wether I’d think it’s a good idea translating Joshua Blochs Effective Java 3rd edition (Partnerlink) to German. Effective Java has been on my Good reads list for a while now and I read the first edition in 2003 or 2004, don’t remember exactly when. I hopefully learned a thing or two in that time and sadly seen some things better left unseen and my initial thought was: Go for it! If a translated version helps spreading best practices and especially things one should not do, it’s worth the effort.
To my surprise, dpunkt than asked if I could review the translation. And so it happened that I read the third edition in its total, mostly parallel in German and English:
My friend Thorben has reviewed the book already very concise at his Thoughts on Java blog. I fully agree with him.
One thing I have to quote is Joshua Bloch himself:
If you have ever studied a second language yourself and then tried to use it outside the classroom, you know that there are three things you must master: how the language is structured (grammar), how to name things you want to talk about (vocabulary), and the customary and effective ways to say everyday things (usage). Too often only the first two are covered in the classroom, and you find native speakers constantly suppressing their laughter as you try to make yourself understood.
This is from the foreword itself and is basically the essence of the book.
If one gets the idea on how to start a Java program, the weird notion of the main-method and have an idea about objects, Java does not have a step learning curve. One can solve many problems without going deeper into the specifications or fully understanding what’s happening behind the scenes.
Most of the time, stuff works out, some times not. Usually those times happen to be late in the evening, on a weekend duty etc. Performance optimizations that should not have been done. Cloneable or serializable classes that violates their invariants. And many more.
Effective Java does address all these and more.
It also is written from an API creators point of view as one clearly sees on how Joshua stresses good documentation at the API level.
One does wonder if qualities being important for an API are equally important for a product or a software that has it’s value in the business it powers? I’d say yes. There’s always a team that has to maintain code or hast to fix bugs. Add new features. I don’t believe in a permanent rewrite of (micro)services. By all probability, the Netflixes, Amazons and Googles of this world do this, but at least I have not yet been in a project where that was a legitimate thing.
Given that premise, I’d rather build my stuff on a solid fundament and that starts with some best practices and at least the ambition to learn a language a bit deeper than just on the surface.
Funny enough, my tweet about Lombok did gain some traction:
I like the project but use it very selectively, most of the time @Getter, @Setter, @EqualsAndHashCode (that one only with the of-attribute) and sometimes @Builder. I use it to create immutable, small values classes with not more than 4 or 5 fields and @RequiredArgsContructor. I’m probably even the last person who learned yesterday, that there is @Synchronized, but at least I can explain what and why the stuff that @Synchronized does, is actually a good idea. If one has a library like Lombok or Googles AutoValue in a project, an understanding of Javas details become paramount or otherwise all kinds of interesting things can happen (if we speak on a higher level like Michael @bitboss Plöd argues, inflationary generation of accessors defies information hiding and encapsulation and should be avoided).
If you want to master the language Java, read all items in the book. If you’re more into other (JVM) languages as well, the chapters General programming, Exceptions and Concurrency have value without Java, too (By the way, you should sometimes have a look at other languages. Kotlin is nice and Simon has a great blog. However it might be a good idea to really look outside the OO box and take a sneak peek at Clojure).
tl;dr: I firmly believe that one has not to master every detail of a day-to-day language but one should know more than just the basics and to the right things the right way. Effective Java has some more or less controversial items, but overall, it indeed helps to be more effective.
Filed in English posts, Java
|
