Live data from Hacker News

An Opinionated Guide to Modern Java Development, Part 1

blog.paralleluniverse.co

11–20 of 402 posts

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

#11
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 trick is to simply have small, cohesive projects linked by common REST (et al) API's and to merely skirt complexity entirely. However, for workflow and state management, you'll inevitably need some common integration point.

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

#12
One of my opinions these days on javadoc is that you should be minimalist. Have nothing to say about the return type? Don't add @return. Same for @param. Just a sentence about the method/field/class? Just a single line /* * ... */ is fine. Have nothing of value to say on a method/field/class (e.g. a getter), don't add javadoc at all. I'm growing weary of large files with tons of redundant javadoc lines to make some checkstyle/pmd rule happy.

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

#14

One of my opinions these days on javadoc is that you should be minimalist. Have nothing to say about the return type? Don't add @return. Same for @param. Just a sentence about the method/field/class? Just a single line /* * ... */ is fine. Have nothing of value to say on a method/field/class (e.g. a getter), don't add javadoc at all. I'm growing weary of large files with tons of redundant javadoc lines to make some c…

Yeah, I'm of the opinion that if you need a class/method comment to explain what it takes in or spits out, you probably named it badly.

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

#15
post #13

The position of things like Netty and Undertow at the top of the techempower benchmarks has me a little intrigued. How much hassle is it to write websites with servlets like that?

A bit of a hassle, but Comsat will make it dead-easy (right now Comsat runs on top of any servlet container, but it will also run directly on top of Netty/Undertow). Take a look at our Comsat web actors: http://blog.paralleluniverse.co/2014/01/28/web-actors-1/

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

#16
post #9
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 ?

IMO dependency injection encourages making very deep object graphs. constructor argument passing can be cumbersome, but jumping into new code it is much more clear, and it encourages you to write flatter code structures. i go without.

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

#17
It's ironic, I'm slowly trying to move my development over to scala. I'll likely integrate gradle in to my stack (still use maven =/ mainly because I know all of its weird quirks)

What have people's experiences with gradle been? I'm not a huge fan of groovy hence why I stayed away from it.

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

#18
post #9
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 ?

I think the point is that you don't want to be instantiating (and thus configuring) a dependency at the site where it is used. The code in class Foo should be limited to implementing Foo, not instantiating and configuring its dependency Bar.

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

#19
post #9
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 ?

Not to sound snarky, but you should read any introduction to dependency injection. The benefits are generally covered very thoroughly, and what you said is not usually considered a benefit.

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

#20
post #9
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 ?

[deleted]
Post reply on HN