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

211–220 of 327 posts

Re: Rating 26 years of Java changes

#211

Post by lenkite »

dkarl wrote: post #107
vbezhenar wrote: post #45

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're absolutely right about checked exceptions. However, I think they're an exception (forgive me) from the pattern of Java mostly sticking to the strategy of, we can build a practical, industrial, reasonably performant language that has all these nice bits from other languages: garbage collection, portable bytecode, no pointer arithmetic, collections in the standard library, etc. I think streams are a great exampl…

Totally Hard disagree on streams - I used parallel streams in my last Job nearly all the time. They are critical for cpu-intensive tasks involving large datasets. And they do involve just a single code change in the consuming code. Sequential to parallel processing can be done via one `.parallel`.

I always believed it was a major plus point for Java compared to other languages. I am even surprised to hear otherwise. How should parallel processing of streams work in your opinion, then ? Just saying it be unsupported would be laughable considering hardware today.

I would rate this feature 9/10. The fact that the author has rated it 1/10, shows he hasn't really worked on large, parallel processing of data - in Java anyways.

Re: Rating 26 years of Java changes

#212

Post by lenkite »

_ea1k wrote: post #170
2muchcoffeeman wrote: post #116

Earlier quoted context omitted.

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.

Please use the facilities of the framework for debugging any lifecycle issues. I was surprised when I found out that people did not use `--debug` for example or enabled logging of application startup events.

If you prefer GUI, Intellij even has a Spring Debugger: https://www.jetbrains.com/help/idea/spring-debugger.html

Re: Rating 26 years of Java changes

#213

Post by lenkite »

Sorry, but several of these ratings are just plain wrong. I am not even a Java developer these days, but it is extremely clear that author did not work in a domain that rightfully leveraged the Java features he rates as of little use.

He would have been better served by opening a poll - that would have opened his eyes to the use of these features.

Its like giving operator overload a rating of 1 in C++/Python. Sure, if you don't find any need for it in your domain, it would look stupid to you.

Re: Rating 26 years of Java changes

#214

Post by nmadden »

nine_k wrote: post #68
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…

Absolutely. It seems that the author never touched Spring, for instance, or a dependency-injection framework of any kind. Annotations allow to do things in a completely different way, removing tons of boilerplate. I'd give annotations 9/10 at least. (And I lost the interest in the rest of the article, given such a level of familiarity with the subject matter.)

Do you really think that in 26 years of professional Java programming I’d have never touched Spring? I’ve been using Spring since it was first released. I’ve found CVEs in Spring (https://spring.io/security/cve-2020-5408). Trust me when I say that my dislike for Spring (and annotations) is not based on ignorance.

Re: Rating 26 years of Java changes

#215

Post by ayewo »

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…

To add to this, modules make it easy for external tools like GraalVM native-image to produce self-contained binaries that are smaller compared to the standard practice of distributing fat binaries (i.e. large JARs).

Re: Rating 26 years of Java changes

#216

Post by nmadden »

alex_smart wrote: post #208
sothatsit wrote: post #129

Earlier quoted context omitted.

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?

Yes, in theory they are good. In practice they cause enormous amounts of pain and work for library maintainers with little benefit to them (often only downsides). So, many libraries don’t support them and they are very hard to adopt incrementally. I tried to convert a library I maintain to be a module and it was weeks of work which I then gave up and reverted. As one library author said to me “JPMS is for the JDK itself, ignore it in user code”.

Given how much of a coach and horses modules drove through backwards compatibility it also kind of gives the lie to the idea that that explains why so many other language features are so poorly designed.

Re: Rating 26 years of Java changes

#217

Post by as1mov »

rr808 wrote: post #87

Java is great, Spring ruined the platform.

Spring and the associated enterprise spaghetti developers have done more damage to the platform rather than the language itself. I've managed to work for almost a decade with Java without using Spring at this point (and count myself lucky for it), but the chances of finding a new job with the same requirement are slimmer and slimmer now.

Re: Rating 26 years of Java changes

#218

Post by samus »

gbear605 wrote: post #174
bigstrat2003 wrote: post #164

Earlier quoted context omitted.

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.

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.

Re: Rating 26 years of Java changes

#219

Post by samus »

nunobrito wrote: post #97
harladsinsteden wrote: post #8

I don't know what to make of this list... Very strange reasoning and even stranger results: Streams 1/10?! Lambdas (maybe the biggest enhancement ever) a mere 4/10?! Sorry, but this is just bogus.

I'm that author. It has been more than a decade and still won't use streams nor lambdas. Makes the code too difficult to write and debug for me. Really prefer to have more lines of code and understanding very clearly what each one is doing, than convoluting too many instructions on a single line.

I bet you don't like how it looks when you put huge code blocks inside a lambda. Me neither. But that's an issue with coding style; it forces you to extract processing code into a method. I'd argue the opposite way - imperative syntax constructs make spaghetti code too easy to work with.
Post reply on HN