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

81–90 of 138 posts

Re: An Opinionated Guide to Modern Java, Part 2

#81

Post by mindcrime »

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…

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.

What about OS/400, OS/390, MVS, etc?

Believe it or not, the world is a lot bigger than *NIX and Windows. Go track down a mid-sized manufacturing company in the midwest or the southeast, for example, and I'd almost bet you money they have apps running on an AS/400 (iSeries), or an S/38 or S/36 or something, if not a mainframe.

Re: An Opinionated Guide to Modern Java, Part 2

#82

Post by lmm »

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…

Having moved from Tomcat to embedded Jetty, it avoids a bunch of problems - no two linux distributions can agree on where to put Tomcat particularly when you need multiple instances, and they have an unfortunate tendency to run out of PermGen space and need restarting after you've done a few redeploys. But it's mainly just faster, and much easier to use in development; you can just run the same java class either way, so running it with a debugger is easy, hot code replace just works, etc. As a bonus you can avoid having an XML config file. It's not a huge difference but it makes life slightly easier.

Fully agreed with the zip and script though, that's what we do (using the appassembler maven plugin, so it just happens as part of the build).

Re: An Opinionated Guide to Modern Java, Part 2

#84

Post by peterashford »

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…

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.

Re: An Opinionated Guide to Modern Java, Part 2

#85

Post by zmmmmm »

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 there isn't a magic command for. This is also why you see blithe statements that you "don't need to know Groovy to use Gradle", etc. However these are only said after the fact when you've learned Gradle, understood enough Groovy to intuit what it's doing and then retrospectively realised there is a theoretical path from ignorance to enlightenment that didn't involve learning Groovy.

What you would probably like is Gant, which is Ant entirely converted to Groovy. It's missing all the higher level project stuff from Maven / Gradle, but it works a treat when you just want the simplest possible thing that could work.

Re: An Opinionated Guide to Modern Java, Part 2

#86

Post by eeperson »

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

Having moved from Tomcat to embedded Jetty, it avoids a bunch of problems - no two linux distributions can agree on where to put Tomcat particularly when you need multiple instances, and they have an unfortunate tendency to run out of PermGen space and need restarting after you've done a few redeploys. But it's mainly just faster, and much easier to use in development; you can just run the same java class either way,…

These arguments don't make sense to me.

I'm not sure why it matters that different distros put Tomcat in different locations. Embedding Jetty just means that now you have to restart every time. You could just do the same thing with standalone Tomcat instance. The only reason you are running out PermGen space on the redeploys is because your application is not cleaning up its threads on shutdown.

Why is it difficult to do any of those development things without having the server embedded in your application? Pretty much every Java build tool (Maven, SBT, Gradle, Lein) makes those things easy to do without specifying an XML file for your server. Also, they will frequently let you reload your application, which is faster.

Re: An Opinionated Guide to Modern Java, Part 2

#87

Post by curun1r »

pron wrote: post #75
curun1r wrote: post #29

Earlier quoted context omitted.

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)

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 Capsule took. This introduces unnecessary state and increases startup time. This is what servlet containers do, so reinventing that wheel seems like a particularly foolish decision. Not to mention that it appears that Capsule adds the additional step of pulling in all dependencies from an external server...slow deployment and an additional point of failure!

I still believe that some sort of VM image or container makes the most sense. Short of that, any system that supports sshd can be configured with Chef. The "solutions" I see coming out of the Java camp all seem like hacks by comparison.

Re: An Opinionated Guide to Modern Java, Part 2

#89

Post by paukiatwee »

lmm wrote: post #83

Does anyone actually swap out their log backend? To me slf4j felt like an overcomplicated, enterprisey step with no clear advantage over log4j.

Think slf4j as API, and logj4 as implementation. slf4j has multiple implementations, e.g. logj4, logback, apache common logging bridge, so you can swap implementation easily without change your code(except configuration)

Re: An Opinionated Guide to Modern Java, Part 2

#90

Post by xearl »

jebblue wrote: post #67
stuff4ben wrote: post #59

Earlier quoted context omitted.

Rather than downvote you, I thought I'd clear up the confusion. Yes Spring.io is the Spring Framework's website. Spring the framework is a dependency injection framework, but that's not all it does. There are other modules, like Spring Roo, Spring MVC, Spring JPA, etc that provide more than just dependency injection.

OK, I recalled it being a different looking site about three years ago then I saw Pivotal at the bottom of the page so I'm still not sure if VMware sold the Spring business or what. The whois reports for vmware.com and spring.io look nothing alike either. Thanks for clarifying spring.io is really Spring Framework.

VMware is owned by EMC. VMware bought Spring Source. EMC bought Pivotal Labs. VMware and EMC subsequently decided to spin-out a few of their acquisitions, including Spring and Pivotal Labs: into a company they dubbed Pivotal Software.
Post reply on HN