Live data from Hacker News

An Opinionated Guide to Modern Java Development, Part 1

blog.paralleluniverse.co

161–170 of 402 posts

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

#161
post #93
post #2

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

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.

Thankfully I am seeing more and more comments like this. I really think we off the deep end with all this. Simple is key.

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

#162
post #80
post #70

Earlier quoted context omitted.

I have since repent myself. Google did indeed managed to pull a Microsoft and now we have a forked Java implementation getting steady behind the standard Java implementations. Even J2ME is more compatible with its big brother than Android. KitKat has now partial support for Java 7, with libraries still missing some pieces. Dalvik and ART still don't support invokedynamic bytecode. And since almost no one has KitKat,…

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

> Plus the Android tooling is horrible to get working reliably - most problems being solved by "restart eclipse"

Try Intellij IDEA / Android Studio. I find them quite reliable.

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

#163
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.

Yep, Maven is the defacto AFAICT. But so is Java 6 currently.

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

#164

Earlier quoted context omitted.

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…

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…

SBT has a terrible habit of breaking backwards compatibility, which has put me off it.

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

#165

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

> or a polymorphic event API with dedicated method types for each event

Exactly!

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

#166
post #131

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…

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

For rest services in java I really recommend Dropwizard. Wraps a bunch of great libraries together with just enough glue to make your development easy. Really great support for metrics.

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

#167
post #93
post #2

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

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...

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

#168

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

Nice! In the past I've used my own loader main to run inside Jetty, now I can just use this. I love finding cool java projs I've never heard of.

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

#169
post #80
post #70

Earlier quoted context omitted.

I have since repent myself. Google did indeed managed to pull a Microsoft and now we have a forked Java implementation getting steady behind the standard Java implementations. Even J2ME is more compatible with its big brother than Android. KitKat has now partial support for Java 7, with libraries still missing some pieces. Dalvik and ART still don't support invokedynamic bytecode. And since almost no one has KitKat,…

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

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

#170
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...

JDBI is quite good: http://jdbi.org/
Post reply on HN