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

291–300 of 557 posts

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

#291

Post by pwinnski »

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…

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

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

#292

Post by oftenwrong »

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…

Unfortunately, records are only guaranteed to be 'shallowly' immutable. It would be great if future Java versions provided a straightforward way to enforce immutability.

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

#293

Post by topspin »

bhuber wrote: post #266
topspin wrote: post #239

Earlier quoted context omitted.

> but @lombok.NonNull helps a lot Which @NonNull? There's javax.validation.constraints.NotNull, org.springframework.lang.NonNull, org.checkerframework.checker.nullness.qual.NonNull, org.jetbrains.annotations.NotNull, android.support.annotation.NonNull and a bunch of others[1]. The proliferation of Not|NonNull is evidence that I'm right, no matter how hard I get downed on HN. [1] https://stackoverflow.com/questions/35…

I didn't say it wasn't a problem - if I could wave a magic wand and get rid of the concept of null in Java I would. That isn't what we're discussing though - you said, "The biggest thing missing in Java is an answer for the billion-dollar mistake [- NPEs]". I've provided what I consider to be at least a partial answer. If you care about avoiding NPEs in Java, it's a pretty good solution. Realistically, null is so fun…

> Realistically, null is so fundamental to the Java language that removing it would...

Again, as jayd16 pointed out a solution has been retrofitted to C#, Java's great nemesis. I don't accept the argument that this is somehow infeasible. Just make null assignments (including potential ones coming from libraries) an error and allow this feature to be scoped to your source files. Eventually the practice becomes ubiquitous. It's been done again and again in many languages and their various 'strict' modes.

The only actual problem here is that Java language developers aren't feeling sufficient pressure to address it. They should, but they're not, and that's sad. That sort of sadness is a common theme with Java.

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

#294

Post by slekker »

haspok wrote: post #114
BenoitP wrote: post #97

Earlier quoted context omitted.

With Loom incoming, Go's only unfair advantage (shared with Erlang) may be gone soon. I guess we'll have the answer in a few years. Will the next WhatsApp be written in Java?

Loom does a small fraction of what the Erlang VM is capable of doing. For one, the Erlang VM has built-in preemptive green thread scheduling, which means it can suspend your green thread at ANY instruction, not just when an IO call is in progress. Loom is a step in the right direction, but Erlang is in its own universe for what it was designed for.

Is Loom THAT big of a deal? Can you point me towards some references of why this is the case?

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

#295

Post by ralmidani »

pwinnski wrote: post #291
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…

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?

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

#296

Post by adgjlsfhk1 »

lenkite wrote: post #175
gen220 wrote: post #45

Earlier quoted context omitted.

I think people dislike XML precisely because it's so flexible and unopinionated. It means that when you're parsing a new XML source, you have to look for data that might be encoded in two or three little niches. God help you if it's encoded in each of them, and if the data therein is contradictory. Basically, it's easy to "hold it wrong" in a way that harms consumers.

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

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

#297

Post by oftenwrong »

topspin wrote: post #62
e67f70028a46fba wrote: post #26

The biggest thing Java is missing is full hot swap. Its been implemented via the dcevm but, inexplicably, has been ignored by both sun and oracle. This one, existing technology would make Java DX on par with the dynamic languages

> The biggest thing Java is missing is full hot swap The biggest thing missing in Java is an answer for the billion-dollar mistake. Real world Java is plagued by NPEs because a lot of Java is written by low caliber programmers. Java + functional error handling would be a monumental improvement.

Java should adopt something like the Checker Framework Nullness Checker in its first-party tooling.

https://github.com/typetools/checker-framework

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

#298

Post by neeleshs »

imtringued wrote: post #279
neeleshs wrote: post #201

Earlier quoted context omitted.

Biggest benefit with Erlang for me is preemptive scheduling. Has a perf hit, but you don't get brownouts. Java lacks this and this results in hanging threads. A lot monitoring has to be there to detect these conditions . Project loom makes this somewhat better, but at its core, java threads are not preemptible

Java uses regular OS threads that provide preemption by default... Whatever you are talking about has nothing to do with preemption.

Right. I meant interruption is cooperative.

https://docs.oracle.com/javase/tutorial/essential/concurrenc...

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

#299

Post by kaba0 »

mdasen wrote: post #106

The JVM is pretty great. I could certainly nitpick things, but it's pretty great. Java is pretty decent. However, I would say that Java lost a lot of time and even now there are some decently rough edges. Java didn't evolve as a language for a while and that left the door open to other languages and other non-JVM ecosystems a lot. As the article notes, Java 8 was a breath of fresh air, but it was minimal in some ways…

The situation regarding POJOs are annoying, but I believe Java maintainers are fighting the good fight: introducing them in the language would hardcode this arguably bad pattern indefinitely. One might say that with the amount of code written this way, properties are already here to say, but I personally find Java’s stance on feature addition much more sane than C# cool and quick, buy maybe too fast one.

I like to believe that records with the upcoming ‘withers’ will be an adequate answer (if a bit too late) to this whole question.

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

#300

Post by ransom1538 »

kentonv wrote: post #274
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…

Oh, please. I once worked on a Java-based server at Google that had to answer requests with millisecond latency. In order to achieve this, the server had to block garbage collection most of the time. Periodically, each instance of the server would ask the load balancers to stop sending requests to it, so that it could then safely run the garbage collector, and then ask for traffic to return. We likely would not have…

Google should have picked a real language: php. When script is completed all resources are freed, let the OS figure it out. No manual GC drama.
Post reply on HN