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

171–180 of 327 posts

Re: Rating 26 years of Java changes

#171

Post by _ea1k »

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…

I agree with you w/r/t the streaming parallelization. I remember huge arguments about this on some of the lists back in the day, because that design decision had lots of ridiculous consequences.

Eg, mutable state capture in lambdas is largely restricted because of the thought that people would use parallel threads within the stream processing blocks. That decision lead to lots of ugly code, IMO.

I've also never seen a need to try to parallelize a simple stream processing step.

Re: Rating 26 years of Java changes

#172

Post by zeroq »

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…

The list generally oversimplifies a lot of things, but you're on point with annotations.

Mandatory personal anecdote:

I'm not a java guy, but I've been around java since '99, and few years ago I was moved to a strictly java team. Upon introduction I decided to show them my party trick and implemented live a pseudo "wolf3d" in one day. As usual, java devs were sort of impressed by the fact that you can do graphics and user input in java, because nowadays that's extremely rare for most of them. I got my approval and in return I asked them to give me a quick one day deep dive into Spring.

At the end I was presented with a basic hello world project that was comprised mostly of... EMPTY CLASSES I mean literally, class Foo {} END OF FILE!

Of course these empty classes had at least 5 lines of annotations on top of class declaration and in the end it somehow pushed the framework into the right direction, but oh my fucking god, I was throwing up in my mouth for the rest of the week.

Re: Rating 26 years of Java changes

#173

Post by taftster »

le-mark wrote: post #159
sass_muffin wrote: post #144

Earlier quoted context omitted.

I do realize you were intending to give examples of why you don't think annotations aren't very extensible, but it is an odd example as all those things can still be achieved via annotation, since the annotations can accept values loaded from env specific properties.

Exactly this, it’s great fun to have a surface level understanding of a topic and post derisively for internet points; rather then spend the time and effort to actually learn about the subject at hand!

I'm not digging for "internet points". Yes, superficial replacement values can be retrieved from the environment. But I guess we have to give you a more imagined or sophisticated example then to make the point to you?

How about varying implementations of a service interface. Let's say I have a Scheduler interface and I want to have multiple implementations; maybe one is CronScheduler, another is RandomScheduler, another is BlueMoonScheduler. Each of these schedulers have their own properties and configuration values. I might want to choose, per environment or deployment context, which service implementation to use.

Annotation configuration makes this (near?) impossible to dynamically wire and configure these scenarios and make them tailored to the environment or deployment scenario. Annotations are generally "static" and do not follow a configuration-as-code approach to application deployment.

An external configuration file, as offered by Spring's original (less "favored") XML style, allowed a more composable and sophisticated configuration-as-code approach. Maybe that's a negative, putting that much power into the hands of the service administrator. But as I stated originally, in my experience, having statically defined annotation driven configuration and/or dependency injection has caused more problems than it has solved.

Re: Rating 26 years of Java changes

#174

Post by gbear605 »

bigstrat2003 wrote: post #164
agos wrote: post #63

Earlier quoted context omitted.

What other language made them think checked exceptions were a good idea?

They are a good idea. They solve the problem that you don't know where an exception is coming from (the "invisible control flow" complaint), and let the compiler help you to avoid mistakes when refactoring. There is zero valid reason to hate on checked exceptions.

The only problem with them is that they don’t work well with lambdas (and related features like Stream). If you need to call a method that throws a checked exception inside of a Stream, there’s no good way to pass it up other than re-throwing it as unchecked or some other hack (like collecting all the thrown exceptions in a separate loop).

A different implementation of lambdas that allow for generic exceptions would probably solve it, but then that introduces other issues with the type system.

My other complaint is that the standard library didn’t have enough pre-made exceptions to cover common usecases.

Re: Rating 26 years of Java changes

#175

Post by vlovich123 »

sass_muffin wrote: post #144
taftster wrote: post #76

Earlier quoted context omitted.

And then I realize I need to change that schedule. And would like to do it without recompiling my code. Oh, and I need to allow for environment specific scheduling, weekdays on one system, weekends on others. And I need other dependencies that are environment specific. I much prefer Spring's XML configuration from the old days. Yeah, XML sucks and all that. But still, with XML, the configuration is completely externa…

I do realize you were intending to give examples of why you don't think annotations aren't very extensible, but it is an odd example as all those things can still be achieved via annotation, since the annotations can accept values loaded from env specific properties.

> env specific properties

And then if you want to change a value at runtime you have to restart the executable?

Re: Rating 26 years of Java changes

#176

Post by rectang »

bigstrat2003 wrote: post #160
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 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 they go through the same try-catch mechanism, failing to make a clean distinction between recoverable errors and unrecoverable bugs. (In e.g. Rust and Go, recoverable errors go through return values but unrecoverable errors go through panics.)

In the end, Java's exception design simultaneously requires a lot of effort to comply with, but makes it difficult to understand when you've successfully locked things down.

Re: Rating 26 years of Java changes

#177

Post by petersellers »

vlovich123 wrote: post #175
sass_muffin wrote: post #144

Earlier quoted context omitted.

I do realize you were intending to give examples of why you don't think annotations aren't very extensible, but it is an odd example as all those things can still be achieved via annotation, since the annotations can accept values loaded from env specific properties.

> env specific properties And then if you want to change a value at runtime you have to restart the executable?

Most web application servers work this way. It also works really well in practice using modern CD tools - update your configuration and perform a gradual rollout of all your application servers to reflect the updated configuration.

Re: Rating 26 years of Java changes

#178

Post by taftster »

nunobrito wrote: post #90
taftster wrote: post #76

Earlier quoted context omitted.

And then I realize I need to change that schedule. And would like to do it without recompiling my code. Oh, and I need to allow for environment specific scheduling, weekdays on one system, weekends on others. And I need other dependencies that are environment specific. I much prefer Spring's XML configuration from the old days. Yeah, XML sucks and all that. But still, with XML, the configuration is completely externa…

The only real-world usage I see for annotations are in GSON (the @Expose) and JUnit with @Test. Never really came across with any other real cases where it solves a pressing issue as you mention. Most times is far more convenient to do things outside the compiled code.

Agreed. These are good examples where annotations seem like a good fit. Being able to tell a processor that a method or field is "special". Test methods, serializable hints, etc.

It's kind of like, when annotations were delivered to Java, lots of projects thought they were just the next greatest thing. I followed right along at the time, as well.

But over time, finding the value in the configuration-as-code approach to application deployment, I definitely feel that annotations have been abused for many use cases.

Re: Rating 26 years of Java changes

#179

Post by blandflakes »

commandersaki wrote: post #140
sedro wrote: post #37

Autoboxing's evil twin, auto-unboxing should knock the score down a few points. Integer a = null; int b = 42; if (a == b) {} // throws NullPointerException

I'm not much of a PL nerd, what should it do?

Return false! They aren't equal. But of course we're comparing a reference to a primitive, so we either lift the primitive to a reference, or lower the reference... so here we are.

Re: Rating 26 years of Java changes

#180

Post by paulddraper »

SerCe wrote: 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…

Yeah modules isn’t for end users, at least not for the most part
Post reply on HN