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

281–290 of 327 posts

Re: Rating 26 years of Java changes

#281

Post by bdangubic »

alex_smart wrote: post #266
bdangubic wrote: post #232

Earlier quoted context omitted.

* 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.

> 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?!

Re: Rating 26 years of Java changes

#282

Post by bdangubic »

didntcheck wrote: post #166
skeletal88 wrote: post #60

Earlier quoted context omitted.

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

Absolutely! But Quartz is also quite heavy. If all you need is to ensure scheduled jobs run in a clustered environment there are more “lighweight” options

Re: Rating 26 years of Java changes

#283

Post by gbear605 »

samus wrote: post #218
gbear605 wrote: post #174

Earlier quoted context omitted.

The only problem with them is that they don’t work well with lambdas (and related features like Stream). If you need to call a method that throws a checked exception inside of a Stream, there’s no good way to pass it up other than re-throwing it as unchecked or some other hack (like collecting all the thrown exceptions in a separate loop). A different implementation of lambdas that allow for generic exceptions would…

When you use lambdas you lose control over when and how often your code gets executed. Since checked exceptions are very often thrown by code that has side effects, I'd consider the friction to be a feature. > collecting all the thrown exceptions in a separate loop It's really not comfortable to do so in Java since there is no standard `Either` type, but this is also doable with a custom collector.

> Since checked exceptions are very often thrown by code that has side effects, I'd consider the friction to be a feature.

This is true, but I think that it’s partly true because checked exceptions are cumbersome here. In my ideal world, the majority of functions would throw exceptions, testing cases that today are either missed or thrown as unchecked exceptions.

Re: Rating 26 years of Java changes

#284

Post by skribanto »

hdpe wrote: 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)), ()…

Well, it can make some chained function composition easier.

  Ick1 result1 = potentiallyNull1();
  Ick2 result2 = (result1 == null) ? null : potentiallyNull2(result1);
  Ick3 result3 = (result2 == null) ? null : potentiallyNull3(result2);
vs

  Ick3 result3 = potentiallyNone1()
    .flatMap(potentiallyNone2)
    .flatMap(potentiallyNone3);
You could maybe move the null check inside the method in the former and it cleans it up a bit, but in the latter you can have methods that are explicitly marked as taking NonNull in their type signature which is nice.

Re: Rating 26 years of Java changes

#285

Post by laughing_man »

hashmash wrote: post #112
alex_smart wrote: post #98

Earlier quoted context omitted.

Why so much hate for modules? They seem to be almost universally disliked by everyone on this thread and I don't understand why.

Directly or indirectly many (or most) projects ended up depending on something which was using an unsupported backdoor API because it provided a marginally useful capability. The module system restricted access to these APIs and everything stopped working, unless you added some magic command line arguments to gain access again. So for most people, the initial impression of modules is negative, and then they just deci…

Early on there were things you couldn't do without using com.sun.* classes, so people got used to doing that. It's been many years since that was all fixed, though.

Re: Rating 26 years of Java changes

#286

Post by laughing_man »

travisgriggs wrote: post #84

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 Ja…

In the early days javascript wasn't far enough along that you could make a web app without a lot of compromises, and the cross-platform nature of java was a big, big plus. I worked on an internal java client application that was developed on Linux for end users on PC. Ten years after we released the first version, and while it was still under development, a group of powerful managers at our company demanded they be issued Macs instead of the PC corporate standard.

When IT asked us if our application worked on Mac, we shrugged and said "We don't have a Mac to test it. We've never run it on a Mac. We won't support it officially, so if there are Mac specific bugs you're on your own. But... it should work. Try it."

And it did work. All the Mac users had to do was click on our Webstart link just like the PC users. It installed itself properly and ran properly. Never had a single issue related to the OS. Before Java was introduced that was an unobtainable dream in a full-featured windowed application.

Re: Rating 26 years of Java changes

#287

Post by vbezhenar »

samus wrote: post #279
vbezhenar wrote: post #224

Earlier quoted context omitted.

> Checked exceptions are for errors that are not possible to prevent. How else should the caller know which exceptions are really likely to happen? 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. And you highlighted one…

> 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. Sometimes it's good. I think that for error handling, it's good.

> Java class loaders can do anything including loading resources from the network. Which is admittedly not that common these days after the demise of applets.

Technically they can, but in my particular case I know very well, that my resources are residing inside of JAR file. And if that JAR file happened to reside on the failed HDD block, that's not going to be a recoverable error.

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.

And the same could be said about SQL Exceptions. Like 99% of SQL exceptions are application bugs which are not going to be handled in any way other than wind up and return high level HTTP 500 error or something like that. There are cases when SQL exception should be handled, but those are rare. Yet JDBC developers decided that programmers must execute error handling rituals on every call site.

> The NullPointerException indicates a bug in the application. By the very reason it occurs, the current thread cannot continue execution normally.

That's not exactly true. In JVM, NullPointerException is absolutely well defined and you can continue execution after catching it. You might suspect, that logical application state is corrupted, but sometimes you know well that everything's fine (and in most cases you hope that everything's fine, if your Spring MVC handler threw NPE, Spring is not going to crash, it'll continue to serve requests). It's not C++ with its undefined stuff. JVM is pretty reliable when it comes to every error, including NPE, stack overflow or OOM. Latter is special, because even handling error might prove challenging, when memory allocations fail, but JVM will not hang up or crash.

Re: Rating 26 years of Java changes

#288

Post by cesarb »

laughing_man wrote: post #285
hashmash wrote: post #112

Earlier quoted context omitted.

Directly or indirectly many (or most) projects ended up depending on something which was using an unsupported backdoor API because it provided a marginally useful capability. The module system restricted access to these APIs and everything stopped working, unless you added some magic command line arguments to gain access again. So for most people, the initial impression of modules is negative, and then they just deci…

Early on there were things you couldn't do without using com.sun.* classes, so people got used to doing that. It's been many years since that was all fixed, though.

> It's been many years since that was all fixed, though.

AFAIK, there's still no replacement for sun.misc.Signal and sun.misc.SignalHandler, so I think "that was all fixed" is false.

Re: Rating 26 years of Java changes

#289

Post by ivan_gammel »

alex_smart wrote: post #206
ivan_gammel wrote: post #105

Earlier quoted context omitted.

Modules are weird. In Java world there exists consensus on dependency management via Maven-style repositories (Maven Central is the primary distribution channel) and all tools support it. You handle your dependency tree outside of your code and just import packages from libraries available on classpath. It’s possible to continue doing that that without using modules, so the case for using them is still unclear to man…

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.

Re: Rating 26 years of Java changes

#290

Post by cesarb »

tombert wrote: post #40

Interesting; I actually have grown pretty fond of NIO. I will acknowledge that the interface is a bit weird, but I feel like despite that it has consistently been a "Just Works" tool for me. I get decent performance, the API is well documented, and since so many of my coworkers have historically been bad at it and used regular Java IO, it has felt like a superpower for me since it makes it comparatively easy to write…

There's one thing I deeply dislike with Java NIO: ClosedByInterruptException. If a thread is interrupted (for instance, due to a future.cancel(true) or similar), and it happens to be in the middle of a NIO operation, the channel will be closed, even if it's not owned by that thread. That single thing makes using NIO far more brittle than the older Java IO.
Post reply on HN