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

111–120 of 138 posts

Re: An Opinionated Guide to Modern Java, Part 2

#111

Post by pron »

agibsonccc wrote: post #94
derengel wrote: post #54

Earlier quoted context omitted.

is that really a big issue? passing the arguments to java to configure the jvm.

It can be. Here's a typical example from my day to day: java -cp "lib/*" -Xmx5g -Xms5g -server -XX:+UseTLAB -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=0 -XX:CMSInitiatingOccupancyFraction=60 -XX:+CMSParallelRemarkEnabled -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled That gets cumbersome really quick. Honestly my preferred jvm deployment is supervisord. I'd like a java only soluti…

Capsule works for any JVM application. It doesn't even have to be Java. It can use Java libraries, native libraries, a well-known server, your own server, with http, with a custom Infiniband thingy -- what have you.

Re: An Opinionated Guide to Modern Java, Part 2

#112

Post by Pacabel »

pron wrote: post #49
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).

Native executables are not always what you want. For example, they don't get security patches.

That's total nonsense. Binaries (or shared libraries they depend on) can be and are updated, on all sorts of systems. In many cases it's as simple as overwriting the existing binary with the updated version.

Heck, the runtimes you're advocating are generally installed as binaries. If they can get updated, then so can any other binary.

And if a user doesn't bother to update a given application's binary when a critical flaw of some sort is found, then there's a very good chance they wouldn't bother to update any runtimes that are installed, either. This is true even when some sort of update notification and installation process is offered. The end result is the same in either case: the update is not applied.

Runtimes shouldn't be portrayed as any better in this case, when they're generally no different than any other binary.

Re: An Opinionated Guide to Modern Java, Part 2

#113

Post by pron »

Pacabel wrote: post #112
pron wrote: post #49

Earlier quoted context omitted.

Native executables are not always what you want. For example, they don't get security patches.

That's total nonsense. Binaries (or shared libraries they depend on) can be and are updated, on all sorts of systems. In many cases it's as simple as overwriting the existing binary with the updated version. Heck, the runtimes you're advocating are generally installed as binaries. If they can get updated, then so can any other binary. And if a user doesn't bother to update a given application's binary when a critical…

Anything can be done in many different ways. It all comes down to convenience. When a library is found to have a security flaw, you can either upgrade all binaries, or just upgrade one runtime. You could say that your OS is just a binary, too, and that's true. But it's a binary that adds a lot of convenience. A lot of people think runtimes add convenience, too. You obviously don't agree, and that's fine: use whatever works best for you.

http://xkcd.com/378/

Re: An Opinionated Guide to Modern Java, Part 2

#114

Post by pron »

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

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

The advantage Capsule gives you is statelessness. The user does not need to put her system in a certain state. You get one file and you run it. It should work regardless of anything else that's installed -- or not -- on your machine, with the exception of an OS and a JRE.

There are other ways to achieve stateless deployment, and Capsule is not always the right fit. For example, it's not the right fit if your app requires an Oracle DB installed locally (it could be done, because Capsule supports an installation script embedded in the JAR, but that probably wouldn't be a good idea in this case). But when it is the right fit (e.g. microservices, grid workers etc.), it's much more lightweight than any other solution.

Re: An Opinionated Guide to Modern Java, Part 2

#115

Post by FeloniousHam »

pivo wrote: post #31
saryant wrote: post #9

Earlier quoted context omitted.

A common example is with logging config files (e.g., logback.xml). Some libraries ship with their own (or a library's dependency). It's not uncommon in a large project to wind up with several logback.xml files littered around from libraries that included their own. These are called "resources" because they aren't code but they are included with the compiled distributable and are placed on the classpath. Of course, yo…

Speaking of Java logging, that's one area that drives me batty. The lack of a good standard Java logging library caused a multitude of logging libraries to be written. Different libraries then of course use different logging libraries, so each logging library generally has a way to wrap all the others, and they all work in different ways. Getting consistent and controllable logging (e.g. ability to turn on or off log…

Agree, and will add that part of my frustration comes from the fact that nobody really cares about logging. You just want it to work.

OT, but I think this is my biggest complaint with Javascript. There's an explosion of invention and creativity with the language (because of its privileged position as the foundation of browser programming), but little standardization for the things I don't really care about.

Re: An Opinionated Guide to Modern Java, Part 2

#116

Post by Xorlev »

Crito wrote: post #52
astine wrote: post #42

Earlier quoted context omitted.

In 2014, how many of us are doing backend/service development in java and not deploying to Linux machines? Among silicon valley webstartups? Not many. But there still are a lot of Windows based installs large megacorps and small offices all over. For a lot of them, switching away is not an option so you might want to support them.

Among silicon valley webstartups, I would be surprised to hear much about java service/backend work at all. My experience is primarily with the megacorps. If you are developing backend/service shit for other companies to use, then that is one thing, but I am thinking about in-house development. Most megacorps aren't software vendors; if they are developing software it is for themselves. Regardless though, some megaco…

You would be? Because its daily I hear about services written on the JVM.

Re: An Opinionated Guide to Modern Java, Part 2

#117

Post by eweise »

bruceboughton wrote: post #100
eweise wrote: post #98

Earlier quoted context omitted.

That's the way we do it in production and it works great. Why create fat jar files and copy them to dozens of servers when you can just have each server pull down its dependencies from your repository.

So now the availability of your production service relies on the availability of your (development) repository. Another (pointless) point of failure. And you can't see why this is a bad idea?

It should be obvious that if the repository were unavailable, we would not try to push a new version of our code. This is a much better approach since library dependencies are only usually downloaded once when we start a service for the first time, vs a fat jar that pushes dependencies every single time, leading to long startup times. This is a big deal when you've got a hundred servers and dozens of services on each.

Re: An Opinionated Guide to Modern Java, Part 2

#118

Post by eeperson »

lmm wrote: post #99
eeperson wrote: post #86

Earlier quoted context omitted.

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

> Embedding Jetty just means that now you have to restart every time. You could just do the same thing with standalone Tomcat instance. So now either I need to figure out how to hook my deployment script into the host system's init scripts, or I need to package tomcat as part of my app (and worry about its shared library linkage). With embedded, my app is just a program, not at all integrated with the host system; it…

Why does standalone Tomcat need any more integration with the system than an app with embedded Tomcat? They are both Java applications.

Tool support is not server specific. In both cases you set the appropriate VM arguments. What XML file would you have to edit?

Yes, hot code replacement is faster (although it comes with other tradeoffs). Why can't you do that with standalone Tomcat? What is unreliable about reloading? You can leak PermGen space if you don't finalize your threads properly, but why wouldn't you be running the latest code?

You're right about the web.xml file. I had forgotten about that. I can see why you might prefer to write that in Java code rather than XML.

Re: An Opinionated Guide to Modern Java, Part 2

#119

Post by agibsonccc »

pron wrote: post #111
agibsonccc wrote: post #94

Earlier quoted context omitted.

It can be. Here's a typical example from my day to day: java -cp "lib/*" -Xmx5g -Xms5g -server -XX:+UseTLAB -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=0 -XX:CMSInitiatingOccupancyFraction=60 -XX:+CMSParallelRemarkEnabled -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled That gets cumbersome really quick. Honestly my preferred jvm deployment is supervisord. I'd like a java only soluti…

Capsule works for any JVM application. It doesn't even have to be Java. It can use Java libraries, native libraries, a well-known server, your own server, with http, with a custom Infiniband thingy -- what have you.

I'll look in to it when there's a maven plugin maybe. As of right now my work flow works fine with the assembly plugin.

It looks pretty solid though. I'm still not totally sold on gradle as of yet mainly because of the tooling.

The native libs thing is a plus though. I'll see where I can work it in. Good work with capsule though.

Re: An Opinionated Guide to Modern Java, Part 2

#120

Post by lmm »

eeperson wrote: post #118
lmm wrote: post #99

Earlier quoted context omitted.

> Embedding Jetty just means that now you have to restart every time. You could just do the same thing with standalone Tomcat instance. So now either I need to figure out how to hook my deployment script into the host system's init scripts, or I need to package tomcat as part of my app (and worry about its shared library linkage). With embedded, my app is just a program, not at all integrated with the host system; it…

Why does standalone Tomcat need any more integration with the system than an app with embedded Tomcat? They are both Java applications. Tool support is not server specific. In both cases you set the appropriate VM arguments. What XML file would you have to edit? Yes, hot code replacement is faster (although it comes with other tradeoffs). Why can't you do that with standalone Tomcat? What is unreliable about reloadin…

> Why does standalone Tomcat need any more integration with the system than an app with embedded Tomcat? They are both Java applications.

With an embedded Jetty my app can just be a jar or set of jars. Tomcat has a directory structure and ships as a binary rather than a jar so I'd need to unpack it and worry about it being linked correctly for the target system.

> Tool support is not server specific. In both cases you set the appropriate VM arguments. What XML file would you have to edit?

I forget the name - catalina.xml or something? You can't just run ./tomcat -agent:myagent.jar. because it won't pass the arguments through to the JVM, unless that's changed.

Post reply on HN