Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don’t call it a comeback: Java is still champ

github.com

Post reply on HN
Print view View original

311–320 of 557 posts

Re: Don’t call it a comeback: Java is still champ

#311

Post by vbezhenar »

plandis wrote: post #118
xxpor wrote: post #73

Earlier quoted context omitted.

An uncommon but not unheard method around that (in services that have diurnal patterns) is to throw memory at it and collect once a day during the down time. You can take the server out of service, restart it, and put it back in service.

This is kind of hard to do in practice unless you’re really watching where you’re allocating memory. It’s very easy in Java to end up accidentally throwing a bunch of allocated memory on the heap without realizing it. Fwiw, the JVM now has a noop garbage collector so this is easy enough to benchmark.

Can you provide an examples of accidentally allocating memory? The only example I'm aware of is autoboxing which is huge misfeature IMO.

Re: Don’t call it a comeback: Java is still champ

#312

Post by type0 »

ralmidani wrote: post #260

Java was actually not bad for me in class when learning software design and data structures, but soul-crushing to work with in the real world. Mindless, unnecessary use of getters/setters, interfaces, and AbstractFactoryImpls. Hiding almost every piece of functionality behind 10+ layers of indirection. Dependency Injection with Spring. They all make it feel like Java draws folks who actually __enjoy__ writing bloated…

Java is the perfect example of software "bureaucracy" for the sake of bureaucracy

Re: Don’t call it a comeback: Java is still champ

#313

Post by mrtranscendence »

gavinray wrote: post #240
dkarl wrote: post #225

Earlier quoted context omitted.

Agree with all of that except readability. Java has some language deficiencies (no first-class functions, "streams" missing for almost twenty years and added too late to be done elegantly) and some cultural norms (mutable everything, overuse of inheritance) that make it a chore to read most of the Java code you encounter in the wild, including the source code of the libraries you depend on. Figuring out the behavior…

Modern Java has first-class functions, pattern matching with structural binding, records/pure immutable data classes, the whole 9 yards: static void main() { BiFunction add = (Integer x, Integer y) -> x + y + 5; Integer result = addTo(10, add); Integer result2 = addTo(10, (x, y) -> x + y + 5); } static Integer addTo(Integer acc, BiFunction addFn) { return addFn.apply(acc, 5); } Integer eval(Expression e) { return swi…

I haven't programmed in Java since 2005, so forgive me. But isn't a lambda automatically converted to an object of the necessary single-method type? That feels a little magical and suggests that there really isn't such a thing as a genuine first-class function in Java, as there is no way to define a function, and no universal type to assign to such a thing.

Re: Don’t call it a comeback: Java is still champ

#314

Post by pdimitar »

TheRealDunkirk wrote: post #219
bullen wrote: post #213

Earlier quoted context omitted.

No Erlang can't share memory between cores atomically. Erlang can only scale 1-to-1 things like phone calls. Java is the ONLY language that scales many-to-many with stable non-blocking IO and concurrent parallelism that shares memory atomically AND doesn't crash.

And for the fraction of the software projects out there that that actually need this feature as a hard requirement, I'm sure it's wonderful.

Yeah, all web apps everywhere are definitely a fraction, I'm sure. :P

Green threads are an amazing fit for web apps. I made a career out of using those for web apps and API apps.

Re: Don’t call it a comeback: Java is still champ

#315

Post by LaGrange »

mcculley wrote: post #277
pkolaczk wrote: post #273

Earlier quoted context omitted.

In Java if you encountered a null pointer exception or out of bounds error at the global level, there is also no guarantee you can safely continue, and dumping the stack and terminating is the only sensible option. Sure, the JVM is ok, but your app state might be already corrupt.

This has not been my experience at all. The JVM is not corrupted by a NPE or out of bounds access unless you are using native code. For example, I worked on a large X-Windows/Motif application with many developers. If some library dereferences a null pointer, it is game over. Kill the app. In a Java Swing app we built for a similar use case, we just trap the exception in the AWT event dispatcher, log it, and keep goi…

> This has not been my experience at all.

This has been my experience with software written in Java by developers who think it was not their experience.

> In a Java Swing app we built for a similar use case

...oh no. I actually tend to associate Swing UI with weird, undefined behaviors, and whenever I'd look under the hood, it would nearly _always_ be due to them trying to swallow runtime exceptions. Pure hubris, as far as I'm concerned.

> Another example is a web app: Any exception that bubbles up to the main request handler loop is likely (in our architecture) to happen before any change is made to the persistent store. Log it and handle another request.

Please, please, _PLEASE_ just crash the server. The OS will handle it, it will be OK, and systemd will even do the right thing and give up if your thing crashes _persistently_, including all the fancy stuff like keeping track of how often it crashes.

I've done too much cleaning up after overly-confident superstar architects, your examples just brings painful memories. I beg you stop trying to be clever and just log the error and crash the app.

Re: Don’t call it a comeback: Java is still champ

#316

Post by lenkite »

adgjlsfhk1 wrote: post #296
lenkite wrote: post #175

Earlier quoted context omitted.

A schema can be written in 15-30 mins to make XML as opinionated as you want it to be.

and then you'll read an xml file that doesn't meet your schema and your code will crash

With nice validation errors pointing to line, col where unexpected information was found. I'll definitely take that.

Re: Don’t call it a comeback: Java is still champ

#317

Post by vbezhenar »

sushisource wrote: post #139
bullen wrote: post #27

The only problem Java has is experienced C programmers don't build servers from scratch with it yet. Once they take that responsibility, the debate will be over because: "While I'm on the topic of concurrency I should mention my far too brief chat with Doug Lea. He commented that multi-threaded Java these days far outperforms C, due to the memory management and a garbage collector. If I recall correctly he said "only…

> This combined with the fact that Java doesn't crash Huh? Doesn't crash in what way vs. C? I can still deref a null pointer and blow up. Java's perfectly fine, and I have no idea why you'd write C any more, but if you care about (extreme) performance and not crashing, Rust seems the obvious modern choice here.

Dereferencing null is undefined behaviour in C. Probably it could be handled with platform-specific code, but handling it correctly not the easiest thing to do. Other than dereferencing null, there're so many ways to accidentally blow up C code and something like reading uninitialised memory is truly undefined behaviour which can't be worked around.

Java does not have undefined behaviour at all. Dereferencing null would throw NPE which is ordinary exception, completely fine to handle or suppress or whatever. There's no concept of uninitialised memory. The only sources of undefined behaviour in Java is calling native code or using unsafe methods which are very rare and usually located in well tested library code.

Even stack overflowing is defined behaviour and you can easily recover from it.

Re: Don’t call it a comeback: Java is still champ

#318

Post by pkolaczk »

mcculley wrote: post #277
pkolaczk wrote: post #273

Earlier quoted context omitted.

In Java if you encountered a null pointer exception or out of bounds error at the global level, there is also no guarantee you can safely continue, and dumping the stack and terminating is the only sensible option. Sure, the JVM is ok, but your app state might be already corrupt.

This has not been my experience at all. The JVM is not corrupted by a NPE or out of bounds access unless you are using native code. For example, I worked on a large X-Windows/Motif application with many developers. If some library dereferences a null pointer, it is game over. Kill the app. In a Java Swing app we built for a similar use case, we just trap the exception in the AWT event dispatcher, log it, and keep goi…

I haven't said that the JVM would be corrupt by NPE. But C program state would also not be, and you could do the same handling as in Java.

But if your code invoked an NPE or bounds check, then it means either the algorithm is incorrect or the data it processes are already corrupt by incorrect processing earlier. Continuing in such situation increases the risk, because you don't have any guarantees which parts of the application state might have been already corrupted by the bug. I've seen many many times an NPE was a result of a shared data corruption caused by a data race. JVM does not guarantee thread state isolation, so one bug can break the state of all threads.

> Log it and handle another request

That gives you only a false sense of safety. A Java app (and any other app) may die for many other reasons you can't handle. You need to be prepared for that anyway if you want a reliable service. But if you are prepared for that, and your server can restart in 0.1 second, you don't win anything by recovering from NPEs.

Re: Don’t call it a comeback: Java is still champ

#319

Post by exabrial »

lliamander wrote: post #133
bullen wrote: post #27

The only problem Java has is experienced C programmers don't build servers from scratch with it yet. Once they take that responsibility, the debate will be over because: "While I'm on the topic of concurrency I should mention my far too brief chat with Doug Lea. He commented that multi-threaded Java these days far outperforms C, due to the memory management and a garbage collector. If I recall correctly he said "only…

Erlang is not as peformant as Java, but there are plenty of reasons to prefer the former to the latter: - a much better concurrency model, that gets you parallelism for free just by adding cores - no global gc pauses, low-latency - fantastic operational tools (trace debugging, remote shell, etc.) - Erlang/OTP gives you great middleware out of the box, including including queues, pub-sub, service monitoring, database,…

> no global gc pauses, low-latency

Java also has this for at least a few years now. G1GC and ZGC in JDK17 offer no global stops unless absolutely necessary, and ZGC even has latency targets.

Re: Don’t call it a comeback: Java is still champ

#320

Post by nick__m »

ralmidani wrote: post #295
pwinnski wrote: post #291

Earlier quoted context omitted.

I don't think this is an issue with Java, it's an issue with Spring. I'm baffled by the popularity of Spring.

I’ve seen similar patterns with tech that’s older than Spring (Servlets/JSP). Also, wasn’t it EJB that promoted getters and setters everywhere?

JavaBeans in general promoted that convention. I first learned about Beans using Swing (the ui toolkit) since it makes heavy use of them.
Post reply on HN