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

131–140 of 327 posts

Re: Rating 26 years of Java changes

#131

Post by bdangubic »

taftster wrote: post #76
bdangubic wrote: post #46

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…

all trivial things you are listing, every single one…

Re: Rating 26 years of Java changes

#132

Post by bdangubic »

alex_smart wrote: post #85
bdangubic wrote: post #71

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?

You can write your own libraries? My goodness. What a question!

you write your own database driver? encryption?

Re: Rating 26 years of Java changes

#133

Post by Supermancho »

guax wrote: post #75
Supermancho wrote: post #39

Earlier quoted context omitted.

This is what it looks like to me. If you wanted to do this, why not use a scripting language where you can use this kind of practice everywhere? In Java, I don't expect to have to look up the return type of something to discover a variable type. Graciously, I can see how you can save rewriting the Type declaration when it's a function return you want to mutate. Generally, you save some keystrokes to let other people…

Modern IDEs will show you the type of anything at all times. I do not understand your point unless you're doing raw text editing of Java source. Those keystrokes are not just saved on writing, they make the whole code more legible and easier to mentally parse. When reading I don't care if the variable is a specific type, you're mostly looking whats being done to it, knowing the type becomes important later and, again…

> Modern IDEs will show you the type of anything at all times. I do not understand your point unless you're doing raw text editing of Java source.

The word "String" "Integer" et al. + "var" is too much real estate for being explicit. Sometimes, I'm looking at the decompiled source from some library that doesn't have a source package available.

> Those keystrokes are not just saved on writing, they make the whole code more legible and easier to mentally parse.

This is incorrect. Repeating it doesn't make it true. For trivial code (Changing practice because an author thinks a function is small enough when it was written, is a recipe for unclean code with no clear guidelines on what to use or expect. Maybe they rather put the onus on a future reader; this is also bad practice.

Re: Rating 26 years of Java changes

#134

Post by hashmash »

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

The first official JIT became available in JDK 1.1, in 1997. The Symantec JIT was available as an add-on sometime in mid 1996, just a few months after JDK 1.0 was released. Even better performance was possible with GCJ, available in 1998.

The release of HotSpot was in 1999, and became default with JDK 1.3 in 2000. It took JIT compilation to the next level, making tools like GCJ mostly obsolete.

Re: Rating 26 years of Java changes

#135

Post by halffullbrain »

rzwitserloot wrote: post #57
tormeh wrote: post #29

Earlier quoted context omitted.

It's seriously puzzling. I just don't get how it's possible to look at what so many others have done better, and somehow design something worse. For what reason? Consistency with the rest of the language, possibly? But is that really so important. Do they just not want to tackle certain parts of the compiler?

OpenJDK redesigns massive swaths of the compiler every other month. The true explanation, at least the way OpenJDK says it, is that designing language features is more complex than a casual glancer can fathom, and there's 30 years of "Java is in the top 5 most used languages on the planet, probably #1 especially if focussing on stuff that was meant to be supported for a long time" to think about. From personal experi…

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.

Re: Rating 26 years of Java changes

#136

Post by swuecho »

pixelmonkey wrote: post #93

A cool thing about Doug Lea's java.util.concurrent (received a 10/10 rating here) is that its design also inspired Python's concurrent.futures package. This is explicitly acknowledged in PEP 3148[1] (under "Rationale"), a PEP that dates back to 2009. [1]: https://peps.python.org/pep-3148/

That is why I think of java when using python's concurrent.future package.

Re: Rating 26 years of Java changes

#138

Post by foresterre »

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.

They're a bit verbose, the interfaces are slightly convoluted and some basic operations are missing from the standard library.

It's also a little convoluted to work with different types of data.

For this one, I wish they would have taken a bit more inspiration from other languages and spent the time to make it more readable.

That said, I generally like streams a lot, and they do reduce the amount of branching, and having less possible code execution points makes testing easier too.

Re: Rating 26 years of Java changes

#139

Post by MBCook »

halffullbrain wrote: post #135
rzwitserloot wrote: post #57

Earlier quoted context omitted.

OpenJDK redesigns massive swaths of the compiler every other month. The true explanation, at least the way OpenJDK says it, is that designing language features is more complex than a casual glancer can fathom, and there's 30 years of "Java is in the top 5 most used languages on the planet, probably #1 especially if focussing on stuff that was meant to be supported for a long time" to think about. From personal experi…

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.

Post reply on HN