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

Rating 26 years of Java changes

neilmadden.blog

Post reply on HN
Print view View original

241–250 of 327 posts

Re: Rating 26 years of Java changes

#241

Post by vips7L »

__float wrote: post #117
nine_k wrote: post #68

Earlier quoted context omitted.

Absolutely. It seems that the author never touched Spring, for instance, or a dependency-injection framework of any kind. Annotations allow to do things in a completely different way, removing tons of boilerplate. I'd give annotations 9/10 at least. (And I lost the interest in the rest of the article, given such a level of familiarity with the subject matter.)

My experience using Dagger (2) was so unpleasant that it really soured me on the possible uses of this feature. I understand the benefits of dependency injection, but to be totally honest I'm more likely to take the Go-style approach of wiring it all up manually, even if it's a bit of extra boilerplate. The indirection and abstractions built up in DI frameworks is rarely worth it IMO.

Dagger is by far the worst UX experience for a DI framework. Really you should try anything else. For compile time DI like dagger you can try Avaje Inject:

https://avaje.io/inject/

Re: Rating 26 years of Java changes

#242

Post by vips7L »

vbezhenar wrote: post #45
dkarl wrote: 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 errors aren’t universally ignored by developers. Rusts main error system is checked. Swift has really introduced checked typed throws. Kotlin is introducing checked error unions. Checked exceptions are the same thing.

Re: Rating 26 years of Java changes

#243

Post by vips7L »

rzwitserloot wrote: post #62
vbezhenar wrote: post #45

Earlier quoted context omitted.

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…

> For example they used checked exceptions. Those are from java 1.0 and thus don't appear to be relevant to the part of the discussion I think this part of the thread is about (namely: "Why doesn't java crib well designed features from other languages?"). > Java went with checked exceptions and nowadays they are almost universally ignored by developers. They aren't. Note that other languages invented for example 'Eit…

All modern languages are adopting a checked error system: Rust, Swift, Kotlin, Zig, Gleam; they all have some type of error you must handle.

The problem with Java is that they haven’t added the syntax to make dealing with those errors easy. It’s boiler plate hell.

Re: Rating 26 years of Java changes

#244

Post by commandersaki »

dcminter wrote: post #15
JanisErdmanis wrote: post #11

Earlier quoted context omitted.

That doesn't sound very pleasant.

Well, it was annoying until autoboxing came in. // Before autoboxing list.add(new Integer(42)); // After autoboxing list.add(42); Mostly it's a non-issue now. If you're desperately cycle/memory constrained you're likely not using Java anyway.

If you're desperately cycle/memory constrained you're likely not using Java anyway.

Java Cards would like to have a word with you. But yeah I know what you mean.

Re: Rating 26 years of Java changes

#245

Post by vips7L »

rectang wrote: post #176
bigstrat2003 wrote: post #160

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…

Do you not have to check the signature to see what a function can return when using Results? It’s off in another file too.

> failing to make a clean distinction between recoverable errors and unrecoverable bugs

Recoverability is context specific. One persons panic may just be another error case for someone else. I think this is one thing that programmers miss when talking about this topic. It is really up to the caller of your function if something should panic. You can’t make that decision for them.

Re: Rating 26 years of Java changes

#246

Post by vips7L »

Traubenfuchs wrote: post #225
noisy_boy wrote: post #181

Earlier quoted context omitted.

What if I'm just looking at a pull request on GitHub? Sure I can check out the branch etc but that's just adding more friction.

Bingo. Sometimes I doubt most hacker news commentors have ever worked in big corpo environments where you have to regularly review large PR in some broken webapp like GitHub.

If you haven’t used GitHub plugins in your ide to review you should really give it a try. It’s really night and day.

Re: Rating 26 years of Java changes

#247

Post by adben »

A little bit bias and opinionated... Tho limited, lambdas and streams were a paradigm shift so big that revamped the love for java into functional programming... Not just a set of features introduced in Java 8.

Re: Rating 26 years of Java changes

#248

Post by clanky »

vbezhenar wrote: post #224
samus wrote: post #196

Earlier quoted context omitted.

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 l…

> Checked exceptions are for errors that are not possible to prevent. How else should the caller know which exceptions are really likely to happen? The same way, caller can know which exceptions are really likely to happen in TypeScript, C++, Python. Or in modern Java which avoids checked exceptions anyway. By reading documentation or source code. That's perfectly fine and works for everyone. And you highlighted one…

There's a recent Reddit thread with some good discussion around modules where Ron Pressler took part. tl;dr: the architects acknowledge uptake outside the JDK has been slow, largely because there have always been few benefits to modules, and secondarily because build tool support is lacking (perhaps because of the first reason). At some point they may begin providing additional benefits to modularization which may help stoke demand.

https://www.reddit.com/r/java/comments/1o37hlj/reopening_the...

Re: Rating 26 years of Java changes

#249

Post by dkarl »

lenkite wrote: post #211
dkarl wrote: post #107

Earlier quoted context omitted.

You're absolutely right about checked exceptions. However, I think they're an exception (forgive me) from the pattern of Java mostly sticking to the strategy of, we can build a practical, industrial, reasonably performant language that has all these nice bits from other languages: garbage collection, portable bytecode, no pointer arithmetic, collections in the standard library, etc. I think streams are a great exampl…

Totally Hard disagree on streams - I used parallel streams in my last Job nearly all the time. They are critical for cpu-intensive tasks involving large datasets. And they do involve just a single code change in the consuming code. Sequential to parallel processing can be done via one `.parallel`. I always believed it was a major plus point for Java compared to other languages. I am even surprised to hear otherwise.…

In the companies I've worked at, those kinds of workloads have been done in Spark or in Beam (GCP Dataflow, etc.)

Re: Rating 26 years of Java changes

#250

Post by mightyham »

fleventynine wrote: post #106

Still no unsigned integer types in the standard library after 26 years?

In one of James Gosling's talks he tells a funny story about the origin of this design decision. He went around the office at Sun and gave a bunch of seasoned C programmers a written assessment on signed/unsigned integer behaviors. They all got horrible scores, so he decided the feature would be too complicated for a non-systems programming language.
Post reply on HN