Live data from Hacker News

An Opinionated Guide to Modern Java, Part 2

blog.paralleluniverse.co

11–20 of 138 posts

Re: An Opinionated Guide to Modern Java, Part 2

#11
post #5

As someone not very familiar with Java can someone expand on what he means by this: "Every library is usually packaged into its own JAR, and merging all dependencies into a single JAR, might cause collisions, especially with packaged resources (non-class files)."

Class loaders work in a tree, and there typically isn't sharing between sibling branches. I believe that visibility is up the tree, and never across. So, you can end up with two different versions of a library existing quite happily in the same process space. Collapsing them down into a single [ejsw?]ar file results in the tree being collapsed down too.

All of a sudden all of the log4j.xml files that everyone has sprinkled everywhere end up overwriting each other...

Re: An Opinionated Guide to Modern Java, Part 2

#12

"Java application servers are dead" and since there's no alternative to Java application servers here's a solution I cooked up myself. Like I mentioned last time I appreciate an overview of modern Java practices but boy howdy I can't discern if this is clever trolling or a cheap way to make me read Part 3.

I skimmed through Part 3 and it's basically saying that app servers are hard to deploy, maintain and dev against and you should be using Spring Boot or Dropwizard instead to create applications with the services you require.

Re: An Opinionated Guide to Modern Java, Part 2

#13

"Java application servers are dead" and since there's no alternative to Java application servers here's a solution I cooked up myself. Like I mentioned last time I appreciate an overview of modern Java practices but boy howdy I can't discern if this is clever trolling or a cheap way to make me read Part 3.

I'd not go so far as to say it's trolling. Perhaps overly-dramatic hyperbole. As a Java developer, I do see a shift away from packaging up wars and deploying them to application servers. See Dropwizard or Spring Boot for examples of frameworks that prefer to run fat jars that serve http requests via embedded containers.

Re: An Opinionated Guide to Modern Java, Part 2

#16
> While I personally prefer Gradle’s nice DSL and the ability to use imperative code for non-common build operations, I can understand the preference for the fully declarative Maven, even if it requires lots of plugins. The modern Java developer, then, might prefer Maven to Gradle.

I find Maven's abstractions surprisingly hard to understand. It is a major part of my annoyance with Java as a dev setup. I miss Make/Ant. Not sure if Gradle will be a good replacement or not but would be curious to try.

Re: An Opinionated Guide to Modern Java, Part 2

#17
I'm glad someone took the time to write this, it's actually a very nice resource to get new coworkers up to speed. Shouldn't be tought as dogma of course (e.g. Gradle vs. Maven).

Also, thanks for mentioning Packr even though noone has used it in production yet. It's only a week old.

Assuming OP is the original author: are you by any chance following JGO? I see Quasar is actually using Matthias Mann's green thread lib which i don't think was advertised anywhere outside JGO.

Re: An Opinionated Guide to Modern Java, Part 2

#18
I like the overview given to JVM tooling, many developers are fully unaware of what JVMs (not only the official one from Oracle) offer in terms of monitoring.

If you want to go really low level, a few of them even show the generated assembly code by the JIT.

Re: An Opinionated Guide to Modern Java, Part 2

#19

"Java application servers are dead" and since there's no alternative to Java application servers here's a solution I cooked up myself. Like I mentioned last time I appreciate an overview of modern Java practices but boy howdy I can't discern if this is clever trolling or a cheap way to make me read Part 3.

I'd not go so far as to say it's trolling. Perhaps overly-dramatic hyperbole. As a Java developer, I do see a shift away from packaging up wars and deploying them to application servers. See Dropwizard or Spring Boot for examples of frameworks that prefer to run fat jars that serve http requests via embedded containers.

Why is the Java community so enamored with creating Java-only solutions when general-purpose solutions work just as well (and often better)?

There's no need to bundle everything up into an executable jar or war. It's much easier to write a Chef recipe to copy all the right files to the right places. And it's even easier to create a Docker container with the exploded war in its correct place. Both of those solutions don't rely on the clunky put-everything-inside-a-jar and the resulting need to write your own ClassLoader.

Re: An Opinionated Guide to Modern Java, Part 2

#20
post #14

I'm a fan of simplifying the server side, one I'd recommend for the latter part of the slideshow he referenced: http://www.sparkjava.com/

...or just use JAX-RS, which is simple, standardised, and has good implementations (such as RESTEasy and Jersey).
Post reply on HN