Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New language features since Java 8 to 17

advancedweb.hu

Post reply on HN
Print view View original

221–230 of 358 posts

Re: New language features since Java 8 to 17

#221

Post by filoeleven »

xxs wrote: post #218
jcelerier wrote: post #198

Earlier quoted context omitted.

> Once you know that “Java says X is the first day of the week,” The basic assumption when designing anything is that you can never rely on assuming that other humans "will" know.

A funny part is that java has java.util.Calendar that has setFirstDayOfWeek(int), the default depends on the locale used to create the Calendar. It's considered a bad design overall, esp with SUNDAY const being 1. For most of the world that (sun=1) made absolutely no sense at all and assumed one of those weird things like jokes about IQ and room temperature.

> java.util.Calendar that has setFirstDayOfWeek(int), the default depends on the locale used to create the Calendar

That is exactly the kind of hidden assumption that I’m trying to fight against! If the date and the locale were both passed in as parameters, preferably just plain data, this would be a transparent function. Instead, you have to find and read through the documentation to see what kind of mischief is going on. And you have to do that every time you encounter a Java.until.Calendar.

Edit to clarify: if “locale” is some class, you have to learn that class DSL to examine it, and depend on a runtime debugger that does the same. If “locale” is just a hash map, you can examine the values without a lot of faff.

Re: New language features since Java 8 to 17

#222

Post by Groxx »

p2t2p wrote: post #212

Am I the only one who's seeing "sealed" classes as an unfortunate development? I can't count how many times I had to resolve to using PowerMock and hacking bytecode just to mock something in one of the libraries I use because it's ingenious author "final"-ed the whole API surface of the library (and bits of the implementation usually). Now this gives even greater tool to people who love to lock everything up and thin…

Yeah - personally I think languages should allow a lot of constraints like sealed classes (it makes your intent clear, and can allow extra optimizations, that's good!), but highly-risky "escape hatches" need to exist because they solve real problems.

"Fork and modify" is a very capable alternative, but it's far, far, far more costly than "monkey-patch this one time issue that'll be fixed next week". And some languages make it extremely painful to achieve, often requiring significant code rewriting, and which sometimes make contributing back to the source-library significantly harder. And when such hacks hang around longer for a week... well, sometimes that's fine, sometimes it's not, and the library author is not the one who should be making that decision. It's my program, it should do what I tell it to do.

Re: New language features since Java 8 to 17

#223

Post by kjeetgill »

Athas wrote: post #164
brundolf wrote: post #98

Earlier quoted context omitted.

Counterpoint: it's become a fairly multi-paradigm language at this point, and a multi-paradigm language is exactly what should be the defacto language in curriculums Whether or not Java is the best one for this purpose is up for debate, but I think it's no longer a bad one

> Counterpoint: it's become a fairly multi-paradigm language at this point, and a multi-paradigm language is exactly what should be the defacto language in curriculums I'm surprised you would say this, as it is the exact opposite of my experience as university teacher. I think we should teach concepts , and concepts appear much more crisply in small and focused languages. I think students gain more from being exposed…

I've never taught, so naturally I'd defer to you on such matters but I feel completely the opposite. I suppose it depends on what year students you're teaching too but for me, elements of functional programming first clicked for me in Python precisely because I could compare how to solve the same problems in the same language so differently.

I didn't get as lost in the incidental differences between languages like how do I print or import function, etc. but just how I might implement just one part of my program more functionally, how it'd help me reason better about that chunk.

I suppose it shows that I rep Java and Python all day, the champions of compromise, jack-of-all-trades languages.

Re: New language features since Java 8 to 17

#224

Post by Ericson2314 »

Groxx wrote: post #222
p2t2p wrote: post #212

Am I the only one who's seeing "sealed" classes as an unfortunate development? I can't count how many times I had to resolve to using PowerMock and hacking bytecode just to mock something in one of the libraries I use because it's ingenious author "final"-ed the whole API surface of the library (and bits of the implementation usually). Now this gives even greater tool to people who love to lock everything up and thin…

Yeah - personally I think languages should allow a lot of constraints like sealed classes (it makes your intent clear, and can allow extra optimizations, that's good!), but highly-risky "escape hatches" need to exist because they solve real problems . "Fork and modify" is a very capable alternative, but it's far, far, far more costly than "monkey-patch this one time issue that'll be fixed next week". And some languag…

A sealed class ought to have no methods, so it is plain old data. Then there's no purpose to overriding it.

Re: New language features since Java 8 to 17

#225

Post by kjeetgill »

weatherlight wrote: post #119
grishka wrote: post #108

Earlier quoted context omitted.

Global scope is a terrible invention. The less implicitness there is, the better.

then write assembly.

What? Barring the stack, everything's essentially global in assembly. Like you can touch your process whole address space from anywhere!

Re: New language features since Java 8 to 17

#226

Post by filoeleven »

jcelerier wrote: post #198
filoeleven wrote: post #184

Earlier quoted context omitted.

Sure, someone’s got to make a numbering choice somewhere for the canonical value. Same thing goes for timestamps, and we settled on UTC, so all offsets can be calculated given that. Once you know that “Java says X is the first day of the week,” you can make your own calculations from it with modulo arithmetic. There is no need for a class here, or for it to build a whole subsystem of locale interpretations. That shou…

> Once you know that “Java says X is the first day of the week,” The basic assumption when designing anything is that you can never rely on assuming that other humans "will" know.

Sure, but how far does that go?

If I try to assign an int value to “3.2” will the language silently fail with null, or a round, or a floor, or a ceiling? Some level of understanding is necessary. I want it to also be reasonably explicit.

Java time library doesn’t meet that standard until Instant.

Re: New language features since Java 8 to 17

#227

Post by Groxx »

Ericson2314 wrote: post #224
Groxx wrote: post #222

Earlier quoted context omitted.

Yeah - personally I think languages should allow a lot of constraints like sealed classes (it makes your intent clear, and can allow extra optimizations, that's good!), but highly-risky "escape hatches" need to exist because they solve real problems . "Fork and modify" is a very capable alternative, but it's far, far, far more costly than "monkey-patch this one time issue that'll be fixed next week". And some languag…

A sealed class ought to have no methods, so it is plain old data. Then there's no purpose to overriding it.

I think you're thinking of `record` classes? Sealed classes are about constraining inheriting or implementing to only approved types - using sealed is pointless without overriding of some kind. Unlike in some other languages, where sealed is closer to java's final classes, i.e. stopping inheritance.

Re: New language features since Java 8 to 17

#228

Post by matt2000 »

abraxas wrote: post #214
dunefox wrote: post #175

Earlier quoted context omitted.

> seems to be antithetical to the principles of a strongly-typed language. So does this now reclassify Java as a weakly- or dynamically-typed language? Var and type inference are neither antithetical to static typing nor do they make a language dynamically typed. They're antithetical to the verboseness of Java.

Except that having the type info is really, really useful at the call site. I know the IDE is able to infer it and display it but it's still a pain to see all the vars during a code review in a browser.

Agree, it's a straight up reduction in code readability for all future maintainers so a single original developer can avoid doing a thing their IDE probably would do for them automatically. (I use "introduce variable" to create most variables automatically of the correct type).

Yes I know the IDE can also reveal what type a var is, but you generally read code in lots of places that aren't IDE enabled.

It also adds more work for the compiler. I'm not sure the effect on Java compile types yet but Kotlin and Swift have both suffered from slow compile times and this seems to be a factor.

I'm guessing that most of the larger codebases out there will add "no var allowed" to their style guides within the next few years.

Re: New language features since Java 8 to 17

#229

Post by filoeleven »

riwsky wrote: post #200
filoeleven wrote: post #196

Earlier quoted context omitted.

Yeah. See my reply to your sibling comment: timestamps suck and it was maybe a foolhardy example that I’m not competent enough to defend. Here goes me trying to make my case anyway! =) My big assumption is that if a system cares about global timestamps, it should go all the way. If you have a “canonical system timestamp,” which I think is necessary, then you can operate on it functionally to get whatever local displa…

Why are you blaming a class called “LocalDate” for not giving you global timestamps? The java doc for the class has an entire paragraph on how it is not a time. If you want to model a specific instant in time, use Instant.

This is a fair criticism. Java Instant should be the standard, and anything that doesn’t use it as its base should be deprecated. I have to support older JDKs, so I don’t know. The article starts with Java 9, and Instant was included with 8, so it is not a fault of the article.

Re: New language features since Java 8 to 17

#230

Post by throwaway2037 »

66fm472tjy7 wrote: post #59
cageface wrote: post #2

Unfortunately it looks like Java is going to evolve enough to take the wind out of the sails of Kotlin and Scala for most dev shops. I guess the positive take is that those improvements might not have happened without the efforts to develop better JVM languages.

I don't think this is going to happen with Brian Goetz as language architect. He refuses to add many features that would address everyday pain points such as: * null safe navigation operator * properties * mutable records * a way to ignore checked exceptions (or at least having the stream API take functional interfaces that can throw exceptions) * adding functional methods like .filter()/.map() directly to collection…

Re: Properties: What is the gain? What is the "pain point"? More typing? Can you share a language where you feel properties is a significant gain? (C#?)

Re: Streams API that allows checked exceptions. Brian Goetz has written about this issue. (Search StackOverflow.com) They did not allow because of the optionally parallel (threaded) nature of streams. If multiple parallel streams throw an exception, when/when/where/how are the exceptions re-thrown? Moving exceptions across thread boundaries is a tricky thing in any language. If you don't care about parallel streams, there are many open source projects that effective create a nearly identical Streams API but allow throws Exception everywhere. Are these open source solutions insufficient for your needs?

Re: adding functional methods like... Is there an advantage other than typing nine less characters?

Post reply on HN