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

71–80 of 327 posts

Re: Rating 26 years of Java changes

#71

Post by bdangubic »

vbezhenar wrote: post #51
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…

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?

Re: Rating 26 years of Java changes

#72

Post by guax »

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.

Re: Rating 26 years of Java changes

#74

Post by dcminter »

AbuAssar wrote: post #55

so java 22, 23, 24 are all released in 2024?

No, it's a 6 month release cadence. You might be confusing the initial release with a point release which are less regular. Edit: oh, my bad, I see the article author had the wrong year for 24.

  22 was March 2024
  23 was September 2024
  24 was March 2025
  25 was September 2025
This is much better than the old "release train" system where e.g Java 5 and Java 6 were released in Sept 2004 and Nov 2006 respectively!

Re: Rating 26 years of Java changes

#75

Post by guax »

Supermancho wrote: post #39
Traubenfuchs wrote: post #20

Earlier quoted context omitted.

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

This is what it looks like to me. If you wanted to do this, why not use a scripting language where you can use this kind of practice everywhere? In Java, I don't expect to have to look up the return type of something to discover a variable type. Graciously, I can see how you can save rewriting the Type declaration when it's a function return you want to mutate. Generally, you save some keystrokes to let other people…

Modern IDEs will show you the type of anything at all times. I do not understand your point unless you're doing raw text editing of Java source.

Those keystrokes are not just saved on writing, they make the whole code more legible and easier to mentally parse. When reading I don't care if the variable is a specific type, you're mostly looking whats being done to it, knowing the type becomes important later and, again, the IDE solves that for you.

Re: Rating 26 years of Java changes

#76

Post by taftster »

bdangubic wrote: post #46
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.

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 external from the application and I can manage it from /etc style layouts. Hard coding and compiling in dependency injection via annotations or other such behaviors into the class directly has caused me grief over the long term pretty much every time.

Re: Rating 26 years of Java changes

#77

Post by JavierFlores09 »

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…

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/watch?v=lnfnF7otEnk

Re: Rating 26 years of Java changes

#78

Post by brap »

Wow I can’t believe try with resources is so old! I’ve been working with Java for years and only learned this exists recently, I thought it must be relatively new. 14 years!

Re: Rating 26 years of Java changes

#79

Post by prein »

dcminter wrote: post #66
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

Or my favourite... Short w = 42; Short x = 42; out.println(w == x); // true Short y = 1042; Short z = 1042; out.println(y == z); // false

Once, after we had an application go live, we started getting reports after a few hours that new users were unable to log in.

It turns out, somewhere in the auth path, a dev had used `==` to verify a user's ID, which worked for Longs under (I believe) 128, so any users with an ID bigger than that were unable to log in due to the comparison failing.

Re: Rating 26 years of Java changes

#80

Post by whartung »

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 get the attraction to var, but I, personally, don't use it, as I feel it makes the code harder to read.

Simply, I like (mind, I'm 25 year Java guy so this is all routine to me) to know the types of the variables, the types of what things are returning.

  var x = func();
doesn't tell me anything.

And, yes, I appreciate all comments about verbosity and code clutter and FactoryProxyBuilderImpl, etc. But, for me, not having it there makes the code harder for me to follow. Makes an IDE more of a necessity.

Java code is already hard enough to follow when everything is a maze of empty interfaces, but "no code", that can only be tracked through in a debugger when everything is wired up.

Maybe if I used it more, I'd like it better, but so far, when coming back to code I've written, I like things being more explicit than not.

Post reply on HN