Hacker News Reader

Comment by jomamaxx | Hacker News Reader

Java EE is basically the official java server-side container. It was designed to scale, it kind of forced a designed pattern (something called 'Enterprise Beans' - one bean for dealing with requests, stateful beans for dealing with sessions etc.)

It got huge and bloated.

Some people came along and created some lighter frameworks.

Arguably - Node.js - the javascript container is the real extension of this: it's incredibly light, can handle zillions of connections, you install the packages you need, it's totally open source. And it's in javascript which is uniquely well positioned to do a lot of 'asynchronous' stuff. Passing functions around with callbacks is possibly in Java but it's just bulky. Mostly due to the nature of typing. It's even kind of bulky in Apple Swift, for example.

Java is a great language, that has made some improvements with lambdas etc.

View on HN

"Java EE is basically the official java server-side container. ... Some people came along and created some lighter frameworks."

"Container" is the key word here.

J2EE had the notion of an app server hosting your app.

The extreme alternative is to have your app be standalone and "embed" an I/O protocol (HTTP) server. I've had great success with this strategy.

Why want several HTTP stacks on the same machine? Isn't that like wanting multiple TCP stacks or DNS resolvers?

It's no help to have lambdas when you're trying to use an old framework designed before Java had lambdas.

Javascript is not unique in having anonymous functions, it merely had a critical mass of web devs whose design preferences were already skewed by missing multicore support in client apps.

Does Java have an equivalent to the Promise system in Javascript? I find it much more usable than callbacks for async-heavy applications.

In either SE or EE, no. Most people use Google's Guava library, which contains Futures that have that functionality.

https://stackoverflow.com/questions/14541975/difference-betw...

Java has Futures, which are close, and allow similar patterns of code. But they're not woven into the language as pervasively as Promises are into JavaScript. You need to deal with asynchronous-ness explicitly.

There's also, in true Java tradition, a number of competing implementations of Promise based frameworks. The one I've used, Ratpack, defines and uses promises almost identically to JavaScript/Node.js.

No Promises in Java.

Sadly - the language is really not quite as 'async' as we would like it to be.

Java scales much better than Javascript though, and I mean that in the architectural sense.

Past 50K lines of code - the lack of typing in JS can start to be hell, unless you really know what you are dong.

Of course, you move much more quickly early on in JS and that's actually important: you need to be able to 'iterate and adapt' in todays world. So it's kind of a paradox.

If you're building a bank, you do it deliberately with Java or something like that.

If you're building a nimble startup, you can start with Node and if there are systems that reach a certain degree of maturity and the uses/cases and data model start to settle you can fold over systems to Java or something like that.

A great team can use anything in the end though - that said, it's really hard to find super talented and responsible people across the board.

Java has an implementation of Futures, but it's not very good. In the JVM, however, we have Scala Futures, which IMO are far better than Javascript promises. And on top, you have a lot more flexibility deciding how to run those futures, as far as threading goes, because they run on top of Java's very sturdy ExecutorService. There are a variety of executor services for pretty much anything you want.

JVM concurrency is best in class. It's just the Java language itself that moves at a snail's pace.

Look into Scala and Futures, very similar.

Reply on news.ycombinator.com