Thread by @nipafx

I just got my (electronic) copy of #EffectiveJava3E and am reading the new parts. Will tweet a little about it...

Nothing spectacular going on with Optional (of course I started with that, what did you think?!) until close to the end. "Optional fields are a smell, but here's an example, where it's justified".

HarHar, I'm just gonna leave this here: blog.codefx.org/java/stephen-c…

#EffectiveJava3E

(Yes, it took me three tries to get that tweet right.)

I think this isn't even new:

"To document your API properly, you must precede every exported class, interface, constructor, method, and field declaration with a doc comment."

It's almost like blog.codefx.org/techniques/doc…, but less vulgar and with more authority.

#EffectiveJava3E

I just love the rest of the Javadoc item (56). Maybe a little overboard on the "document everything" front, but so much good advice on how to structure and phrase for good readability.

#EffectiveJava3E

Oh, I didn't know the Javadoc search box #Java9 added could be filled manually. Nice!

#EffectiveJava3E

Going back to documenting "exported classes, interfaces, etc." The book defines "exported" like the module system does (if you create modules), which shows a huge boon of the module system: Your intention of which APIs are public is clearly documented in code.

#EffectiveJava3E

Oh, hello, #JUnit5. (Yes, I'm full-text-searching for "module".)

#EffectiveJava3E

Off to modules then, which are only really discussed towards the end of item 15 - a little stingy with advice, here. It's somewhat discouraging, which I disagree with. (But of course I do, I have a book to sell. 😜 Shamelkess plug: manning.com/books/the-java…)

#EffectiveJava3E

I do not consider exports "largely advisory". Even if users of a module place it onto the class path, they still have an easy way to check whether they use internal APIs. In fact, IDEs should warn about that. Heck, maybe even the module system?

Also, no need to rearrange the source tree (blog.codefx.org/java/java-modu…). The default `src/main/java` works like a charm.

On to default methods (item 21). A very good point about them subtly breaking the contract of implementing classes. I never really thought about it like that before.

When adding default methods after the fact, maybe let them throw UOE?

#EffectiveJava3E

Ehh, yes it is: blog.codefx.org/design/pattern… Unless I'm overlooking something (binary compatibility?) which is possible.

#EffectiveJava3E

Still, last paragraphs on the importance of proper design and real-life-testing of interfaces totally holds:

"While it may be possible to correct some interface flaws after an
interface is released, you cannot count on it."

#EffectiveJava3E

Shouldn't the try-with-resources item (9) mention that in #Java9 the resource no longer has to be assigned?

Item 9 makes me really happy that I never dev'd professionally with Java <7 with try-try-finally-finally-cross-fingers-hope-everything-works.

#EffectiveJava3E

Next stop: item 32 on @SafeVarargs (of course that's a Twitter handle). Solid explanation of heap pollution ("it is unsafe to give another method access to a generic varargs parameter array") and what to do about it ("never write unsafe varargs methods").

#EffectiveJava3E

Mh, Java annotations that are also Twitter handles... There should be something in here for @lukaseder to make fun of.

Next up would be lambdas and streams, which I'm so excited about! But it's late, so it'll have to wait.

So it's "advisory" in the sense that it is not enforced, but not in the sense of "just a piece of advice". As a maintainer I'd still be willing to break users by refactoring internals. "You've been warned."