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

131–138 of 138 posts

Re: An Opinionated Guide to Modern Java, Part 2

#131

Post by digaozao »

curun1r wrote: post #19
jacobheric wrote: post #13

Earlier quoted context omitted.

I'd not go so far as to say it's trolling. Perhaps overly-dramatic hyperbole. As a Java developer, I do see a shift away from packaging up wars and deploying them to application servers. See Dropwizard or Spring Boot for examples of frameworks that prefer to run fat jars that serve http requests via embedded containers.

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…

I agree with using tools from other languages for the job. In our company, we chose python fabric. Wrote some deploy scripts with it.

It basically downloads the new version, updates the database running liquibase, updates some configuration files that are on git and finally updates the application war on tomcat.

Not so bad for a single file script.

Re: An Opinionated Guide to Modern Java, Part 2

#132

Post by digaozao »

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.

slf4j was useful for me in a switch from log4j to logback.

Other useful tool for logging, that integrate with logback or log4j is sentry: https://github.com/getsentry/sentry

And to use it with java: https://github.com/kencochrane/raven-java

Re: An Opinionated Guide to Modern Java, Part 2

#133

Post by pswenson »

twic wrote: post #64
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.

I've found OSGi to be an absolute nightmare. Classloader hacks is not the way to solve Java's dependency problem, it needs to be baked in the language IMO.

I think it's one of those ideas that sounds great in theory, but in reality it all falls apart.

Even if it worked as advertised, fact is many 3rd party libraries have all sorts of issues with OSGi. For example, my company is stuck on Jersey 1.x because 2.x doesn't work properly with OSGi.

Testing is much slower and harder to write. Testing seems to be an afterthought....

I think you can get most of the benefits of OSGi simply by using proper dependency management (Gradle). Use the Single Responsibility Principle and IoC and you'll get good modular code. These are much easer to do, have low risk, and are easy to test.

JMO

Re: An Opinionated Guide to Modern Java, Part 2

#134

Post by dafnap »

Patient0 wrote: post #109
philbarr wrote: post #12

Earlier quoted context omitted.

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.

Where did you find part 3?

Part 3 will be released toward the end of the week.

Re: An Opinionated Guide to Modern Java, Part 2

#135

Post by thejdude »

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…

At least with Maven you have a standardized build process in every project. Checkout the code and be productive right away. It structures dependencies and project layout.

Currently I'm in a large enterprise project where the build department decided it was a good idea to reimplement a whole complex build in gradle (basically all that maven does by default). It didn't help that they didn't realize Gradle uses Maven conventions by default, ignored that and ran their own dependency system. The build is REALLY slow and really complex and nobody has any idea exactly what it does.

In ant having a non-standard project layout was ok, but then at least the build was FAST and didn't take half a minute just to START the build system.

I'm not yet sure if gradle actually IS better if you use it right, or if it's just a very very slow solution to a problem you shouldn't have it the first place if you do it right with something like maven.

Re: An Opinionated Guide to Modern Java, Part 2

#136

Post by thejdude »

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.

It's great because you can use whatever backend you're comfortable with in your setup. Are you a JUL guy? Great, configure JUL then.

I took a totally baroque project setup (they just don't know WTH they're doing) with some JUL and some log4j, piped everything into SLF via the bridges, then configured a log4j backend (which I'm confortable with) and now I'm the only person in the project that actually has control over their logging and configures it to log into nicely separated files for application output, SQL statements and so on :-)

In an ideal world we'd all just use one log system, but Sun screwed that when they created the very unnecessary JUL back in the day. SLF solves the logging mess nicely.

Re: An Opinionated Guide to Modern Java, Part 2

#137

Post by thejdude »

kbcv wrote: post #122

How does profiling Java applications work with JIT. Should you wait until the code has been optimized before profiling, or these tools smart enough to realize that the performance of code changes as the application runs?

I think as soon as any method takes up a noticeable part of execution time, it has been optimized all the way by the Hotspot or whatever your JVM uses.

After all, you want to profile your app's hot spots ;-)

Re: An Opinionated Guide to Modern Java, Part 2

#138

Post by diroussel »

curun1r wrote: post #129
pron wrote: post #104

Earlier quoted context omitted.

The next release will include the option to resolve (potentially download) all dependencies without launching the app, if someone finds that useful. If dependencies are resolved, or are embedded, startup time is increased by 100ms or so.

It still feels like a pre-automation mindset...this is a step that should happen during CI, not application startup or even deployment. The delay is going to be a lot more than 100ms if you use something like this when scaling elastically. In that situation, you need to go from automatically provisioned to running and accepting load in as short a timeframe as possible. Fully-baked machine images or Docker containers…

Copying a file takes the same time, regardless of it's capsule of chef that is copying the file. Once capsule has cached the file, you can cut a VM image, and no copying will occur later.

> making your Maven repository a dependency of your production environment It becomes a dependency of your deployment process, which probably already depends on a maven repo. And a maven repo can be just a NAS drive, which is often reliable enough for use in production.

Post reply on HN