Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Better Java – Resources for Writing Modern Java

github.com

Post reply on HN
Print view View original

181–190 of 192 posts

Re: Better Java – Resources for Writing Modern Java

#181

Post by lliamander »

owlish wrote: post #64

I used to be a fan of the Builder pattern (or Fluent Interface), but the ease of use for developers comes at the cost of no compile-time checking. Before, you just had to look up the constructor to see which parameters go where, with the benefit of type-checking. Now, you have to look up the Builder's methods to make sure you've filled in all required fields. The only case where I can actually advocate using Builders…

You can have a type-safe fluent Builder, but it requires having one or more static nested classes with private constructors. The outer class will not have a build() method, but rather that method will live in one of the nested classes. You use the type system to control what parameters have already been set, and what parameters need to be set.

Obviously, this can apply to many sorts of fluent API. This is at least part of what Tony Morris is alluding to in his essay on API design [1].

[1] http://blog.tmorris.net/posts/understanding-practical-api-de...

Re: Better Java – Resources for Writing Modern Java

#182

Post by dguaraglia »

Babylonian wrote: post #143
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…

Wow, I didn't know this could happen. I've only recently started using Lombok for some side-project related stuff and this heads up comes at a really good time. Thanks!

Re: Better Java – Resources for Writing Modern Java

#183

Post by vorg »

adarshr wrote: post #103

My solution is to use Groovy wherever possible. It has a superb syntax, very low learning curve and compiles into JVM bytecode. There is no issue with getters and setters in Groovy - you just define the fields, which Groovy calls properties and defines implicit getters and setters. If not for the main application code, I would definitely use Groovy for unit testing in combination with Spock Framework. You just have t…

Groovy's always been OK for quick and dirty testing of Java classes, though the statement label hack that Spock uses makes Groovy look trashy. The static compilation that came with Groovy 2.0 is what no-one should touch if they don't want to spend countless hours and days debugging and wondering why they didn't use a language built from the ground up for static compilation, e.g. Java, Scala, Kotlin, Ceylon, and others.

Re: Better Java – Resources for Writing Modern Java

#184

Post by mindcrime »

lomnakkus wrote: post #111
mindcrime wrote: post #100

One thing I'd add, is that Java is very amenable to static code analysis, and there are good tools like PMD and FindBugs for Java. I always encourage teams using Java to use one or both. The biggest downside is that you usually have to tweak the rule-sets to avoid getting lots of false positives. And if you get too many false positives then people tend to stop paying attention to the notifications from the tool. On a…

> [...] Java is very amenable to static code analysis [...]. The biggest downside is that you usually have to tweak the rule-sets to avoid getting lots of false positives. These two statements seem to be in opposition to each other. (All your advice is spot on. If you let warnings remain in code, you'll just end up accumulating more and more warnings until it's too much to fix. I guess it's a sort of "broken windows"…

I don't know if they're in opposition exactly. The Java language is definitely amenable to static analysis to some extent, probably more so than a more dynamic language. But a lot of the "false positives" are just about what rules the developers of the tool ship by default, and what they define as a "bug" (or "possible bug"). For better or for worse, static analysis tools sometimes conflate simple stylistic issues ("don't use variable names less than two characters") with things that are likely to be actual logic errors. And since the tool will always be limited in how much it can understand about the intent of the code, it's pretty much always just applying heuristics and a probabilistic analysis, even when processing Java.

So yeah, those tools aren't perfect, but my subjective experience has been that they help, as long as you tweak the knobs so that they don't just generate something equivalent to the "broken windows" compiler warnings, etc.

Re: Better Java – Resources for Writing Modern Java

#185

Post by vorg »

monksy wrote: post #118
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.

Thats one of the things that'll happen to you if you start writting groovy code. The whole setter/getter boilerplate thing gets really annoying. Another groovy-ism.. the whole deal with having to copy properties. (In a groovy class they're threated like a map)

> properties. (In a groovy class they're threated like a map

Except in hard to remember special cases like .class which gives the class "LinkedHapMap" of the map object instead of the value at key "class". After working with Groovy for a short while you'll realize you're really working around it.

Re: Better Java – Resources for Writing Modern Java

#186

Post by vorg »

meddlepal wrote: post #65
zeckalpha wrote: post #57

Earlier quoted context omitted.

People get in the habit of writing loops with indices.

I still people doing that shit in Java 8 and Groovy... I can probably count on one hand the situations when a counter-based loop is necessary.

> I can probably count on one hand the situations when a counter-based loop is necessary

Such counting is analagous to counter-based looping. If you'd said "I can probably filter down to the fingers of one hand..." I might have believed you.

Re: Better Java – Resources for Writing Modern Java

#187

Post by EdwardDiego »

yogthos wrote: post #174
EdwardDiego wrote: post #91

Earlier quoted context omitted.

I like Clojure, but anyway to make it start faster in a scripting context? I wrote the same script in Clojure and Kotlin, and the Kotlin one loads so much faster.

There's Planck for OS X https://github.com/mfikes/planck It uses JavaScriptCore and starts practically instantly. There's some work being done to port it to Linux/Windows as well. Here's an example: cat foo.cljs #!/usr/local/bin/planck (println "hello world: clojurescript -> planck -> as shell script") ./foo.cljs hello world: clojurescript -> planck -> as shell script Planck can be installed using homebrew now as wel…

Cheers mate :)

Re: Better Java – Resources for Writing Modern Java

#188

Post by asveikau »

harryh wrote: post #164
asveikau wrote: post #113

Earlier quoted context omitted.

By all means, have more clumsy, less straightforward ways to represent the lack of a value in your code, because Tony Hoare says so.

The problem with NULL is that it can be there for literally any reference in your code. So, unless you are careful, you can get an NPE when calling any single object method. In languages without NULL this can never happen making them much easier to reason about.

My initial reaction: programming ain't bean bag. Them's the breaks.

Then I think of it and I see the real problem is languages making all nonprimitive types into pointers without being explicit. In a language like C it's more obvious what can be null.

Re: Better Java – Resources for Writing Modern Java

#189

Post by jonalmeida »

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…

Wouldn't the best way to create an empty map be to use `Collections.emptyMap()`?

Re: Better Java – Resources for Writing Modern Java

#190

Post by vorg »

pron wrote: post #120
mahmoudimus wrote: post #102

Earlier quoted context omitted.

I really like OGMJ, it's definitely a great resource and I recommend it to many new Java developers; however, I disagree re: tools mentioned. After trying dropwizard for a few projects, the superiority of the spring-boot and its various ecosystems just blew me away. Also, while I appreciated Gradle, Maven is just much more supported through the entire eco-system. As a new comer to Java from C++/Python, it made a big…

You're probably right about Spring Boot. I've never been a web developer, and TBH, I've had no direct experience with either Boot or DW other than a simple Hello, World. At the time DW seemed the safer choice simply because it used the JAX-RS standards, and using standards in the Java world (especially good ones like JAX-RS) is a very good idea. But in the meantime Spring Boot has also done the right thing and adopte…

5 years is a long time in IT. Gradle has a millstone called "Groovy" around its neck because of an early poor choice to ship with only one configuration language. Maybe they'll enable more languages to be plugged in later on, but there's an ex-Pivotal programmer who used to work on Groovy now working at Gradleware on Gradle who might sabotage such an effort because of his lingering association with Groovy.
Post reply on HN