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

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

#201

Post by cgh » Thu, May 01, 2014, 8:56 PM UTC

ishbits wrote: post #151

twistedpair wrote: post #11

Earlier quoted context omitted.

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…

Modern Spring is quite nice, and after having tried Play, I go back to Spring MVC, but use Spring-Boot with Jetty was the embedded container. Its much like Dropwizard, but better integrated with Spring if that is what you are used to or like. No XML, and I can produce a usable web API with a minimal amount of boiler plate (its all wrapped up in Spring boot, much like Play wraps up a lot of stuff for you).

Yes, Spring Boot is pretty cool. Not a bit of xml in sight, unless you want it, of course. And you have the choice of deploying with an embedded Tomcat or as a more traditional war.

I think a lot of "big Java" haters haven't looked at Spring or JEE (which has seen similar massive improvements) in the last several years.

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

#202

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

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…

I was just recently trying to decide between "new" Spring MVC, Dropwizard, and Play.

Spring now has a bunch of slick-looking guides and tutorials. But then I looked at the actual contents of their tutorial project, and it just turned me off. For an "example" REST project, they had over 50 classes not including tests: https://github.com/spring-guides/tut-rest/tree/master/6/comp... , with many being "event" classes of some sort. I mean, WTF, is this really the "idiomatic" way to build Spring REST/MVC projects nowadays? I'm trying Dropwizard for now.

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

#203

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

stevoski wrote: post #159

lmm wrote: post #122

Earlier quoted context omitted.

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);

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

#204

Post by mushishi » Thu, May 01, 2014, 9:16 PM UTC

EdwardDiego wrote: post #167

jebblue wrote: post #93

Earlier quoted context omitted.

I try to avoid it as much as possible. It's confusing at least to me and makes maintaining code over a long haul an arduous dull process. I'm getting to the point where I prefer straight JDBC over Hibernate too. It takes longer to code but I've seen speed increases of several times over Hibernate in those situations. JDBC code is just linear but I feel it's easier to maintain in the long run.

I agree. Hibernate has become a downright liability at times in our codebase. These days I only use it in new code for query parameterization and result row transforms into models. Speaking of which, if anyone knows of a good library for query parameterization alone, let me know...

Checkout Dalesbred, http://dalesbred.evident.fi/

It's our in-house jdbc library, and has IDEA plugin. We use it in many small projects, and in one major.

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

#205

Post by cakeface » Thu, May 01, 2014, 9:17 PM UTC

stevoski wrote: post #159

lmm wrote: post #122

Earlier quoted context omitted.

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.

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

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

#206

Post by kazagistar » Thu, May 01, 2014, 9:23 PM UTC

tieTYT wrote: post #69

That pluggable type system looks amazing. One thing that's weird to me is how java included a new Optional type (seems similar to Haskell's Maybe), but the compiler (afaik) doesn't prevent you from setting an Optional field to null. Something about that doesn't feel right. (Side Note: Optional isn't serializeable. Also... what's the best practice for using Optional when I'm using JPA? Can it be used in my Entities?)…

The main issue with non-nullable types in OOP, in my mind, seems to be defaults. Quite simply, when you don't initialize an primitive, you get a 0, and when you don't initialize an object, you get a null. Not all fields must be initialized by the time the constructor ends, so some kind of valid default exists.

Enforcing non-nullability would involve somehow enforcing that the variable is always valid before use some other way, like how "final" is enforced in the constructor, but it should be possible.

Unless you make it default, though, it won't be as "elegant" as the haskell Maybe, and doing so would net you a very very different language.

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

#207

Post by tieTYT » Thu, May 01, 2014, 9:30 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…

> 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 confidence that my maven filtering is working the way I want it to. But it sounds like gradle isn't built with that in mind.

Considering that groovy is dynamically typed, if my IDE doesn't auto complete (maybe it does) I think it's possible to make the argument that Maven is the least awful of the 3. At least the maven XML has a schema. I don't need yet another way to make a mistake in my build script (ie: typing issues).

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

Such as?

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

#208

Post by kitd » Thu, May 01, 2014, 9:30 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…

Guice and SiteBricks [1] work very well together.

[1] http://sitebricks.org/

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

#209

Post by mateuszf » Thu, May 01, 2014, 9:35 PM UTC

stevoski wrote: post #159

lmm wrote: post #122

Earlier quoted context omitted.

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.

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.

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

#210

Post by Glide » Thu, May 01, 2014, 9:36 PM UTC

UK-AL wrote: post #79

rymndhng wrote: post #21

Earlier quoted context omitted.

It depends. One thing that I thought is an interesting feature of Spring, is that it allows the framework to inject code between your dependencies like decorators. This allows them to do aspect-oriented-programming transparently. And I think there's some interesting ideas here. For example, you can mark the interface of a class as @Transactional, and all your implementations will get the behavior.

I think that's the interception way of AOP? Unity IoC in c# also does this. The IoC container will return transparent proxy(Not the original object), which then calls the underlying method(after doing the AOP behaviour).

Be careful of using these though.

I had an obscure bug using dynamic proxy (castle dynamic proxy2) a while ago in a WPF application. I was proxying to an interface so it created a proxy object in between that in the actual class so it was eating my C# event. Changing the proxying from an interface to a subclass fixed it.

Boy that was a fun one to figure out.