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 :)
An Opinionated Guide to Modern Java, Part 2
51–60 of 138 posts
Re: An Opinionated Guide to Modern Java, Part 2
#52Earlier quoted context omitted.
> 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…
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 megacorps deploying to windows doesn't explain the practices of java shops that don't deploy to windows. It seems like portability just for the sake of portability, without any real purpose but with real added hassle.
Re: An Opinionated Guide to Modern Java, Part 2
#53As 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…
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...
Re: An Opinionated Guide to Modern Java, Part 2
#54Nice 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.
We'll discuss Dropwizard in part 3, but the single-jar deployment is not really solved by Dropwizard. To launch the server you still need to configure the JVM at the command line.
is that really a big issue? passing the arguments to java to configure the jvm.
Re: An Opinionated Guide to Modern Java, Part 2
#55As 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…
unzipping a folder and running a <10 line bash script requires installation? is that what you mean by installation?
Re: An Opinionated Guide to Modern Java, Part 2
#56As 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…
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 difference.
As far as I can tell, it comes down who cares more about the settings for the server, the people who maintain the machines or the people who maintain the code. If those people are the same then it sounds like it really doesn't matter.
Re: An Opinionated Guide to Modern Java, Part 2
#57Earlier 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…
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.
Re: An Opinionated Guide to Modern Java, Part 2
#58As 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
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 development means having a gratuitous difference between development and production, which, again, is something i have learned to fear.
A zip with startup scripts is OK, but it requires installation.
'gradle installApp' works out of the box, and 'installs' the jars and scripts in your build directory, which is all you need to run locally. It's work of minutes to write an fpm [1] invocation that packages the output of installApp as an operating system package, which you can then send down the pipe towards production. This is simple, easy, standard, and fully integrated with a world of existing package management tools. Why would i use Capsule instead of doing this?
Re: An Opinionated Guide to Modern Java, Part 2
#59Earlier quoted context omitted.
Sharing a lot of the Dropwizard philosophy, there is Spring Boot ( http://projects.spring.io/spring-boot/ ), which we use and love as well.
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.
Re: An Opinionated Guide to Modern Java, Part 2
#60"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.
I used Spring Boot the other day. It was really easy! Up until things just didn't work for no apparent reason, and neither the error messages nor documentation gave me any clues as to how to fix it.
App servers have historically been hard to deploy, maintain and dev against. There has been a huge amount of progress in the last few years. Based on my experience, Java EE / Wildfly is actually easier to develop with than Spring Boot.