91–100 of 138 posts
Does anyone actually swap out their log backend? To me slf4j felt like an overcomplicated, enterprisey step with no clear advantage over log4j.
If there is one logging engine to depend on that libs can use, this means less dependency hell.
Fighting it is a losing battle with how much traction it has among all the different libs.
Does anyone actually swap out their log backend? To me slf4j felt like an overcomplicated, enterprisey step with no clear advantage over log4j.
Earlier quoted context omitted.
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…
Because Java-only solution to a complicated problem is normally simpler. Few reasons contribute to that. One of them is exhaustive pure Java library ecosystem, which means that it's very unlikely that you'll run into intricacies of native library access on your host system. Another is excellent tooling, which means that when all your processes are Java processes, lots of operations-related tasks (process management &…
Plus, there's the benefit of (essentially) standard builds, project layout, dependency management, and deployment strategies (jar or war). A java developer can walk into a new job and be productive right away.
Earlier quoted context omitted.
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.
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 solution if one should exist that's good but these newer containers don't work for self made servers that don't run http.
Some of the instrumentation could be good, but at the end of the day I'm not sure how much it would help.
Earlier 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…
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 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 different companies, within any particular company it tends to always deploy on only type of system. Most "mega-corps" are not software vendors; when they develop software they are developing it for themselves. This means that they control the entire stack, making portability fairly pointless.
When development in these organizations is done in other languages without such a "portability culture", not a second of thought is given to portability. The second a service is written in Java though, everyone starts jumping through hoops for something that they will never use.
Does anyone actually swap out their log backend? To me slf4j felt like an overcomplicated, enterprisey step with no clear advantage over log4j.
Also consider the case of third-party libraries. I have dependencies in my application that are hard coded to log to about three different logging implementations. If they instead used SLF4J, the end user could choose whichever implementation they were already using in their app, instead of having multiple implementations or needing to redirect the output via an SLF4J bridging module.
Earlier quoted context omitted.
You can do this from the JVM command line with "-XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly". (it's kind of a mess, though)
Yes, it still requires the plugins which aren't delivered with the JDKs and each JVM does it a bit differently, but is possible. As complement of it, check JIT Watch https://skillsmatter.com/skillscasts/5243-chris-newland-hots...
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…
Earlier quoted context omitted.
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 t…
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 runs like a program and stops like a program.
> Why is it difficult to do any of those development things without having the server embedded in your application?
Because the tool needs support for the server and often it has to be done in a server-specific way. How does one use JProfiler on an app deployed in Tomcat? One edits one of the internal Tomcat xml files. How does one use JProfiler on an app that embeds Jetty? One runs it with the same command line arguments one uses for running any other app with JProfiler. And it's like that for every tool - the way to do it with Tomcat is slightly different, the way to do it with an embedded server is standard.
> Pretty much every Java build tool (Maven, SBT, Gradle, Lein) makes those things easy to do without specifying an XML file for your server.
If you're building a war you need a web.xml (or I'm seeing some speculation it can be done with annotations? Either way, much less clear than just making a servlet in code).
> Also, they will frequently let you reload your application, which is faster.
Not in a way that matters. If you're just doing day-to-day dev then IDE hot code replace is faster still. If you want to be sure you've cleaned out all traces of the old version and are definitely running your latest code then reload isn't reliable enough.
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…
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.
And you can't see why this is a bad idea?