Live data from Hacker News

Rating 26 years of Java changes

neilmadden.blog

191–200 of 327 posts

Re: Rating 26 years of Java changes

#191
post #101

It's nice to review the features, but the history of Java isn't really about features or even programmer popularity. (1) It was the first disruptive enterprise business model. They aimed to make everyone a Java programmer with free access (to reduce the cost of labor), but then charge for enterprise (and embedded and browser) VM's and containers. They did this to undercut the well-entrenched Microsoft and IBM. (IBM f…

The business plan originally was to sell CPUs that ran Java natively. And these would be fast. That idea failed miserably.

Re: Rating 26 years of Java changes

#192
post #5

Definitely underrates the impact of annotations. I'm personally not a fan of the way annotations are used to implicitly wire together applications, but I have to admit the impact. Maybe 5/10 is fair in light of the wide range of positive and extremely negative ways annotations can be used. So many of these features were adopted after they were proven in other languages. You would expect that since Java took such a sl…

I don't really feel that Java uses proven features. For example they used checked exceptions. Those definitely do not seem like proven feature. C++ has unchecked exceptions. Almost every other popular language has unchecked exceptions. Java went with checked exceptions and nowadays they are almost universally ignored by developers. I'd say that's a total failure. Streams another good example. Making functional API fo…

You've never used parallel streams? They're my favorite way to do parallel computation in Java, and very easy if you've structured your problem around streams.

Re: Rating 26 years of Java changes

#194

Ah Java. The language I never got to love. I came of coding age during the “camps” era of object oriented stuff: Eiffel, Smalltalk, CLOS, C++, etc. Java, from 95ish to oh 98ish, was like a giant backdraft. Completely sucked the air out of the room for everything else. Does anyone remember the full page ads in WSJ for programming language, that no on quite yet knew what it really was? So my formative impressions of Ja…

> I can code some in Java today (because, hey, GPT and friends!! :) ),

I love GPT. Such a marvellous tool. Before ChatGPT came along, I had no medical experience. Thanks to GPT and friends, I am now a doctor. I've opened a clinic of my own.

Re: Rating 26 years of Java changes

#195

Earlier quoted context omitted.

You can get pretty good performance out of Java these days, so long as you know to avoid stuff like boxed primitives and the streams api, as they generally have god-awful memory locality, and generally don't vectorize well.

Yeah, I know there are even oddballs using it for HFT and the like - I like Java a lot, but even I find that a bit peculiar. Edit: actually, if someone here is using it for something like that I'd love to hear the rationale...?

Not „oddballs“ for sure. Java established itself as the primary enterprise language for fintech in 2000s and since then there was and there is no reason to switch. It offers everything business needs including vast supply of workforce.

Re: Rating 26 years of Java changes

#196
post #5

Definitely underrates the impact of annotations. I'm personally not a fan of the way annotations are used to implicitly wire together applications, but I have to admit the impact. Maybe 5/10 is fair in light of the wide range of positive and extremely negative ways annotations can be used. So many of these features were adopted after they were proven in other languages. You would expect that since Java took such a sl…

I don't really feel that Java uses proven features. For example they used checked exceptions. Those definitely do not seem like proven feature. C++ has unchecked exceptions. Almost every other popular language has unchecked exceptions. Java went with checked exceptions and nowadays they are almost universally ignored by developers. I'd say that's a total failure. Streams another good example. Making functional API fo…

Checked exceptions are for errors that are not possible to prevent. How else should the caller know which exceptions are really likely to happen?

Modules absolutely achieved their primary goal: stopping libraries from accessing JDK internals without the application's knowledge. The ecosystem is slow on the uptake since split packages and access to internal APIs is endemic, but it is happening ever so slowly. I wish libraries could opt into not being part of the unnamed module.

Virtual threads were designed with explicit cooperation of the community, with the explicit goal of making it easy to switch as much existing code over to it as possible. I really don't understand the scepticism there. Most other languages went with promises or reactive streams because they were inspired by how functional programming languages do it.

Re: Rating 26 years of Java changes

#197

Earlier quoted context omitted.

> For example they used checked exceptions. Those definitely do not seem like proven feature. Checked exceptions are an awesome feature that more languages should have. Just like static typing is a good thing because it prevents errors, checked exceptions are a good thing because they prevent errors.

Idealized checked exceptions are isomorphic to Rust's `Result` type, which is great. Java's implementation of checked exceptions has some issues, though. * "Invisible control flow", where you can't tell from the call site whether or not a call might throw (you need to check the signature, which is off in some other file, or perhaps visible in an IDE if you hover). * Java has both checked and unchecked exceptions, but…

> * "Invisible control flow", where you can't tell from the call site whether or not a call might throw (you need to check the signature, which is off in some other file, or perhaps visible in an IDE if you hover).

Never found this this to be a problem. It is really common to all implementations of exceptions, not just checked ones. And when you write code the compiler will yell at you. In monadic code,

Re: Rating 26 years of Java changes

#198
post #149

My read is that it's easy to be quite negative on Java features when you're not the person they were designed for. For example, the main "customer" of the module system is the JDK itself. The main customer of NIO/2 is the low-level libraries like Netty. I highly recommend the Growing the Java Language talk by Brian Goetz to anyone who's interested in the philosophy behind evolving the modern Java language [1]. And Do…

>For example, the main "customer" of the module system is the JDK itself As mentioned in TFA, "The general advice seems to be that modules are (should be) an internal detail of the JRE and best ignored in application code" So yeah, why expose it to those who are not the "main customer"?

It’s just too complex. They should have went with the internal modifier.

Re: Rating 26 years of Java changes

#199

Earlier quoted context omitted.

You can write your own libraries? My goodness. What a question!

you write your own database driver? encryption?

If you want to build an application from scratch, you must first create the universe.

Re: Rating 26 years of Java changes

#200

Earlier quoted context omitted.

You can write your own libraries? My goodness. What a question!

you write your own database driver? encryption?

Why would I write my own database driver or encryption just because I wanted to implement my own "cronService"?
Post reply on HN