Hacker News Reader

Comment by lmm | Hacker News Reader

The #1 thing you need to make Java usable is to abandon the JavaBean conventions. When every field requires 8 lines of boilerplate it's no wonder the code looks ugly (YAGNI, and if you do need it it's two keystrokes in your IDE to "encapsulate field"). public final fields are fine, and can get your data classes something close to readable.

I'd stick with maven for the build rather than Gradle; it's completely declarative and all the tools understand it. Learning a new language just to configure your build tool seems excessive.

View on HN

For starters, you can see Groovy as "Java without semicolons". I went from Maven to Gradle and never looked back. It's superior in most ways. The tooling could be better though.

> For starters, you can see Groovy as "Java without semicolons"

Not if you have to read other people's code, or understand examples you find on the internet.

> I went from Maven to Gradle and never looked back. It's superior in most ways.

What's it better at? I want my build tool to be simple; maven compiles my source and does my releases, and the main thing I have to configure is just a list of dependencies (in an admittedly verbose format). I'm actually a scala programmer, but I use maven rather than SBT because it seems to me that having lots of logic in the build system could only lead to bad things. So what are the things you see it helping with?

Maven is simple as long as your build is simple. As soon as you need to do something custom, it's a pain. Gradle is less painful.

See my reply to vorg regarding Groovy. As a developer the argument "I don't want to learn something new" is invalid.

Gradle offers the declarative nature of Maven without pushing it down your throat. You don't have to write a plugin for something that can be expressed in 3 lines of Groovy (but you can, if you want to!). Instead of adapting your build to Gradle, Gradle adapts to your needs. That's often a point of criticism from Maven users, because every Gradle build looks different. But that's the point: Everyones needs are different. Of course that only applies if your build is beyond the standard compile/test/release configuration. A simple configuration looks pretty much like a Maven POM (minus the tag soup).

> you can see Groovy as "Java without semicolons"

Only a very small subset of Groovy is used by the typical Gradle build script, the very subset of Groovy that's least like Java. What part of this build script from the linked article bears any resemblance to Java?...

  apply plugin: 'java'
  apply plugin: 'application'

  sourceCompatibility = '1.8'
  mainClassName = 'jmodern.Main'

  repositories {
    mavenCentral()
  }

  dependencies {
    compile 'com.google.guava:guava:17.0'
    testCompile 'junit:junit:4.11' // A dependency for a test framework.
  }

  run {
    systemProperty 'jmodern.name', 'Jack'
  }

  javadoc.options {
    docletpath = configurations.markdownDoclet.files.asType(List) // gradle should relly make this simpler
    doclet = "ch.raffael.doclets.pegdown.PegdownDoclet"
    addStringOption("parse-timeout", "10")
  }

  run {
    jvmArgs "-javaagent:${configurations.quasar.iterator().next()}" // gradle should make this simpler, too
  }

I understood the post I replied to as if the author wanted to configure something custom and thus needs to write code. I didn't assume that the original argument was supposed to address the configuration of a standard build. Because you'll always have to learn a new syntax for the tool. Use Make-> Learn make syntax. Use Maven-> Learn POM syntax. Use Gradle -> learn the DSL syntax. Want to extend Gradle -> learn Groovy, a "superset" of Java.

I'd submit that the POM "syntax" is much simpler than a full programming language.

You don't have to learn the complete XML syntax to write a POM. Think about it.

I think anyone programming Java is going to have to learn XML pretty soon; not so Groovy.

Modern Java is usually 100% XML free. Even new servlet containers/standeard REST frameworks (Dropwizarrd, embedded Jetty etc.) require no XML whatsoever.

You only need XML if you're deploying to heavyweight servlet containers (standalone Tomcat, e.g.). Even embedded Tomcat doesn't use XML.

That's not what I wanted to point out. To write a POM, you don't need to know the XML specification. If you want to write a Gradle script, you don't have to know Groovy. You just have to use the Gradle DSL which is fairly compact for most plugins. You make it sound as if you have to learn a whole new programming language, and if that was the case I would agree that Gradle sucks! If you want to do something more specific, then yes you will have to learn Groovy, but at that point the time will be spent well. Also, most of the time Groovy is weakly typed Java with lambdas and no semicolons. I think you've already spent more time arguing about not wanting to learn Groovy than time you would've needed to learn said amount of Groovy.

The "Gradle DSL" and Groovy's grammar are the same thing, mixed together in one Antlr file, and probably the largest programming language grammar I've ever seen. Here it is for Groovy 1.8, the version that shipped the paren-less parameters that Gradle uses:

http://svn.codehaus.org/groovy/eclipse/trunk/base/org.codeha...

I accept that argument if you prove my preceeding argument, that you don't need all of Groovy to use Gradle, to be wrong.

Maybe you can write it, if it's a solo project with a fairly vanilla build. But as soon as you have to collaborate with other people, or read examples from the internet, you're going to run into full-on Groovy; "the Gradle DSL" is not well-defined, so while most bloggers will claim they're writing idiomatic Gradle, they'll all have different subsets of Groovy in mind when they say that.

By contrast Maven has a very rigid format - there's no risk of randomly seeing a lambda or conditional expression in the middle of the XML - and its plugin model ensures that there's a very clear delineation between what's standard and what's an extension.

> you can see Groovy as "Java without semicolons

I see it as "Java without types", myself.

I'm aware that Groovy now supports optional typing but if I'm going this path, I prefer to switch to Kotlin, which I describe as "Java with everything that's bad removed".

If that's what you want wouldn't Ceylon be a better choice? If you're still using the Java standard library you still have the billion dollar mistake (null) everywhere.

Project Lombok is your friend then: http://projectlombok.org/features/Data.html

Until you have to debug it. At which point you realise you're now writing what's effectively a different language with its own tooling and compilation (and its own bugs), and if you were going to do that then you might as well go all the way to Scala where you get much more in return.

Lombok is an anti-pattern for me. It creates a unholy mess of annotations for what should be language features.

I used Project Lombok back in the days to get read of Javabeans boilerplate. Just declare your private fields and put @Data annotation on class, and it would generate at compile time all your getters, setters, equals, toString, constructor and hashCode methods. Really helps to keep the code lean and small. Don't know does it work with Java 8 though or it didn't yet catch up.

I used Lombok in a Java 8 project without problems.

Couldn't agree more. Use public, protected, private fields as they were meant to be used. I only dip into JavaBean anymore if I need a readable but non-writable field.

For me that's almost all fields: I try to make just about everything immutable by default. Makes reasoning about concurrency much simpler.

For immutable you can just use public final fields. I assume GP must be talking about fields that are mutated but only by the object itself, where outside code needs to be able to read but not write.

Not quite. eg:

public final Date date;

date.setTime(1);

That's not immutable.

The bean convention doesn't help you with that one though; if you have private Date date; public Date getDate() {return date;} then people can still do getDate().setTime(1);

Yeah, but with a getter you can make getDate return a copy of the Date object to enforce immutability.

Yeah, but getDate().setTime(1); works the same way.

Not if getDate() returns a copy of the underlying member.

Yep, the thing is that Date is immutable. I think that this public final immutable rule is ok, but one has to ensure the fields themself are really not modifiable.

The Java Date class is not immutable.

So you can use a wrapper or Joda time library.

A class with mutable fields that a caller can mutate is not immutable.

The fact that java.util.Date is terrible is so many ways should go without saying.

Couldn't agree more.. But this comes with the most cliche discussion with a smartass looking at your code. Dude, I know what getters and setters are, I just don't agree

Reply on news.ycombinator.com