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

61–70 of 138 posts

Re: An Opinionated Guide to Modern Java, Part 2

#61

Post by pron »

eeperson wrote: post #56
pron wrote: post #38

Earlier quoted context omitted.

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…

Looks like I should have read the Capsule Github page. I didn't realize Capsule was caching the project dependencies. I could certainly see that making projects much faster to deploy. Aren't the app servers and the embedded servers the same servers just configured differently? Standalone it is configured with XML and and embedded it is configured with Java code. It doesn't seem to me like there is much of a set up di…

Multi-app servers usually take much longer to launch, deploying apps and upgrading the servers is a pain, and there's a host of other issues (like not being able to easily allocate resources to apps according to their needs).

> As far as I can tell, it comes down who cares more about the settings for the server

There's a lot of truth to that. I think that the whole devops approach is that they should be the same people. Of course, you might have valid reasons for not subscribing to that approach.

Re: An Opinionated Guide to Modern Java, Part 2

#62

Post by derengel »

pron wrote: post #57
derengel wrote: post #55

Earlier quoted context omitted.

unzipping a folder and running a <10 line bash script requires installation? is that what you mean by installation?

Well, if it works for you then great. But doing that with every version (Capsule gives you automatic upgrades) might become annoying, and even dangerous, and if you can do the same thing with a single file that doesn't even require installation, why not make life even easier.

Ok, not disagreeing, just wondering what you meant by installation, Capsule sure looks cool.

Re: An Opinionated Guide to Modern Java, Part 2

#63

Post by pron »

twic wrote: post #58
pron wrote: post #38

Earlier quoted context omitted.

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 You wouldn't do this for a production deployment, right? Application starup that may or may not require access to the artifact repository to complete successfully. When that idea bounces around my developer neocortex, my sysadmin hindbrain starts reaching forward to strangle it. And if you're not going to do it in production, doing it in devel…

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

Re: An Opinionated Guide to Modern Java, Part 2

#64

Post by twic »

12345678123 wrote: post #51

This article does not mention OSGI or Jigsaw with one word but claims to guide to modern Java development. Seems they never run any large scale EE projects yet :)

Ah, OSGI. OSGI is a bit of an enigma. People who use it think it's great, and, by the sound of it, assume everyone else is using it. People who don't use it think it's some weird thing from the turn of the century that nobody actually uses.

I do think a well-rounded Java developer should know about OSGI (i have to confess that i don't). But it would be mistaken to think that it's mainstream.

Re: An Opinionated Guide to Modern Java, Part 2

#65

Post by pron »

depsypher wrote: post #53
einrealist wrote: post #50

Earlier quoted context omitted.

Actually, you can have Jars in Jars. Of course, you need to do the lifting yourself. It is actually very nice to have a simple unpack / installation application inside a Jar and to unpack the actual application from this Jar. In this way, the only requirement for unpack / installation is the JVM, which you already require to run the application itself. This is much more elegant than a platform dependent unpack / inst…

spring boot has done the lifting: http://docs.spring.io/spring-boot/docs/current-SNAPSHOT/refe...

That is actually very similar to Capsule, except that it doesn't support Maven, automatic upgrades, and as far as I can tell - JVM configuration (heap size, agents etc). I think Capsule is a strict superset in terms of features.

Re: An Opinionated Guide to Modern Java, Part 2

#66

Post by twic »

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…

It's a sad story. The proliferation of logging libraries was the problem that Commons Logging aimed to solve by providing a facade over all of them. But because it screws up classloading (i forget the details, but it's serious), eventually a critical mass of people needed to move off it. java.util.logging tried to fix the problems and canonise a standard interface by putting in the JDK, but it got so many things wrong that it wasn't widely adopted. SLF4J finally came along as a very well-implemented facade that has gained wide adoption. It would say it is a de facto standard.

Only then JBoss decided that all their stuff (including Hibernate) needed a facade of its own, which manages to not quite properly interact with SLF4J!

It's almost enough to drive me to printlns.

Re: An Opinionated Guide to Modern Java, Part 2

#67

Post by jebblue »

stuff4ben wrote: post #59
jebblue wrote: post #41

Earlier quoted context omitted.

I'm not clear, just did a ton of Googling and I think maybe spring.io is related to the Spring Framework at VMware. That would mean it's dependency injection.

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.

Re: An Opinionated Guide to Modern Java, Part 2

#68

Post by twic »

jpollock wrote: post #11
derengel wrote: post #5

As someone not very familiar with Java can someone expand on what he means by this: "Every library is usually packaged into its own JAR, and merging all dependencies into a single JAR, might cause collisions, especially with packaged resources (non-class files)."

Class loaders work in a tree, and there typically isn't sharing between sibling branches. I believe that visibility is up the tree, and never across. So, you can end up with two different versions of a library existing quite happily in the same process space. Collapsing them down into a single [ejsw?]ar file results in the tree being collapsed down too. All of a sudden all of the log4j.xml files that everyone has spr…

FWIW, classloaders don't have to work as a tree. The JDK itself has a simple model with three classloaders in a hierarchy (bootstrap, extension, and system), which is a degenerate tree, and application servers have traditionally had a more general tree, but other topologies are possible. But OSGi and JBoss Modules have directed graphs of classloaders.

Re: An Opinionated Guide to Modern Java, Part 2

#69

Post by twic »

pron wrote: post #63
twic wrote: post #58

Earlier quoted context omitted.

It can point to Maven dependencies that are downloaded on the first launch You wouldn't do this for a production deployment, right? Application starup that may or may not require access to the artifact repository to complete successfully. When that idea bounces around my developer neocortex, my sysadmin hindbrain starts reaching forward to strangle it. And if you're not going to do it in production, doing it in devel…

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.

Re: An Opinionated Guide to Modern Java, Part 2

#70

Post by eeperson »

pron wrote: post #61
eeperson wrote: post #56

Earlier quoted context omitted.

Looks like I should have read the Capsule Github page. I didn't realize Capsule was caching the project dependencies. I could certainly see that making projects much faster to deploy. Aren't the app servers and the embedded servers the same servers just configured differently? Standalone it is configured with XML and and embedded it is configured with Java code. It doesn't seem to me like there is much of a set up di…

Multi-app servers usually take much longer to launch, deploying apps and upgrading the servers is a pain, and there's a host of other issues (like not being able to easily allocate resources to apps according to their needs). > As far as I can tell, it comes down who cares more about the settings for the server There's a lot of truth to that. I think that the whole devops approach is that they should be the same peop…

The difficulties you mention (aside from upgrading servers) is about the having multiple apps in a single server not standalone vs embedded. Although, if you are careful, it can actually be faster and easier to deploy to a multi-app server [0].

I grant you, upgrading servers can be more involved depending on how you do it.

[0] - http://tomcat.apache.org/tomcat-7.0-doc/deployer-howto.html#...

Post reply on HN