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

161–170 of 327 posts

Re: Rating 26 years of Java changes

#161

Post by paulddraper »

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…

So…pass that variable to your annotation.

I’m not seeing the point?

Re: Rating 26 years of Java changes

#162

Post by paulddraper »

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…

Go implements green threads.

It might only be one language, but it’s a pretty big one

Re: Rating 26 years of Java changes

#163

Post by bigstrat2003 »

newAccount2025 wrote: post #41
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.

Your IDE can do that?

Languages should not be designed around the assumption that people use an IDE.

Re: Rating 26 years of Java changes

#164

Post by bigstrat2003 »

agos wrote: post #63
marginalia_nu wrote: post #35

Earlier quoted context omitted.

Yeah that's very much an explicit design philosophy of Java, dating way back. Let other languages experiment, and adapt what proves useful. It hasn't worked out in terms of delivering perfect language design, but it has worked out in the sense that Java has an almost absurd degree of backward compatibility. There are libraries that have had more breaking changes this year than the Java programming language has had in…

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.

Re: Rating 26 years of Java changes

#165

Post by throwaway7783 »

alex_smart wrote: post #85
bdangubic wrote: post #71

Earlier quoted context omitted.

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!

Whole point of spring is so you don't have to write your own libraries. Batteries included and all.

Re: Rating 26 years of Java changes

#166

Post by didntcheck »

skeletal88 wrote: post #60
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…

Then you need to deploy it on multiple nodes and neex to make sure it only runs once for each run of the cron, etc.

I believe Quartz is the go-to solution for this. It's not part of Spring but it offers a similar annotation-driven interface, but with distributed locking via a database

Re: Rating 26 years of Java changes

#167

Post by bdangubic »

throwaway7783 wrote: post #165
alex_smart wrote: post #85

Earlier quoted context omitted.

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

Whole point of spring is so you don't have to write your own libraries. Batteries included and all.

@alex_smart hand rolls it all :)

Re: Rating 26 years of Java changes

#168

Post by fleventynine »

hashmash wrote: post #155
MBCook wrote: post #148

Earlier quoted context omitted.

It’s rare I have to do bit math but it’s so INCREDIBLY frustrating because you have to do everything while the values are signed. It is amazing they haven’t made a special type for that. I get they don’t want to make unsigned primitives, though I disagree, but at least makes something that makes this stuff possible without causing headaches.

Sometimes I'd like to have unsigned types too, but supporting it would actually make things more complicated overall. The main problem is the interaction between signed and unsigned types. If you call a method which returns an unsigned int, how do you safely pass it to a method which accepts a signed int? Or vice versa? Having more type conversion headaches is a worse problem than having to use `& 0xff` masks when do…

> If you call a method which returns an unsigned int, how do you safely pass it to a method which accepts a signed int?

The same way you pass a 64-bit integer to a function that expects a 32-bit integer: a conversion function that raises an error if it's out of range.

Re: Rating 26 years of Java changes

#169

Post by _ea1k »

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…

IDK, I've worked in projects that didn't use the magic so much and I honestly think it was worse.

Instead of a config class and a bunch of apps with @Inject Config config;, we'd have giant *Config classes. Each one would have lots of methods like:

@Bean public fooProducer(FooConfig config, BazProvider provider, BarProvider barProvider, SoapClient soapClient) {...}

Want to know how they were produced? Find usages on the class' constructor.

The magic @Inject and @Autowired annotations don't seem worse than that to me.

Re: Rating 26 years of Java changes

#170

Post by _ea1k »

2muchcoffeeman wrote: post #116
SkiFire13 wrote: post #81

Earlier quoted context omitted.

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.

Spring boot just provides what they think are reasonable defaults and you provide some specifics. You can always inject your own implementation if needed right?

In theory, yes. In practice, I've found that things get really complicated as soon as you start trying to interact with the spring lifecycle. Figuring out how to customize things and manage priority is the trickiest thing in Spring, IMO.
Post reply on HN