Better Java – Resources for Writing Modern Java • Hacker News Board

Re: Better Java – Resources for Writing Modern Java

#141

Post by dang » Sun, Sep 20, 2015, 7:51 AM UTC

fizwhiz wrote: post #67

nobleach wrote: post #52

Earlier quoted context omitted.

Well, I was an English major, so I'm glad you were engaged by the "diatribe". And if you were unable to piece it together... and I kinda feel bad if you couldn't. I'm referring to Java 8 language features and OpenJDK 1.8. I get the feeling you knew that though and are being pedantic. You've succeeded though, because I responded. Sadly you missed the part where I said, "Not all Java devs obviously". I have read great…

Your comment about the "JVM update" was a non sequitur trailing from your rant, but I'm glad to know that you were indeed referring to JDK 1.8. The fact that you get excited in the event these nebulous java devs have "heard" of Clojure/Scala only comes across as patronizing (but I suspect you weaved that in masterfully and deliberately, given your degree in English.) Your anecdotal fallacy hasn't added anything valua…

Your comments in this thread violate the HN guidelines. Please comment civilly and substantively, or not at all.

https://news.ycombinator.com/newsguidelines.html

https://news.ycombinator.com/newswelcome.html

Re: Better Java – Resources for Writing Modern Java

#142

Post by iwwr » Sun, Sep 20, 2015, 8:11 AM UTC

mahmoudimus wrote: post #124

hiram112 wrote: post #18

I've seen numerous posts lamenting the use of typical Java Beans. The problem with the struct approach is that numerous tooling / libraries expects beans with typical getter/setters - Jackson Json, Spring binding, etc. Yes it's possible with configurations and/or annotations to get around this, but IMO, saving a few lines of code in exchange for non-default behavior isn't a valid trade-off. Adding a dependency on Lom…

Lombock is one of the most valuable enhancements to Java. Without it, it would make Java development not as fun.

Lombok is also a non-standard dependency and there are costs with having to rely on it.

Re: Better Java – Resources for Writing Modern Java

#143

Post by Babylonian » Sun, Sep 20, 2015, 8:25 AM UTC

Cthulhu_ wrote: post #16

Re the first bit about 'struct' style, even better (IMO) is to use Lombok; throw an @Data annotation on your class and all you need to do is put your properties in there (private final if need be). Nobody should be writing those boilerplate constructors, getters and setters. If it's generated by your IDE, use Lombok. The best code is no code.

Lombok is a crime. Have you seen what happens when someone does a minor reformatting of your code and moves one field declaration above another? You get a nasty little surprise because the two fields of the same type have now reordered in your Lombok generated constructor. When the app runs nobody can figure out why foo is set to bar and bar is set to foo. There's also the issue of Lombok vals which don't conform to the language spec leading to other fun. And it's almost always incompatible with new jdks without code changes to the lombok libs due to the whacky way it relies on implementation specific compiler details.

Re: Better Java – Resources for Writing Modern Java

#144

Post by Babylonian » Sun, Sep 20, 2015, 8:36 AM UTC

cletus wrote: post #76

I mostly agree with this list but some things I have issues with. The biggest is DI. Having witnessed what a tangled mess large Guice codebases can become where you really have no idea what is providing what I have to say that Spring here gets a bad rap from the all-XML days and (IMHO) it is actually the cleanest and easiest to work with. The author mischaracterizes Spring too: > It has a either code-based wiring or…

> Scala. That's a huge negative IMHO. I'm not interested in Scala. Nobody is.

Their use of Scala was the only reason I gave the play framework a second look. Just because you're not interested in Scala doesn't mean nobody else is. Scala is the most popular plugin for intellij by a very wide margin, that's a lot of 'nobody' downloads. Having used both java and Scala extensively I honestly can't understand why anyone would still pick java by choice other than if it's the only jvm language they know.

Re: Better Java – Resources for Writing Modern Java

#145

Post by brown9-2 » Sun, Sep 20, 2015, 11:36 AM UTC

nobleach wrote: post #38

After working at two companies filled with Java devs, I don't think any of them will read this article. I can't speak for all Java devs obviously, but it seems unless the dev is a polyglot, they are just fine living in their Spring/SVN/J2EE/Java5 world. They have no idea what's going on in the software development world. I get so excited whenever I hear any of them mention Clojure or even Scala! They just live with t…

I have a hard time believing that a company stuck on Java 1.5 or SVN is like that because the developers want it that way.

Re: Better Java – Resources for Writing Modern Java

#146

Post by agumonkey » Sun, Sep 20, 2015, 11:47 AM UTC

Peaker wrote: post #127

agumonkey wrote: post #44

Earlier quoted context omitted.

In other paradigms (Lisps) null is a lot less than a billion dollar mistake, it seems it goes better with map/filter/fmap patterns. In imperative languages, data is tied to control, and null means segfault.

When some ELisp code crashes in my emacs with an error like: error: (stringp nil): not a string I think it indicates Lisps suffer from this problem too...

It does, I said 'a lot less' not 'zero dollar mistake'. Recursively defined lists take care about nil, and since it's one of the most used ways to program in lisp it makes a lot of logic nullproof.

Re: Better Java – Resources for Writing Modern Java

#147

Post by jacques_chester » Sun, Sep 20, 2015, 12:20 PM UTC

lmm wrote: post #132

fizwhiz wrote: post #8

>> Good alternatives to using Spring is Google and Square's Dagger library or Google's Guice. They don't use Spring's XML configuration file format, and instead they put the injection logic in annotations and in code Spring has had code-based configurations since 2009[1]; seems a little disingenuous to recommend Guice/Dagger due to this non-existent limitation. [1] http://spring.io/blog/2009/12/22/configuration-simpl…

Spring has a million and one ways to do anything; that's the problem with it. Spring with a very strict, carefully enforced style guide is probably as good as Dagger or Guice. But there is a cost to maintaining and enforcing a style guide. Better to just use something that doesn't have the bad options.

That's what Spring Boot is for.

Everything is autoconfigured and set to sensible defaults. All the dependencies in the starters are levelled and guaranteed to work together.

Spring Boot on Gradle is the closest thing Java has to adding lines to a Gemfile in a Ruby system. Especially when you add other Spring automagical libraries (Spring Data REST, Spring Cloud...).

Re: Better Java – Resources for Writing Modern Java

#148

Post by jacques_chester » Sun, Sep 20, 2015, 12:22 PM UTC

jonhohle wrote: post #108

As a fan of immutable objects, I bemoan the builder pattern. The nice thing about constructors (or factory methods) is that you have a compile time guarantee that you have all required components to construct an object and validate its invariants. With a field oriented builder, only the documentation informs you whether you've met all of the conditions to construct an object. Also, a builder which mutates its own int…

The Builder pattern includes setting sensible defaults on the built object before building it. You configure the built object in the constructor of the Builder, before anyone starts updating fields.

You can achieve this through constructors or setters; Builder itself is agnostic.

Re: Better Java – Resources for Writing Modern Java

#149

Post by CHY872 » Sun, Sep 20, 2015, 1:07 PM UTC

kilink wrote: post #23

I'm surprised he didn't mention AutoValue [1] or Lombok (using @Data and @Builder) in his section about data objects and builders. I prefer AutoValue, but both approaches cut down on a lot of the boilerplate (and they also generate sensible equals(), hashCode(), toString(), etc). It's also kind of a nitpick, but I disagree with his preference for Guava's Maps.newHashMap() vs new HashMap (). I'm pretty sure the only r…

Lombok's a bit sketchy as parts of it rely on some undocumented, non-standard parts of the Sun Java compiler - you have to be really into code generation to want to use it.

Other libraries like Immutables are safer for this purpose.

Re: Better Java – Resources for Writing Modern Java

#150

Post by izzle49 » Sun, Sep 20, 2015, 1:38 PM UTC

lmm wrote: post #131

izzle49 wrote: post #4

Please don't use Java 8's default methods in interface's to do multiple inheritance, and code reuse. Prefering this over 'Util' classes is bad as it is inheritance over composition. The default methods were designed to facilitate easier interface migration

Java was designed for TV set-top boxes, but that doesn't mean it's bad to use it on a server. If using a default method in an unintended way leads to clearer, more maintainable code, do it.

how would it lead to more clearer code? You would have many interfaces referencing an instance variable, each with different semantics for that variable. Interfaces cant have variables so they should not be used as traits.