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

201–210 of 327 posts

Re: Rating 26 years of Java changes

#201

Post by vips7L »

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. Checked errors are so important for correctness. HN’s darling Rust exclusively uses checked errors.

Re: Rating 26 years of Java changes

#202

Post by alex_smart »

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.

What if I told you - you can use a batteries-included framework, and still write your own libraries specifically only for things you want your own version of and want to share across projects?

The problem isn't that I don't know how to use a batteries included framework. The problem is that you guys don't know there is even an option to reuse your code by writing libraries.

Re: Rating 26 years of Java changes

#203

Post by SerCe »

executesorder66 wrote: post #190
SerCe wrote: post #149

My read is that it's easy to be quite negative on Java features when you're not the person they were designed for. For example, the main "customer" of the module system is the JDK itself. The main customer of NIO/2 is the low-level libraries like Netty. I highly recommend the Growing the Java Language talk by Brian Goetz to anyone who's interested in the philosophy behind evolving the modern Java language [1]. And Do…

>For example, the main "customer" of the module system is the JDK itself As mentioned in TFA, "The general advice seems to be that modules are (should be) an internal detail of the JRE and best ignored in application code" So yeah, why expose it to those who are not the "main customer"?

> So yeah, why expose it to those who are not the "main customer"?

How did modules affect you as a user? I'd guess that you had to add `--add-opens`/`--add-exports` during one of the JDK migrations at some point. And the reason you had to do it was that various libraries on your classpath used JDK internal APIs. So modules provided encapsulation and gave you an escape hatch for when you still have to use those libraries. How else would you do it while still achieving the desired goal?

Re: Rating 26 years of Java changes

#204

Post by samus »

vbezhenar wrote: post #88
JavierFlores09 wrote: post #77

Earlier quoted context omitted.

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/wat…

They are absolutely failed concept in Java. Every first popular library uses unchecked exceptions, including famous Spring. Java streams API does not support checked exceptions. Even Java standard library nowadays includes "UncheckedIOException". Kotlin, Scala: both languages grown from JVM and do not support checked exceptions.

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 at that.

The UncheckedIOException is for situations where you really cannot throw a checked exceptions, such as inside an iterator. Which might lead to ugly surprises for the API user;

Re: Rating 26 years of Java changes

#205

Post by alex_smart »

blackoil wrote: post #199
bdangubic wrote: post #132

Earlier quoted context omitted.

you write your own database driver? encryption?

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 with this attitude without blinking an eye.

Re: Rating 26 years of Java changes

#206

Post by alex_smart »

ivan_gammel wrote: post #105
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.

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 libraries you have included in your classpath that have implemented a public class named "List"? Most likely 90% of the libraries did not even want to expose their internal "List" class to the world like that but they got leaked into your classpath just because java didn't have a way to limit visibility of classes beyond packages.

Re: Rating 26 years of Java changes

#207

Post by alex_smart »

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…

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

Is it even theoretically possible for a project like this to not run into these kind of issues? Like literally the project's goal is to enable library authors to be more explicit about their public API. So breaking use cases that use unsupported backdoor APIs very much seems like a predictable and expected result?

Re: Rating 26 years of Java changes

#208

Post by alex_smart »

sothatsit wrote: post #129
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.

They are only useful for a small group of people, and their addition broke/complicated lots of people's builds in non-trivial ways.

I have a company with ~20 developers only. And already I have an ArchUnit test stating that public classes within "com.companyname.module.somepackage.internal" cannot be used anywhere outside "com.companyname.module.somepackage".

Surely almost everyone who has worked in a large enough codebase and thought about large-scale modularity can see the use case for a unit of abstraction in java higher than a package?

Re: Rating 26 years of Java changes

#209

Post by winternewt »

linuxhansl wrote: post #67

Didn't Java 1.3 (Sun's JDK) introduce the JIT? I remember talking to colleagues about what a joke Java performance was (we were working in C++ then). And then with Java 1.3 that started to change. (Today, even though I still C++, C, along with Java, I'll challenge anyone who claims that Java is slower then C++.)

Maybe not slower once it has warmed up, though for memory-bandwidth bound use cases I would still say the lack of mutable records has you fighting the language to get reasonable cache locality (and everybody will hate your code for not being good Java). The fact that everything is a pointer kills the CPU execution pipeline and cache.

But even for I/O bound applications it still feels slow because excessive memory usage means more swap thrashing (slowing down your entire OS), and startup time suffers greatly from having to fire up VM + loading classes and waiting for the JIT to warm up.

I can start a C/C++/Rust based web server in under a second. The corresponding server in Java takes 10 seconds, or minutes once I have added more features.

Post reply on HN