Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An Opinionated Guide to Modern Java, Part 2

blog.paralleluniverse.co

Post reply on HN
Print view View original

71–80 of 138 posts

Re: An Opinionated Guide to Modern Java, Part 2

#71

Post by pron »

twic wrote: post #69
pron wrote: post #63

Earlier quoted context omitted.

Well, you can choose to embed the dependencies in the capsule, but I think the best approach for production deployment is have an organizational Maven repository (Artifactory/Nexus). This way you upload the libs, and the jars containing the actual apps to your repo, and all you need to do is restart the capsule (it can be configured to load and run the latest version).

So you're downloading jars from the repository to the production server when the app starts? I would feel very uneasy about that kind of coupling. And i still don't see what advantage this has over just pushing out normal packages.

I feel uneasy about deploying the wrong version. With capsule, at launch it checks for a new version in the repo (if you configure it to use the newest version rather than a specific one). The packages are only downloaded once: not on every restart.

Alternatively, you can embed the dependencies, in which case it's just like a "normal package", only it doesn't require installation, and is just as easy to create (your build tool can create it). So it's a platform independent "normal package", with added features.

Re: An Opinionated Guide to Modern Java, Part 2

#72

Post by bad_user »

pron wrote: post #43
benjaminpv wrote: post #33

Earlier quoted context omitted.

Fair enough, it's a matter of terminology then, I guess? Generally I think of Tomcat as being as much of an application server as something like JBoss is. Granted, JBoss/Wildfly has a lot more enterprise-y features, but they both 'serve' web 'applications.'

I was talking about app/servlet containers (Tomcat, JBoss, WebSphere, etc.), vs embedded, single-app servers (Jetty, embedded Tomcat, and Dropwizard, which is essentially Jetty+Jersey+added goodies)

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 first and foremost the servlets API, which is pretty light and arguably good (well, at least since the latest Servlets 3.1, which finally adds asynchronous readings of requests).

Servlets is the piece of Java EE that I actually like - for everything else, there are third-party libraries and frameworks - though I've been working lately with Play framework, which comes with its own server and deployments on top of servlet containers is not officially supported, but that was primarily because it is a fully async framework and Servlets I also prefer embedding and the deployment of fat JARs to WARs. Makes things easier - a WAR implies that you need a management interface and a configured instance of your production server. A JAR implies that everything comes bundled in, configuration and all and you only have to copy and execute it directly, plus with embedding you have more fine-grained control. When I was using an embedded Jetty for example, a fine-tuned the shit out of its thread and connection pools, all from code.

Re: An Opinionated Guide to Modern Java, Part 2

#73

Post by vorg »

> I personally prefer Gradle’s nice DSL [...] in order to use Gradle one does not need to know Groovy, even if one wishes to do some non-standard stuff [...] I just learned a few useful Groovy expressions that I found in Gradle examples online

The DSL is Groovy syntax from Groovy's antiquated Antlr 2.7 grammar, so simply by using Gradle you're using Groovy along with all its warts. Underneath, Gradle isn't so much a DSL as an API shipping with a programming language. You could just as easily write the first Gradle example from the article in most other JVM languages. If it was in Clojure...

  (require gradle :as g)

  (g/apply :plugin "java")
  (g/apply :plugin "application")

  (g/source-compatibility "1.8")

  (g/main-class-name "jmodern.Main")

  (g/repositories
    (g/maven-central))

  (g/configurations
    g/quasar)

  (g/dependencies
    (g/compile "co.paralleluniverse:quasar-core:0.5.0:jdk8")
    (g/compile "co.paralleluniverse:quasar-actors:0.5.0")
    (g/quasar "co.paralleluniverse:quasar-core:0.5.0:jdk8")
    (g/test-compile "junit:junit:4.11"))

  (g/run
    (g/jvm-args (str "-javaagent:" (-> (configurations.quasar.iterator) next))))

Re: An Opinionated Guide to Modern Java, Part 2

#74

Post by cmicali »

asdf1234 wrote: post #28
cmicali wrote: post #15

Nice article - Many of the suggestions (single-jar deployment, metrics, slf4j logging, etc) are all wrapped up for you in Dropwizard http://dropwizard.io , which we use and love.

Do you just use it for producing a REST API or do you use it to render HTML, handle session management etc.?

We use dropwizard only for rest APIs currently. Our HTML and JS are served up with an in-house framework that has plugins for less, minimization, svg inlining, etc. We have open tasks to both publish it and make it hostable in dropwizard directly.

Re: An Opinionated Guide to Modern Java, Part 2

#75

Post by pron »

curun1r wrote: post #29
philbarr wrote: post #21

Earlier quoted context omitted.

Java - "run anywhere" (supposedly) Docker - "The Linux Container Engine" Think you've got your answer there.

Docker is an option if you're deploying on Linux, which is what the majority of server deployments use these days. Chef works on the rest of the Unixes, including OS X. If you're deploying Java on a Windows server, you're doing it wrong. And the days of needing to use different development and production OSs are over...if you develop in Windows and deploy on some Unix variant, you should be using a VM. I'm still not…

Capsule has exactly 0 class-loader contortions (that's why I'm not too keen on One-Jar)

Re: An Opinionated Guide to Modern Java, Part 2

#76

Post by pjmlp »

sehugg wrote: post #45
pjmlp wrote: post #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.

You can do this from the JVM command line with "-XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly". (it's kind of a mess, though)

Yes, it still requires the plugins which aren't delivered with the JDKs and each JVM does it a bit differently, but is possible.

As complement of it, check JIT Watch

https://skillsmatter.com/skillscasts/5243-chris-newland-hots...

Re: An Opinionated Guide to Modern Java, Part 2

#77

Post by smikhanov »

curun1r wrote: post #19
jacobheric wrote: post #13

Earlier quoted context omitted.

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

Because Java-only solution to a complicated problem is normally simpler.

Few reasons contribute to that. One of them is exhaustive pure Java library ecosystem, which means that it's very unlikely that you'll run into intricacies of native library access on your host system. Another is excellent tooling, which means that when all your processes are Java processes, lots of operations-related tasks (process management & monitoring, log rotation, etc) get significantly easier.

More on that I wrote few weeks ago: http://www.mikhanov.com/2014/03/31/a-love-letter-to-java-363

Re: An Opinionated Guide to Modern Java, Part 2

#78

Post by pjmlp »

Crito wrote: post #34
philbarr wrote: post #21

Earlier quoted context omitted.

Java - "run anywhere" (supposedly) Docker - "The Linux Container Engine" Think you've got your answer there.

> Java - "run anywhere" (supposedly) Sure, it's a nice benefit, but is it actually used? In 2014, how many of us are doing backend/service development in java and not deploying to Linux machines? There are certainly still backend/service java shops out there that aren't deploying to linux machines, but I wager that most are. Regardless of those numbers though, why do the linux shops actually care about being able to…

GNU/Linux != UNIX, and there are still lots of it on the enterprise.

At the enterprise it is also common to develop on Windows and deploy across Windows and UNIX systems.

Finally, there are quite a few banks, finance and insurance institutions running Java on mainframes.

Re: An Opinionated Guide to Modern Java, Part 2

#79

Post by pjmlp »

gsmethells wrote: post #37

As far as packaging and deployment of a native executable goes, I thought it odd to not mention Excelsior JET ( http://www.excelsiorjet.com ) as I believe that's the only Java compiler that can handle all of the JDK (gcj isn't there yet).

gcj is dead since 2009.

The only alternatives, besides Excelsior, is the new RoboVM, Websphere Realtime JVM, Aicas, Aonix among a few other ones.

And if Graal eventually replaces Hotspot on the reference JVM, it might be that Truffle comes along as well.

Re: An Opinionated Guide to Modern Java, Part 2

#80

Post by lmm »

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 reply on HN