An Opinionated Guide to Modern Java Development, Part 1 • Hacker News Board

Re: An Opinionated Guide to Modern Java Development, Part 1

#211

Post by lmm » Thu, May 01, 2014, 9:44 PM UTC

emsy wrote: post #193

lmm wrote: post #36

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 declara…

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?

Re: An Opinionated Guide to Modern Java Development, Part 1

#212

Post by vanilla » Thu, May 01, 2014, 9:49 PM UTC

pjmlp wrote: post #84

tieTYT wrote: post #50

> But the modern Java developer uses Gradle I'm a little skeptical of this. More like the developer in the future uses Gradle. Usually when I go to a project's home page, I see documentation on how to include the Maven dependency, not the Gradle dependency. It's pretty obvious how to convert one format to the other, but my point is I think most people are using Maven.

Gradle is mainly being pushed by Grails and Android development. I don't know of any other project using it. We are always doing Maven or Ant. If Gradle is the future I hope it gets improved, I gave up on Android Studio given its dependency on Gradle and how it drags my dual core with 8 GB to its knees when compiling.

libGDX (cross plattform game lib.) also made a push to gradle

Re: An Opinionated Guide to Modern Java Development, Part 1

#213

Post by pjmlp » Thu, May 01, 2014, 9:52 PM UTC

pnathan wrote: post #197

pjmlp wrote: post #111

Earlier quoted context omitted.

> The short answer is C++ gives control and abstraction on demand, an unusual combination. Ada, Modula-3, the Oberon language family as well. But they lacked a proper OS vendor support and faded away. Ada seems to be raising up, thanks to GNAT and continuous security issues with C and C++. At least from its increasing presence at FOSDEM.

Well, yes. And more than a few other languages that got left in the dustbin of our history. But as for today... I actually am personally very keen on seeing where Rust goes here, but it isn't 1.0 yet (which will be the signal for me to start writing in it seriously ).

Me too, alongside D, .NET Native and the Graal/Truffle compilers.

Re: An Opinionated Guide to Modern Java Development, Part 1

#214

Post by bananas » Thu, May 01, 2014, 10:08 PM UTC

dota168 wrote: post #169

bananas wrote: post #80

Earlier quoted context omitted.

I wrote a lot of J2ME stuff a few years ago and you're spot on. I spent two weeks doing Java 8 bits with NetBeans which was really nice and spent the last two evenings writing my first Android app and what a complete mess it is. Plus the Android tooling is horrible to get working reliably - most problems being solved by "restart eclipse". Late edit: perhaps Oracle should make a phone ;)

> "restart eclipse" Eclipse /shudder

After this week, yep!

Re: An Opinionated Guide to Modern Java Development, Part 1

#215

Post by eeperson » Thu, May 01, 2014, 10:11 PM UTC

lomnakkus wrote: post #187

eeperson wrote: post #156

Earlier quoted context omitted.

The performance problems are definitely the most annoying part of using Gradle. The Gradle daemon helped a little but tended to break other things and Gradle was still pretty slow. If you are looking for something faster and more declarative, you may want to check out SBT[0]. It is way faster than any of the other JVM build tools. Also, in the future[1] it should have much better tooling support than anything else on…

Right now, SBT + IDEA is a bit of a pain because they share the same target folder and IDEA sometimes overwrites/deletes .class files that your application (started via sbt run) hasn't loaded yet. Usually that leads to a few ClassDefNotFound errors and such. Hopefully that'll go away once we have a single SBT instance. My two wishes for SBT would be: 1) A monadic style for .scala build files. It would make dealing wi…

Would you mind elaborating on what you mean by a monadic style for .scala build files?

PS - You may already know this, but you can change IntelliJ's compile output directory [0].

[0] - http://www.jetbrains.com/idea/webhelp/configuring-module-com...

Re: An Opinionated Guide to Modern Java Development, Part 1

#216

Post by hugofirth » Thu, May 01, 2014, 10:14 PM UTC

Another great Java resource (though admittedly the current edition is focused on Java 7) is "The Well-Grounded Java Developer" by Evans & Verburg [1].

[1]: http://www.manning.com/evans/

Re: An Opinionated Guide to Modern Java Development, Part 1

#217

Post by pswenson » Thu, May 01, 2014, 10:21 PM UTC

tieTYT wrote: post #207

pswenson wrote: post #195

Earlier quoted context omitted.

I'd say Gradle is the least awful of the 3 major build systems. Ant degrades into an unmaintainable mess as soon as any complexity enters the system. XML is a horrible scripting language, simple imperative constructs are very awkward (loops/variables/conditionals). Maven also suffers from XML hell, but at least it has dependency management. I've used gradle extensively and it is quite difficult to figure out what is…

> Maven also suffers from XML hell, but at least it has dependency management. I don't find it that bad. The nice thing about it is how my IDE will auto complete almost everything and it should be possible to validate it without even using an IDE, as it has a schema. I agree with your complaints about Ant. The thing I was hoping gradle would give me is the ability to write tests for my build. EG: I want to have more…

w/ regards to gradle using groovy.... in gradle I can easily add in variables to my dependencies, I can write conditionals (if System Prop X then include dependency Y).

Basically anything you can do in code, you can do in gradle very easily.

Auto-complete does work in IntelliJ 13 - at least for groovy code type stuff. Nothing for the gradle DSL (that could be implemented of course).

> Java devs do many things manually that a Ruby/Python dev would be horrified at....

Jenkins config - almost every one does this by hand. Jenkins jobs weren't really even designed to be automated (ironic, eh), you have to build a full xml doc for each job rather than say apply a similar change across all jobs (add in a -D param across all jobs for example). I know this is a Jenkins specific issue, but this mentality is very common in java land.

Others: have every dev manually install a database for their environment (Chef/Puppet/Ansible solve this - and what are they written in? Ruby/Python)

No one would ever use java for any scripting type work, the JVM startup time is awful + the file/string libs are far less powerful/usable than ruby/python.

Of course a java dev can learn one of the scripting langs, but they typically don't.

this is just my experience, but note I've seen a lot of shops...

Re: An Opinionated Guide to Modern Java Development, Part 1

#218

Post by izacus » Thu, May 01, 2014, 10:22 PM UTC

pswenson wrote: post #195

tieTYT wrote: post #50

> But the modern Java developer uses Gradle I'm a little skeptical of this. More like the developer in the future uses Gradle. Usually when I go to a project's home page, I see documentation on how to include the Maven dependency, not the Gradle dependency. It's pretty obvious how to convert one format to the other, but my point is I think most people are using Maven.

I'd say Gradle is the least awful of the 3 major build systems. Ant degrades into an unmaintainable mess as soon as any complexity enters the system. XML is a horrible scripting language, simple imperative constructs are very awkward (loops/variables/conditionals). Maven also suffers from XML hell, but at least it has dependency management. I've used gradle extensively and it is quite difficult to figure out what is…

After doing couple of Android projects with Gradle I've felt like Maven is a godsend.

It might require writing some XML to declare what your project does, but at least it WORKS and at least it does not waste my time by forcing me to write code to include pieces of projects and properly process project (e.g. including native code, Robolectric testing, renderscript and some other things).

Also any compilation inside IDE's was orders of magnitude faster with Mvn than with Gradle... all in all setting up all the components with gradle took about 2-3x as much time. Mostly it seems like someone decided that because now you have code instead of XML for build configuration, they'll just skip most of the plugin design and force you to roll half of the build process on your own.

Right now (at least for Android), Gradle is a colossal waste of time due to lacking features, extremely slow execution and myriad of bugs which will eat away productive time on project.

Re: An Opinionated Guide to Modern Java Development, Part 1

#219

Post by mbrock » Thu, May 01, 2014, 10:25 PM UTC

sivanmz wrote: post #190

spopejoy wrote: post #149

> In this example, Java is rather annoying, especially when it comes to testing the type of a message with instanceof and casting objects from one type to another. Using instanceof is an antipattern 99% of the time, easily avoided with proper API design. In this case a simple enum type would help with appropriate getType() method on the event; or a polymorphic event API with dedicated method types for each event (Lif…

Agree that instanceof is wrong and discredits the article. I'm not sure if this is what you meant, but here is how polymorphism along with the double dispatch pattern would work: NaiveActor#handleLifecycleMessage will need to delegate to the event subclass, which will in turn select the appropriate method on NaiveActor. Example of subclass of LifecycleMessage: class ExitMessage implements LifecycleMessage { @Override…

I think a lot of programmers aren't totally clear about how dispatch works in Java. I've talked to many who couldn't explain exactly why it doesn't work to overload based on subtype information only known at runtime. Type flags are extremely obvious!

Re: An Opinionated Guide to Modern Java Development, Part 1

#220

Post by MBlume » Thu, May 01, 2014, 10:26 PM UTC

lmm wrote: post #134

bananas wrote: post #34

Earlier quoted context omitted.

That pisses me off but the following is much worse. The commit comment that goes: "checked in abstract_class.cpp" Duh!

I do that a lot, or rather my commit messages are usually "mumble" or "fixed this" or "awookga". I feel this is more justified than the javadoc case because you can always just leave out javadoc, whereas the VCS forces me to put a commit message.

I sincerely hope that you and I never work on the same project =(