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

101–110 of 138 posts

Re: An Opinionated Guide to Modern Java, Part 2

#101

Post by bruceboughton »

pron wrote: post #71
twic wrote: post #69

Earlier quoted context omitted.

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…

So your production application can potentially run in an untested configuration because someone has pushed a new version of XyzLib.

Again, for what advantage?

I mean, fine if you want to do that. But I wouldn't call it Modern Java or recommend anyone else do it.

Re: An Opinionated Guide to Modern Java, Part 2

#102

Post by john-waterwood »

bad_user wrote: post #72
pron wrote: post #43

Earlier quoted context omitted.

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 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 then and work from there.

Re: An Opinionated Guide to Modern Java, Part 2

#103

Post by john-waterwood »

philbarr wrote: post #12
benjaminpv wrote: post #6

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

App servers like TomEE, JBoss and GlassFish are not hard to install at all, and certainly not to dev against. What's the author smoking?

These servers are just unzip == fully installed things. We have them checked in and just deploy them automatically whenever there's a need for an update, pretty much as every other library out there.

I wonder are we missing something or do people just wrongly think there's "something" difficult, where there's no need at all for things to be difficult?

Re: An Opinionated Guide to Modern Java, Part 2

#104

Post by pron »

curun1r wrote: post #87
pron wrote: post #75

Earlier quoted context omitted.

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

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.

Re: An Opinionated Guide to Modern Java, Part 2

#105

Post by smikhanov »

Crito wrote: post #95
peterashford wrote: post #84

Earlier quoted context omitted.

I've written telephony apps that deployed to Linux, Unix and Windows. I've written an OpenGL / Swing app on Windows and deployed it for Mac. This kind of stuff (a) does happen and (b) is valuable.

I don't understand how you believe that I was implying that nobody develops cross platform software. I am talking about one specific kind of development: Service/backend development done in-house in a corporation that is not a software vendor. If you're doing Swing/OpenGL work, you're not doing the sort of work that I am talking about. In my experience, while this sort of development may deploy to different nix's at…

Portability of Java helps you avoid the situation when your sysadmin tells you that he just upgraded a production server because the previous version of your distro reached its EOL and now your product does not start because libfoobar.so that you depend on is not included in the distro any more and he can't build it from source because the distro's default compiler also switched from gcc to clang.

Portability is important, even when you supposedly know your deployment platform.

Re: An Opinionated Guide to Modern Java, Part 2

#106

Post by objectified »

pron wrote: post #38
eeperson wrote: post #35

As a Java developer, I thought this article had some interesting information about logging and monitoring. However, the deployment section had my scratching my head a little. I've never totally understood why people want to make fat jars. It seems like a process full of headaches since you can't have jars in jars. Wouldn't it be much easier to create a regular zip file with a small script to set the classpath and and…

Author here. A capsule is not necessarily a fat jar. It can point to Maven dependencies that are downloaded on the first launch, and can later be shared by other capsules. A zip with startup scripts is OK, but it requires installation. As to full blown app servers vs embedded servers, I think it's the other way around. It's the big app servers that require justification, as they are a lot more cumbersome to set up an…

It can point to Maven dependencies that are downloaded on the first launch

Please don't. Never assume that production machines have access to the internet or even an internal Maven repository. If they do, they're a security risk. There are plenty of scenarios I can think of where an attacker could possibly make your application download something from the internet, or has your application server functioning as an anonymous proxy by exploiting your application.

Re: An Opinionated Guide to Modern Java, Part 2

#107

Post by twic »

pron wrote: post #71
twic wrote: post #69

Earlier quoted context omitted.

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…

Interesting. I feel much more confident about deploying the right thing using an operating system package than some other mechanism. Almost everything else in the datacentre is deployed using operating system packages, so we get a lot of practice at deploying the right versions of things. The few legacy applications we have that are deployed via custom mechanisms are a headache - they require completely different tooling and troubleshooting knowledge to everything else.

But then, i have spent a fair amount of managing machines, shuffling packages around apt repositories, writing Puppet code and so on. Perhaps for a developer who has not served a sentence in operations, operating system packages are a less comforting proposition.

You seem to be very keen on avoiding "installation". Could you tell us about why that is?

And could you remind me what the added features of a capsule are? Putting aside the differences in delivery mechanism, which as i've said, i'm afraid i see as misfeatures, the only one i see is that it automatically finds the right JRE.

(Sorry you're being downvoted, by the way. I think this is an interesting discussion, and your gracious responses deserve upvotes, not downvotes.)

Re: An Opinionated Guide to Modern Java, Part 2

#108

Post by pron »

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…

1. Because the Java ecosystem usually gives you an API to everything: you can configure things to work exactly as you want. Everything is programmable and easily hackable.

2. Because everything is standardized, which is a lot easier than stitching together lots of pieces, each has to be deployed upgraded, configured, monitored and managed differently.

3. Because some Java libraries are used to do very sensitive stuff (performance wise, or correctness wise, or security wise), Java libraries, on average, tend to be of very high quality, at least relative to almost everything else (well, except maybe the Java browser plugin, but we're talking server-side here).

4. With Capsule there is no need to use a custom class loader, it's not any clunkier than Docker, and it's cross platform. It's just a cross-platform Java executable, which is stateless and requires no installation.

Re: An Opinionated Guide to Modern Java, Part 2

#109

Post by Patient0 »

philbarr wrote: post #12
benjaminpv wrote: post #6

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

Where did you find part 3?

Re: An Opinionated Guide to Modern Java, Part 2

#110

Post by pron »

bruceboughton wrote: post #101
pron wrote: post #71

Earlier quoted context omitted.

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…

So your production application can potentially run in an untested configuration because someone has pushed a new version of XyzLib. Again, for what advantage? I mean, fine if you want to do that. But I wouldn't call it Modern Java or recommend anyone else do it.

How is that any more dangerous from deploying and installing an OS package? It's very hard to accidentally deploy to a release Maven repo. Maven Central makes you jump through hoops, and organizational repos have their own safeguards. They already deploy everything to their Maven repo anyway, why deploy again?

And if you don't want to enable automatic upgrades, you still get stateless, installation-free deployment.

Post reply on HN