Live data from Hacker News

Rating 26 years of Java changes

neilmadden.blog

301–310 of 327 posts

Re: Rating 26 years of Java changes

#301

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…

You do know about environmental variables?

Re: Rating 26 years of Java changes

#302

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?

I have to deal with this at work for rolling db credentials, actuator refreshes are fine for this purpose.

Would be nicer if we could handle creds like it wasn't 1992, but this does the job too.

Re: Rating 26 years of Java changes

#303

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.

Like Shedlock?

Re: Rating 26 years of Java changes

#304

Earlier quoted context omitted.

The use case for modules is to have a unit of organizing code (deciding what is visible and accessible to who) at a higher level of abstraction than a package. It allows library authors to be much more explicit about what is the public API of their library. Ever wrote "List" in Intellij and instead of importing "java.util.List" Intellij prompts you to choose between like twenty different options from all the librarie…

Yes, but at what cost? Many libraries can solve visibility problem with package level visibility. And modules cost a lot: dependency management was a non-goal for them, so anyone who wants to use module path instead of classpath, has to declare dependencies twice. It was a big mistake not to integrate modules with a de facto standard of Maven.

> Many libraries can solve visibility problem with package level visibility

The only way of doing this would be to put all classes in the same package. Any nontrivial library would have hundreds of classes. How is that a practical solution?

Re: Rating 26 years of Java changes

#305

I haven't written much Java but I am learning Kotlin and I really appreciate the language and the whole JVM ecosystem. Yeah yeah, Gradle is complicated but it's waaaaay easier to figure out than my adventures with Cmake, and when I read Java code there is a certain comfort I feel that I don't get with other languages, even ones I'm experienced with like Go. Java feels a bit like a stranger I've known my whole life, s…

Maven was peak Java build tool. I detest Gradle. Some people just hate XML enough to doom us all.

Can't speak for everyone, but I think a substantial part of the shift from Maven to Gradle was the ability to write build scripts: you didn't need to write a plugin. I'm hoping that Maven (and Gradle) can take advantage of JEPs 458 and 512 to allow people to write build scripts for that Java projects in Java.

- https://openjdk.org/jeps/458

- https://openjdk.org/jeps/512

Re: Rating 26 years of Java changes

#306

Earlier quoted context omitted.

> you did start this with writing your own I really did not. I only said that if you were to create your own cronService, you can reuse it by creating your library rather than copy pasting code (which is obviously insane). > which is about as insane as writing your own database driver No, it is not. Spring Boot’s support for async jobs and scheduled jobs is lacking. A lot of people roll their own. Including yours tru…

Spring Boot’s support for async jobs and scheduled jobs is lacking. Can you elaborate? What exactly is lacking and what version of Spring are you using?!

Compare with the functionality offered by async job systems of other full stack frameworks - eg django with celery and rails with solid-queue. It’s not even close.

I am on the latest version of Spring Boot.

Re: Rating 26 years of Java changes

#307

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…

You've never used parallel streams? They're my favorite way to do parallel computation in Java, and very easy if you've structured your problem around streams.

Code with parallel streams wouldn't even pass my review. The server processes multiple requests simultaneously. It makes no sense to smash all cores in one request. It'll cause bad latency for other requests and will not increase throughput.

There might be use-cases, but I've yet to encounter them.

And when I need parallel computation, I can just use good old ExecutorService. Few more lines, but that's OK for a task that arises once in a 10 years.

Re: Rating 26 years of Java changes

#308
post #279

Earlier quoted context omitted.

> The same way, caller can know which exceptions are really likely to happen in TypeScript, C++, Python. Or in modern Java which avoids checked exceptions anyway. By reading documentation or source code. That's perfectly fine and works for everyone. This provides no automatic verification that indeed all likely error situation that can and should be handled were indeed handled. The very idea is that you have to opt i…

> This provides no automatic verification that indeed all likely error situation that can and should be handled were indeed handled. And some people write code in Python which provides no automatic verification whatsoever. Actually unchecked exceptions are very similar to dynamically typed languages. And that's fine. As Python and other languages proved by their mere existence: dynamic typing is not inherently bad. S…

> And some people write code in Python which provides no automatic verification whatsoever.

Python is a language with almost no static validation whatsoever. It would be very odd if it cared about checked exceptions. This dynamism makes big Python code bases infuriating to work with.

> When we're talking about IO Exceptions, it's almost always failed operation which requires complete abort. It's either failed hardware, or, typically, disconnected client. Can't do much about it, other than clean up and proceed to the next client.

If this is the case then the solution is to add it to the `throws` list.

> That's not exactly true. In JVM, NullPointerException is absolutely well defined and you can continue execution after catching it.

Why would I catch a NullPointerException instead of fixing my application? The JVM is indeed completely fine, but processing still cannot continue because that code simply does not exist.

Re: Rating 26 years of Java changes

#309
post #204

Earlier quoted context omitted.

Spring has a special error handling strategy where the whole request is allowed to fail, punting error handling off to the caller. A lot of code that throws checked exceptions is simply dangerous to use with Java streams because the execution order of stream operation is not obvious and possibly non-deterministic. For this reason, streams were never intended to also handle errors. Reactive frameworks are much better…

> A lot of code that throws checked exceptions is simply dangerous to use with Java streams because the execution order of stream operation is not obvious and possibly non-deterministic. From the type system PoV, they could have just written something like `interface Runnable { void run() throws X; }` and now `forEach` would have been written like ` void forEach(Runnable r) throws X`. And repeat that for all stream o…

At the risk of repeating myself: streams were simply never designed with error handling in mind. Aborting everything at the first error is just the most simplistic error handling strategy. Reactive streams frameworks should be preferred for this.

Re: Rating 26 years of Java changes

#310
post #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)), ()…

I don't grumble about Java much, I make my living with it and enjoy it. But Optional is a bane.

We use NullAway and I just never use Optional unless it really, really makes sense.

Post reply on HN