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

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

#131

Post by lmm » Thu, May 01, 2014, 6:41 PM UTC

twistedpair wrote: post #11

bsaul wrote: post #6

I'm back to java after having an unsatisfying experience 2 years ago with Spring MVC, (this time i use the "play framework"), and it seems to confirm my intuition that the language itself is really just fine. The problem lies more in bloated frameworks and corporate culture where everything needs to be standardized, regulated, and the purpose of a mandatory non-free training session. Add to that the fact that every s…

How's Play! compare to Spring? I'm working on a bloated Spring whale (1.5M LoC, 485 Spring XML config files) and wondering if something like Play! can do it better, or if complexity is simply a beast that will inevitably turn any project into a turgid mass. I ask since friends at Google will laugh at a bar if you even say "Spring," but I'm curious what else can do it all (Guice/Gin?). Perhaps nothing can and the tric…

Spring is a huge umbrella project that contains many parts, some good, some not so good. Guice or picocontainer work well, but you can achieve the same effect by using spring's Java configuration and avoiding silly things (AOP, shudder), and that way you can migrate existing spring XML piece by piece.

If you're writing an actual webapp (i.e. something that outputs html) then I highly recommend Wicket; it's the most beautiful framework I've ever used, in any language. If it's just REST APIs I can't really recommend anything - by the time I started writing those I'd switched to Scala (in which Spray is wonderful).

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

#132

Post by nsxwolf » Thu, May 01, 2014, 6:41 PM UTC

wil421 wrote: post #124

>But the modern Java developer uses Gradle...there are quite a few things that are quite, though not very, common, but still require dropping down to imperative Groovy. This is the first time I have heard of Gradle, but why would I use a build tool that requires me to learn Groovy. If I already know Java I wont be learning something new just to build a Java project. I find a lot of development tools/frameworks make m…

I wouldn't say you need to actually learn Groovy to get going with Gradle. The example build.gradle files are fairly self-documenting, and you'll be modifying them more than writing them from scratch.

Easier to read than a pom.xml, for sure.

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

#133

Post by ddeck » Thu, May 01, 2014, 6:42 PM UTC

veeti wrote: post #4

netcraft wrote: post #2

What about dependency injection in modern java - is Guice or spring still the de facto standard?

I only do Java on Android, but Dagger ( https://square.github.io/dagger/ ) might be a nice lightweight alternative.

Dagger is definitely more appropriate for Android applications and was developed specifically to address the issues with using something like Guice on mobile. That said, I love Guice and use it exclusively as it has a superset of features and startup performance is irrelevant in my area.

As Christian Gruber from the development team put it:

Dagger is a joint effort by Square, Google, some individual contributors from other places such as Nextflix, and is descended conceptually from Guice - specifically from MiniGuice. It addresses some key challenges our users faced with Guice. From Square’s side (/u/swankjesse can clarify this) it was the need to get high-performance, low-startup dependency injection on Android. From our side, it was that and the desire to trim the API weight of dependency injection, to reduce the user confusion that comes from reflection and bytecode generation in stack traces and debugging environments, and to get early validation of your graph’s wiring.

Dagger is a substantial direction shift for Google, and we are investing time and resources in it. Guice will always have a superset of features compared to Dagger, though we do have projects using Dagger on the server and in stand-alone java apps. But Dagger is not as evolved in terms of the surrounding "scaffolding" code (servlet support, etc.) as Guice, and won’t be for quite some time. Additionally, some teams will need or want some advanced Guice features that will never make it in to Dagger. [1]

[1] http://www.reddit.com/r/java/comments/1y9e6t/ama_were_the_go...

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

#134

Post by lmm » Thu, May 01, 2014, 6:43 PM UTC

bananas wrote: post #34

benjaminpv wrote: post #22

Earlier quoted context omitted.

Seconded. I always bristle when I see javadocs that include things like 'returns an object of [x] type that...' You're dealing with strong types, the signature provides all this information already. That, combined with good variable names, should do a lot of the documentation for you. If you wanna document a method, document what problem it solves. Document any gotchas (or better yet, redesign them out o_~). Don't ju…

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.

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

#135

Post by oldmanjay » Thu, May 01, 2014, 6:43 PM UTC

smrtinsert wrote: post #105

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.

There are no winners in the build war despite the overwhelming online support for Gradle. Personally I'm not a fan of it. I find it on the slow side even compared to maven. I'd rather have declarative builds like Ant but therefore support better tooling than super freeform tools like Gradle that force you to drop into a language with about as much type safety as Javascript. Multi-project builds are also annoying, as…

I've definitely found gradle to be faster than maven, particularly using the daemon, and even more so considering the extensive support for understanding when a task is up-to-date. I haven't run a clean task in gradle in several months, but in maven it seemed to be a crapshoot if the clean was required or not. That saves a lot of time.

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

#136

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

sztanko wrote: post #130

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…

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.

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

#137

Post by jebblue » Thu, May 01, 2014, 6:45 PM UTC

bradleyjg wrote: post #94

jebblue wrote: post #83

Good article, lots of opinions but the title forewarns. For me, Eclipse is still very good and if anything, more stable than in earlier years. I've tried NetBeans and the free IntelliJ but though those are fine, Eclipse is better for me. The real trick is to _not_ store your code in the workspace (which is ironically where the project wizards default to unless you change it). Store your code in as an example, svn for…

As an eclipse user this suggestion intrigues me, but I'm not sure what the workflow would actually look like. Do you have a pointer to an article or something? Thanks.

Sorry no link, co-workers and as "smrtinsert" said, Git or for me having both Git and Subversion projects makes life easier keeping source separate from the workspace.

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

#138

Post by pron » Thu, May 01, 2014, 6:46 PM UTC

leorocky wrote: post #53

I love Java, especially Java 8. But as the article points out, what frustrates me is threading. You can't do much without quickly running into threading issues. I played audio files in a game I made and it created up to 2,000 threads and crashed. Once I wrapped audio in an explicitly created thread this issue magically went away. Any kind of UI, timers, file I/O and network activity also involves threads. The really…

Go makes it even harder not to share mutable memory, as it has no 'final'. But if you read the whole article you'll see that Java now has lightweight threads with cheap blocking - just like Go or Erlang.

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

#139

Post by lmm » Thu, May 01, 2014, 6:49 PM UTC

Terr_ wrote: post #71

benjaminpv wrote: post #32

Ironically the Java ecosystem could stand to use some garbage collection of its own: there's a ton of old, outdated info out there that both colors people's impressions of the language and teaches new players a whole manner of bad habits. I appreciate what this article's going for and hope there'll be follow-ups. I use Java daily and though there's undoubtedly room for improvement (I'm looking forward to when tooling…

> old, outdated info out there I'd love it if the JDK had a "learner mode" that disabled interned string literals . Then newbies experimenting with `assert(str1 == str2)` wouldn't leap to false conclusions.

== should never have been used for that method, which is very rarely what you want. The right thing is probably to deprecate == on nonprimitive types, replacing it with a longer name that's clearer about what it means.

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

#140

Post by ddeck » Thu, May 01, 2014, 6:51 PM UTC

bsaul wrote: post #9

exabrial wrote: post #3

Earlier quoted context omitted.

I agree... can't live without Dependency Injection (one of the reasons I refuse to move off of Java). I've been using CDI and TomEE for small simple stuff (it just works). Can't stand Spring Framework anymore. It set out to replace the bloatware of Java EE 1.5 but it ended up becoming what it was meant to replace.

Genuinely curious : i've been playing with dependency injection, and really never got to understand the true use of it. I mean, what's the point of being able to replace an implementation outside the source code itself ? You'd still have to extensively test the thing and recompile it... Is there more to it than just being able to replace a class by its mock up, for unit testing ?

There are definitely more advantages than just the unit testing side. The Google IO talk on Guice does a pretty good job of explaining the benefits:

https://www.youtube.com/watch?v=hBVJbzAagfs