An Opinionated Guide to Modern Java, Part 2

Post by bad_user » Fri, May 09, 2014, 3:49 PM UTC

john-waterwood wrote: post #102

bad_user wrote: post #72

Earlier quoted context omitted.

Dropwizard is a framework that delegates to Jetty the responsibility of serving requests by default, but you can host a Dropwizard app on whatever server you like. In Java terminology, "application server" has actually started to mean servers capable of the full Java EE stack, which really means EJB and JMS. Jetty is not capable of those. Tomcat from what I know is not capable of those either. Both are targeting firs…

Thinking Java EE is primarily about EJB and JMS is pretty old school. These days CDI is the centrepiece of Java EE, along with services like Interceptors and Bean Validation. JPA, JSF and JAX-RS also play pretty important roles, which are all things you don't find by default in Tomcat. Actually, nearly every time I see people using Tomcat they add many of the things mentioned above. You might as well start with TomEE…

Post by philbarr » Fri, May 09, 2014, 4:04 PM UTC

Patient0 wrote: post #109

philbarr wrote: post #12

Earlier quoted context omitted.

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.

Where did you find part 3?

Post by mike_hearn » Fri, May 09, 2014, 4:27 PM UTC

lmm wrote: post #80

eshvk wrote: post #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…

What abstractions? You have a project which has a name and some other metadata and it has a bunch of dependencies. If your build does something weird then it also has plugins, but you should try to avoid those as much as possible. I guess profiles could be confusing, but again, try to avoid them. Maven is the simplest build tool I've used, in any language.

Post by eshvk » Fri, May 09, 2014, 5:16 PM UTC

zmmmmm wrote: post #85

eshvk wrote: post #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…

I find all of them hard to work with, because they are all aiming for the modern day "zero configuration" nirvana that Ruby on Rails achieved, and thus enormous amounts of implicit knowledge is required to understand them. Part of the problem is that the initial steps are so easy that you're actually never forced to learn the mechanics of what is happening. Hence you get away with a lot until you need to do something…

Post by curun1r » Fri, May 09, 2014, 6:40 PM UTC

pron wrote: post #104

curun1r wrote: post #87

Earlier quoted context omitted.

ClassLoader contortions are one of the cleaner ways to handle the problem, but they're not the only way. You could: - Create a fat jar, which necessitates bytecode transformations to prevent namespace collisions if you don't want to be sloppy. JarJar did this kinda of thing many years ago, but it seems hard to trust a process like that. - Create what is essentially a self-extracting archive. This looks like the path…

The next release will include the option to resolve (potentially download) all dependencies without launching the app, if someone finds that useful. If dependencies are resolved, or are embedded, startup time is increased by 100ms or so.