Rating 26 years of Java changes • Hacker News Board

Re: Rating 26 years of Java changes

#81

Post by SkiFire13 » Sat, Oct 11, 2025, 10:13 PM UTC

9dev wrote: post #47

dhosek wrote: post #9

Earlier quoted context omitted.

I used to joke that the direction spring was heading was that you’d have an application be a boilerplate main method with a dozen lines of annotations. Then I actually encountered this in the wild: we had an app that sent updates from db2 to rabbitmq, and the application literally was just configuration via annotations and no actual Java code other than the usual spring main method.

Is that strictly bad, though? Being able to run an enterprise service by setting configuration values declaratively, and get all the guarantees of a well-tested framework, seems like a pretty good thing. Yes, it’s weird how that’s still Java, but using standard components and only using code as glue where it’s absolutely necessary seems very similar to other engineering disciplines to me.

I think the general adversity against this specialized configurations is that they often tend to be fairly limited/rigid in what they can do, and if you want to customize anything you have to rewrite the whole thing. They effectively lock you into one black box of doing things, and getting out of it can be very painful.

Re: Rating 26 years of Java changes

#82

Post by brap » Sat, Oct 11, 2025, 10:13 PM UTC

marginalia_nu wrote: post #17

I think the author is sleeping on Java assertions. I really like the feature, and it's really one of the features I feel Java got right. The syntax is very expressive, and they can easily be made to generate meaningful exceptions when they fail. It's also neat that it gives the language a canonical way of adding invariant checks that can be removed in production but run in tests or during testing or debugging (with -…

What are the pros of making this a keyword vs just a standard function?

Re: Rating 26 years of Java changes

#83

Post by a57721 » Sat, Oct 11, 2025, 10:13 PM UTC

Traubenfuchs wrote: post #20

Supermancho wrote: post #6

Can someone explain why developers like var?

It‘s a harmful code smell: It often obfuscates the type, forcing you to actively check for the type and should not be used.

It is used for things like "Foo x = new Foo()" where the type is obvious.

Re: Rating 26 years of Java changes

#84

Post by travisgriggs » Sat, Oct 11, 2025, 10:16 PM UTC

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 Java on were emotional/irrational, enforced by comments like:

“Of Course Java will Work, there’s not a damn new thing in it” — James gosling, but I’ve always suspected this might be urban legend

“Java, all the elegance of C++ syntax with all the speed of Smalltalk” - Kent Beck or Jan Steinman

“20 years from now, we will still be talking about Java. Not because of its contributions to computer programming, but rather as a demonstration of how to market a language” — ??

I can code some in Java today (because, hey, GPT and friends!! :) ), but have elected to use Kotlin and have been moderately happy with that.

One thing that would be interesting about this list, is to break down the changes that changed/evolved the actual computation model that a programmer uses with it, vs syntactic sugar and library refinements. “Languages” with heavy footprints like this, are often just as much about their run time libraries and frameworks, as they are the actual methodology of how you compute results.

Re: Rating 26 years of Java changes

#85

Post by alex_smart » Sat, Oct 11, 2025, 10:18 PM UTC

bdangubic wrote: post #71

vbezhenar wrote: post #51

Earlier quoted context omitted.

Yeah, it works until it isn't. And they good luck debugging it. I'd prefer simple obvious linear code calling some functions over this declarative magic any day. cronService.schedule("xxx", this::refresh); This isn't any harder than annotation. But you can ctrl+click on schedule implementation and below easily. You can put breakpoint and whatnot.

never had any issues debugging as I am never debugging the scheduler (that works :) ) but my own code. and what exactly is “cronService”? you write in each service or copy/paste each time you need it?

You can write your own libraries?

My goodness. What a question!

Re: Rating 26 years of Java changes

#86

Post by mi_lk » Sat, Oct 11, 2025, 10:20 PM UTC

guax wrote: post #72

Supermancho wrote: post #6

Can someone explain why developers like var?

To me var is what makes modern java somewhat readable and more bearable. It was always a joke that it takes too long to write anything in java because of the excessive syntax repetitions and formalities. To me that joke is heavily based on a reality that modern Java is tackling with this quality of life features.

I have the opposite feeling. var makes it easier to write but harder to read/review. Without var you know the exact type of a variable without going through some functions for example

Re: Rating 26 years of Java changes

#87

Post by rr808 » Sat, Oct 11, 2025, 10:24 PM UTC

Java is great, Spring ruined the platform.

Re: Rating 26 years of Java changes

#88

Post by vbezhenar » Sat, Oct 11, 2025, 10:26 PM UTC

JavierFlores09 wrote: post #77

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…

Stuart Marks and Nicolai Parlog recently had a discussion about checked exceptions in the Java channel [0]. In short, while they mentioned that there are certainly some things to improve about checked exceptions, like the confusing hierarchy as well as the boilerplate-y way of handling them, they're not necessarily a failed concept. I do hope they get to work on them in the near future. 0: https://www.youtube.com/wat…

They are absolutely failed concept in Java. Every first popular library uses unchecked exceptions, including famous Spring. Java streams API does not support checked exceptions. Even Java standard library nowadays includes "UncheckedIOException". Kotlin, Scala: both languages grown from JVM and do not support checked exceptions.

Re: Rating 26 years of Java changes

#89

Post by ronyeh » Sat, Oct 11, 2025, 10:27 PM UTC

zylepe wrote: post #18

I haven’t used markdown in javadoc yet but this seems like at least 3/10? I often want to put paragraphs or bulleted lists in javadoc and find myself wanting to use markdown syntax for readability in the code but need to switch to less readable html tags for tooling to render it properly.

I hate using html in comments.

Markdown in javadoc is at least 7/10 for me. Improves comment readability for humans while allowing formatted javadocs.

Re: Rating 26 years of Java changes

#90

Post by nunobrito » Sat, Oct 11, 2025, 10:29 PM UTC

taftster wrote: post #76

bdangubic wrote: post #46

Earlier quoted context omitted.

this is exactly why spring succeeded. I need to run a scheduled job, @EnableScheduling then @Scheduled(cron = “xxxxxx”) - done. I need XYZ, @EnableXYZ the @XYZ… sh*t just works…

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.