Live data from Hacker News

Rating 26 years of Java changes

neilmadden.blog

231–240 of 327 posts

Re: Rating 26 years of Java changes

#231
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?

Fail to compile when you assign something which isn't an integer to an integer.

Re: Rating 26 years of Java changes

#232

Earlier quoted context omitted.

If you want to build an application from scratch, you must first create the universe.

All this because I told one guy who asked "what exactly is “cronService”? you write in each service or copy/paste each time you need it?" that they can reuse code by writing a library instead of copy/pasting it? If this is the level of incompetence encouraged by a framework, I would avoid using it just to avoid the chance of hiring people like you. Just kidding. Spring boot is great. But yeah, I would fire people wit…

* Why would I write my own database driver or encryption just because I wanted to implement my own "cronService"?*

how do you decide whether you will write your own or pull in a dependency? this is a legit question. you did start this with writing your own “cronService” (which is about as insane as writing your own database driver) so asked about it.

Re: Rating 26 years of Java changes

#234
post #87

Java is great, Spring ruined the platform.

As someone who has used Java pretty extensively for a few years (but in an environment where Spring was forbidden), why is that?

The beautiful and essential technique of DI (dependency inversion) got namesquatted hard by DI (dependency injection).

Before, you used to write "loosely coupled" software by decoupling your business logic from your IO to keep it testable. You could take virtually anything worth testing, 'new' it in a unit test, and bob's your uncle.

Now you write "loosely coupled" software by keeping the coupling between components, but also couple them to a bunch of Spring dependencies too (check your imports!). Now you can't instantiate anything without Spring.

Re: Rating 26 years of Java changes

#235
post #139

Earlier quoted context omitted.

But ... LocalDate predated records by 6 years? Eventually, I guess there'll be backwards compatible "pattern extractors" functionality retrofittable to existing "record-like" classes. This has been hinted at on several occasions.

Records are great, but objects work. Date flat out doesn’t. We needed something in the standard library to fix that. It should’ve happened long before it did.

Totally agree, I was just pointing out to GP why LocalDate wasn’t a record. (Date and Calendar should never be used in new code. Note how the new date/time API doesn’t have any conversions to/from old types (Date+Calendar), they only in the opposite direction)

Can’t wait for destructuring support for classes, though.

Re: Rating 26 years of Java changes

#236
Great list, even if I disagree with many of the ratings!

But astonished that Optional isn't mentioned either there or in the comments. A second way to represent no-value, with unclear and holy-war-ushering guidance on when to use, and the not exactly terse syntax I see everywhere:

Optional ickOpt = Optional.ofNullable(ickGiver.newIck()); ickOpt.flatMap(IckWtfer::wtf).ifPresentOrElse((Wtf wtf) -> unreadable(wtf)), () -> { log.warn("in what universe is this clearer than a simple if == null statement?!"); });

Re: Rating 26 years of Java changes

#237

Earlier quoted context omitted.

It's another thing they adopted from Kotlin, since Kotlin is supposed to be a "better java". Now Java is retroactively adopting Kotlin freatures.

Kotlin didn't invent type inference, it's a feature from ML.

I never said Kotlin invented type inference, just that the syntax was straight adopted from kotlin

Re: Rating 26 years of Java changes

#238
post #231

Earlier quoted context omitted.

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

Fail to compile when you assign something which isn't an integer to an integer.

None of that code does that; the "issue" is with `==` between an int and an Integer. I'd accept a failure to compile _that_, but that does kind of kill the utility of the 99.9% of times where auto-boxing and unboxing is syntactically simpler.

Re: Rating 26 years of Java changes

#239
post #158
post #154

Earlier quoted context omitted.

You’ll find differing opinions. As someone who has worked on code bases that did not have spring that really should have and had to do everything manually: when used well it’s fantastic. Now people can certainly go majorly overboard and do the super enterprise-y AbstractBoxedSomethingFactoryFacadeManagerImpl junk. And that is horrible. But simple dependency injection is a godsend. Ease of coding my just adding an ann…

Actually I really dont like DI and its a core of my dislike. I can easily create objects directly and pass in dependencies, its a lot easier to debug and see what is going on as opposed to Spring magic.

> Actually I really dont like DI and its a core of my dislike. I can easily create objects directly and pass in dependencies...

So you DO like DI, you just do it explicitly. Which is fine.

Re: Rating 26 years of Java changes

#240

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?

`cronService` is an injected instance of some class, probably provided by framework. My point is to demonstrate alternative, imperative way of defining cron tasks, as compared to declarative one.

A better name would probably be CronScheduler or something else. “Service” is always overused and doesn’t actually describe or mean anything.
Post reply on HN