Hacker News Reader

Comment by dlandis | Hacker News Reader

> So Java is not only the safe choice for serious server-side software; it's also the bleeding edge.

Sure for core Java (OpenJDK), but what the future of JEE licensing and development? Even non-"enterprise" apps typically make use of some JEE stuff like servlets and JDBC. Is it really the "safe" choice when, apparently, the trademark agreements have just fallen apart?

https://headcrashing.wordpress.com/2019/05/03/negotiations-f...

View on HN

JDBC is not JEE - it is core Java. Servlets are the original web-container Java spec, independent of JEE. Both are great specs supported by several stable and performant implementations - rock solid tech compared to a lot of the flaky stuff you find advertised today.

How are Java programmers implementing RESTFUL APIs these days?

Spring Boot with Webflux and any rx supporting libraries you can get your hands on

Thanks.

Many developers don't want to think too much and generally choose Spring boot for a stable, highly-popular and well-documented framework. There is nothing wrong with this choice but I find it too bloated for lean container based micro-services.

Dropwizard and Micronaut are pretty good for getting a smaller and saner footprint. If you need more than REST, say you want a lean MVC-based web-framework, then Blade is also a good choice.

You can also choose not to use a framework and say use code-generation from a swagger/openAPI REST document and implement the remaining bits on your own. If your deployment target is AWS, you can also choose to leverage Netflix's fantastic set of libraries.

Java has tonnes of options, so you usually need to spend some time evaluating what goes into your stack.

I'm curious to hear what specifically is too bloated in Spring Boot in your opinion for container based microservices. I've been writing microservices that run in docker in Java for a few years, then moved to Kotlin recently, all using Spring Boot, and I haven't run into anything that made me feel like they were bloated. I've also written Go and Node microservices for contrast.

Spring boot has a large startup time, heavy dependency trail and a lot of dynamic class-loading based off auto-configuration. This makes it un-suitable for some areas: if you desire fast scaling micro-services that respond quickly to incoming load. Or say you want to transform your micro-service to a server-less function. One can do that with Graal VM to compile your micro-service to a single binary with microscopic start-up time. However, native-image tends to fail more often than not with Spring boot apps. (I haven't tried this recently though so my knowledge could be out of date).

Spring Boot does what it's asked to do, which is to load everything it finds. The dynamic class work has basically nil effect on load time. The core performance constraint is that classes are loaded essentially linearly. If you ship with something enormous like Hibernate, that's thousands of files read individually from a zipfile.

Spring folks are actively involved with Graal. I see a lot of excitement internally at Pivotal. Watch this space.

I'm reminded of the crazy stunts from the 1980s where people would start some big, slow program (Emacs was huge!), dump core, and then "undump" to make a pre-initialized binary that would start as fast as the OS could read it. It actually worked, as long as it wasn't relying on open file descriptors, or signal handlers, or env vars, or …

I’m pretty sure Emacs still does this. There was a patch committed to change it to use a more portable method of dumping state, but I don’t think that change made it into the 26.2 release.

You should checkout new RedHat framework - [Quarkus](https://quarkus.io/). This is a framework which leverages Graal to create native images. Those images are very small and optimized. For example one of Quarkus developers showcase the size of native image, spoilers - it's [19MB](https://youtu.be/BcPLbhC9KAA?t=103). It takes 0,004s to start.

In [this](https://youtu.be/7G_r1iyrn2c?t=3104) session, RedHat developer shows how Quarkus application is being scaled. Comparing to Node, it's both faster to respond to first request and have smaller memory footprint (half the size of node).

Looks very interesting although unfortunate they went with Maven over Gradle.

they do support gradle https://quarkus.io/guides/gradle-tooling

Spring boot + jOOQ for RDMS support.

I can't speak for others, but I work in games and we've spun up a bunch of servers and we use Netty/Jersey for REST and sockets. It's been incredibly stable and a joy to program for compared to our previous Node servers. Granted we were using bleeding-edge Node 5 years ago which is not the Node of today.

https://www.dropwizard.io/

Quoting from the site: Dropwizard is a Java framework for developing ops-friendly, high-performance, RESTful web services.

It's a nice microframework which comes with built in health-checks, and metrics and it's also ops friendly because it deploys as a single JAR file.

Not really related to Dropwizard but... this:

> mvn archetype:generate -DarchetypeGroupId=io.dropwizard.archetypes -DarchetypeArtifactId=java-simple -DarchetypeVersion=[REPLACE WITH A VALID DROPWIZARD VERSION]

Why is it that everytime I read something about Java I have a feeling it was not meant for humans ? Not as bad as C++ projects setup though, I'll give it that.

I don't use maven archetypes too often, the rest of maven seems pretty good to me, but maybe I'm just used to it.

I have done a lot more Java than Javascript, so I feel the same about npm error messages.

Don't get me started on js/npm stuff...

I use javalin.io which was written by one if the maintainers of sparkjava (not to be confused with Apache Spark).

I'm a big fan.

Pardon my ignorance but what does any of that trademark stuff have to do with jdbc?

I know little about EE (and I'm certainly not speaking for anyone but myself), but I believe Java EE has lost dominance not because of any corporate decision, but because it simply started losing ground to unstandardized open source projects [1], as opposed to EE's JCP. So people who liked EE wanted to ditch the slow-moving JCP in favor of a faster process, and one question was whether the new project will be able to change specifications of namespaces that are traditionally reserved to, and associated with, the JCP. In the end it was decided that no, they will not be able to change JCP namespaces (but can choose to maintain them until the end of time in addition to any innovation they do outside of JCP namespaces). The decision obviously disappointed some, but I don't think it's viewed as catastrophic (although some may think so). And I don’t think that the “negotiations have failed” so much as that either side wasn’t able to achieve what they believed was the best outcome for them, but an agreement has been made. You also need to realize that it wasn't a negotiation between Oracle and some grassroot project, but among multi-billion-dollar corporations, some of whom have fought Java standards for over a decade, so the process was both legally and politically complex. But now everyone can move on.

I, for one, am curious to see how Jakarta EE's current approach of what seems to be an internet-based, democratic semi-standard would work out, and if it can be better than both the JCP as well as more common centrally-controlled open-source projects.

Anyway, this is what Eclipse's director said on the matter:

https://twitter.com/mmilinkov/status/1125213654775889921

[1]: That post you linked to reminds me of those who blame Oracle for killing Solaris. Solaris is a terrific operating system, that was sadly killed by Linux long before Oracle acquired Sun. After a few years of trying, I guess Oracle decided they could no longer save it, and there was no point in continuing to throw good money after bad.

> You also need to realize that it wasn't a negotiation between Oracle and some grassroot project, but among multi-billion-dollar corporations, some of whom have fought Java standards for over a decade, so the process was both legally and politically complex.

Yes exactly, I think that is what makes if feel like not the safest choice for many companies.

Java EE has not been the preferred choice for many companies long before this issue, which, I guess, is at least part of the reason why Oracle gave up those projects. I think Spring is the leader, but I am really not too familiar with that entire domain.

That's right that _pure_ JEE has not been preferred, but part of my original point is that simple things like servlets are actually technically part of JEE - so if you are using Spring for web, cloud, etc then you are actually using JEE at least a little bit.

Your revisionism in your footnote is astounding, frankly. Oracle closing the source for OpenSolaris was not because of Linux - it was because of a choice made inside Oracle. Remember that development then continued for years in a closed source fashion, and is still ongoing with a skeletal staff.

Reply on news.ycombinator.com