New language features since Java 8 to 17

https://advancedweb.hu/new-language-features-since-java-8-to-17/

345 276 5 years ago

cageface3• 5 years ago

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.

Waterluvian• 5 years ago

I don’t follow why this is unfortunate?

CuriousCosmic• 5 years ago

A lot of people have migrated away from Java to better JVM languages. If Java actually keeps improving, there's a reasonable likelihood that people will stop migrating and those that have may come back to Java from these other langs.

Long term this could lead to a loss of maintenance for tools and libraries for these languages which could kill them and leave those that migrated with a dead & decaying ecosystem.

Of course this is a bit of a stretch but it's not unheard of.

tablespoon• 5 years ago

I don’t follow why this is unfortunate?

I'm guessing Java hate, which is kind of fashionable. If Java evolves to stay relevant, it won't be usurped and fade away.

atomicnumber32• 5 years ago

I assume OP prefers Kotlin or Scala.

Personally, I think one of my favorite things about Java is that, all things considered, it's a small-ish language. So I'm glad that Java is both willing to evolve (slowly, letting other people try stuff out first) but also clearly focused on a curated feature set and resistant to letting new stuff in to bloat it. I am very happy to deal with minor things like no multiline string support if it means we get to avoid being a terrible mess of language features that ruby, scala, python, etc have accrued in a relatively quicker timescale.

I was fairly sad around the java 6-7 days where we went quite a long time with no visibly major new language features (diamond inference was 7's big thing, lol). So it is nice that we're moving a bit faster than that, now.

cageface3• 5 years ago

What I don't want to see happen is innovation stop in JVM languages and then Java, no longer under threat, also stops innovating.

jmfldn6• 5 years ago

This is great not unfortunate. If Java improves because of Scala and Kotlin then so much the better, this is how languages evolve. If it really does evolve to remove the need for a better Java then it would be nice if people switched away from Kotlin and back to it. Scala can then carry on cementing its niche as a powerful commercial FP language. No hate for Kotlin at all but it seems like in that world, there might be no need for it. Scala is better for FP and if Java 17 is the better Java then great.

cutler• 5 years ago

Android will always be Kotlin-first. That's a pretty huge market.

jpgvm5• 5 years ago

To be honest I see Kotlin continuing to exist because of it's multi-platform nature and it's focus being on different things to Java.

So even if feature wise the 2 equalize (a good thing not a bad thing IMO) stylistic differences will remain. Many of Kotlins syntactic differences are unlikely to make it to Java for instance.

I'm ok with this. I use both for different things. Kotlin for most app level development, Kotlin for libraries that are only useful in the context of Kotlin, Java for everything else so it has minimal dependencies and can be used from Kotlin/Scala/Java/Clojure equally well.

Smaug123• 5 years ago

I think one could argue exactly the same thing for the same reasons about C# vs F# on .NET, which is my area of expertise - but honestly I'm not so sure it's true. C# has grown into an enormous language as it tries (consciously or not) to subsume F#, and F# is always going to remain so much cleaner just because you aren't having to ignore 90% of the language features when you code in it.

throw868788• 5 years ago

Agree with this. What's more interesting is on the feature level languages do borrow/converge on each other in order to try to secure a position in the market. I note that as an example Java is consdering a .NET like Span feature (https://openjdk.java.net/jeps/412) as an example probably to close the gap w.r.t performance. There are others.

What matters more in all honesty, and what's hard to change IMO is:

- The base of the language (is it verbose, how the base features interact with each other) vs being "tacked on". A language with these features initially. e.g. you mention F# and I know it uses HM type inference, immutability by null, makes null hard to express by default, etc.

- Anything that breaks backwards compatibility (e.g. Java's generic implementation) for example including existing API's. Adding Async afterwards takes time, and changing the underlying model of the language (e.g. Python's GIL, OcAML multithreading) takes time and needs a lot more consideration. Its code, anything can change, its just harder and maybe easier to take something that was designed for that case initially. Being a polygot isn't a bad thing per se I think if it can be justified tech wise.

pjmlp14• 5 years ago

Except without Java they are meaningless.

5e92cb50239222b• 5 years ago

This happens all the time with "guest" languages. A few old salts have been prophesying this right here on HN since Kotlin first came out. I think it'll still be used on Android though, it's hard to see Google pushing Android development back to Java.

mavelikara• 5 years ago

Java's implementation of generics was heavily influenced by a language called Pizza. Sun hired the author of the language, Martin Odersky, to write the compiler for Java. Odersky later went on to develop Scala.

Java improving borrowing ideas from other JVM languages had happened in the past, and that has made the ecosystem stronger. Nothing unfortunate about it.

66fm472tjy72• 5 years ago

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 collections instead of having to .stream().map(..).collect(toList())

bestinterest• 5 years ago

Is that true though? nullability is a area I've heard /u/pron mention may be tackled in the future, mutable records seem like they will be tackled with the 'withers' concept in the future. Checked exceptions + changing the sugar of .stream().map I don't see ever changing. Properties I am unsure of.

krzyk• 5 years ago

He does not refuse, but needs to look at bigger picture.

Some features are low hanging fruit, some are proposed small changes that actually should be defined a bit differently to be better and they will take more effort.

But even small hanging fruits means that they need to chose which ones to do. Should they delay pattern matching by 6 months to get elvis operator? I wouldn't like it, pattern matching is more important.

Basically they have limited resources and have to chose what to work on.

pron13• 5 years ago

Thank god for that, because those feature are either horrible on their own or superseded by better ones. You're getting a car and complaining for not getting faster horses. The features Java has adopted -- specifically, algebraic data types and pattern-matching -- will lead to better development practices, rather than making it easier to work with inferior ones.

oftenwrong• 5 years ago

Stream has been given a `toList()` convenience method:

https://docs.oracle.com/en/java/javase/17/docs/api/java.base...()

nikeee• 5 years ago

IMHO safe navigation only makes sense when the compiler is able to reason about nullability, meaning nullability is rooted in the type system. That's the case for Kotlin and not for Java.

Otherwise, you've got a high risk of developers inserting a ? to fix a bug, which only fixes the symptoms.

As of now, Optional#map seems to be the way to go.

throwaway2037• 5 years ago

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?

hocuspocus3• 5 years ago

Scala is fine. People understood it's not really worth it as a "better Java". Companies that choose Scala in 2021 are using either big data frameworks (where Python bindings are the most common alternative to Scala, not Java), or functional ecosystems (Typelevel, Zio). Scala 3 has taken an interesting direction and to me it seems that Odersky wants to win Python developers over rather than Java shops using Spring.

New features in Java and the JVM (records, loom, valhalla, ...) are directly going to benefit Scala and make it even better.

On the contrary, Kotlin's essence has always been threatened by the fact it's nothing more than a better Java. I assume there's still a big demand for that on Android, but if you're running on a recent JVM, I would certainly consider Java over Kotlin.

tunesmith2• 5 years ago

Which is a bummer for folks that loves the cleanliness and power of "basic Scala" (pure functions, immutability) without wanting to get into deep FP theory (typelevel, zio). That has been a really nice pocket to be in for teams that have the discipline to not get clever with it. Same with teams wanting to integrate with Akka on scala.

zorr• 5 years ago

Kotlin started out as a better Java but it's more than that now. With Kotlin multiplatform you can compile to JVM, Javascript and Native from the same repository.

Java has been catching up on language features but I'm not sure if I'm ready to switch back to Java for Spring projects yet. Mostly because of nullability, extension methods and coroutines in Kotlin.

hota_mazi5• 5 years ago

Interestingly, I have the exact opposite opinion.

Scala has been declining steadily for a decade now, and Scala 3 is going to precipitate this state of affairs by splitting the shrinking community even further.

Kotlin, on the other hand, has done nothing but grow for the past five years, no doubt helped by Google's formidable support for it. I just took a quick look at one of its Slack channels, "getting-started", and it has over 38,000 people on it. And that's just one channel among dozens more.

I don't think Java's latest additions are anywhere near threatening Kotlin's rise to dominance since Java is moving at a very slow pace, by design, while Kotlin supports some features and design directions that will never happen in Java.

leroman• 5 years ago

Scala still has a better design at its base, which is missing from Java and I don’t see how Java can retro-fit it into the language, Immutability is a big part of being functional and doing safe multi-threading stuff, java is doing all the good syntactic stuff (case class, switches with guards etc) but without immutability it’s a far cry from the same facility in Scala land. Having said that, this trend is welcome for every time I have to write Java and makes it feel more natural to me as an old time Scala developer.

kaba017• 5 years ago

With records, Java does try to embrace immutability to a certain degree, but of course it will never be completely immutable.

jayd162• 5 years ago

Kotlin is still run by the company that makes the best Java ide, no? I don't expect kotlin to get pushed out so easily.

pron13• 5 years ago

The cause and effect are quite right, though. The reason Kotlin was designed in 2009-2010 was because Java became stagnant, not by choice, but due to Sun's demise. After the acquisition and an adjustment period, Oracle gradually increased investment, and the evolution pace got back to it's "normal" course. So Java's "revival" and Kotlin's existence are, indeed, related, but one did not cause the other; rather, they both have a common cause.

whyenot• 5 years ago

I don't see it as unfortunate. It shows that Java is a living language that continues to improve and change to match the needs of its users. Compare this to Common Lisp, which has not change in any meaningful way since 1984.

A lisp-er would probably say that CL is so malleable that it hasn't needed to change, but I'm not so sure about that.

armchairhacker• 5 years ago

Kotlin is still way ahead of Java with IMO essential features like:

- Explicit null

- Extension methods

- Getters/setters which use property syntax

- == instead of Object.equals confusion

Also Kotlin's this-scoping and delegated properties, while they take a while to get used to, can be incredibly useful. They make it possible for to write typesafe DSLs like kotlin-html.

Moreover, Kotlin is usually very easy to integrate with existing Java projects. Setting up Kotlin in Gradle is just adding a plugin, and Kotlin automatically imports and exports java code. And it runs on the JVM so it will support most platforms that also support Java. And one of the top Java IDEs and contributors (JetBrains) maintains and prioritizes Kotlin.

dmitryminkovsky• 5 years ago

I just want to add that while this is a really nice post in its own right, I found this blog because its author created this: https://github.com/dodie/vim-fibo-indent

popotamonga• 5 years ago

Still no property literals

irl_chad• 5 years ago

We must have a “new features since Java 8” post every other day.

pjmlp14• 5 years ago

Because plenty of people judge Java by their pre-Java 8 frozen knowledge.

At least it isn't yet another link to re-written in Rust headlines.

junon• 5 years ago

I must be in the minority of thinking java 7 was the last great version of Java. What I see today is a nearly different language.

rdpintqogeogsaa• 5 years ago

I've been bitten by bitwise operations on signed integers a few too many times. Are there any plans on having normal unsigned integer types yet?

recursive2• 5 years ago

Other than sign-extension on right shift, I can't think of a bitwise operator that has a different implementation between signed/unsigned. What scenarios are you thinking of?

xxs10• 5 years ago

reading and processing bytes mostly. Many people get confused due to the need of bitwise and, yet even if that would be removed I can't quite see the intrinsic benefits, given how difficult would be having another primitive type.

rzzzt• 5 years ago

Java has both >> and >>> operators for sign-extending and zero-extending right shift, respectively.

sorokod• 5 years ago

They are present in Kotlin

https://kotlinlang.org/docs/basic-types.html#unsigned-intege...

chrisseaton3• 5 years ago

Java already has everything you need for unsigned integers doesn't it? You just use the normal int type, and then use methods like Integer#compareUnsigned instead of language operators.

da_chicken• 5 years ago

This reads like, "VisualBasic already has everything you need for pointers. You can define your own classes and pass by reference."

5faulker• 5 years ago

Same here. Can be downright confusing sometimes.

xxs10• 5 years ago

What exactly do you have in mind. Using '&0xff' is annoying but well whatever. Perhaps 23y ago, applying the bitwise and would be a novelty but now it's a minor inconvenience.

The way java is built in internally I can quite see another primitive type popping up.

hashmash• 5 years ago

I was griping about Java's lack of unsigned types for over 20 years until it dawned on me why mixing signed and unsigned types together in the same language is a bad idea. Consider when one method returns an unsigned type, but another one accepts a signed type. Signed and unsigned types cannot be safely casted to each other without loss of information, and that causes bigger issues.

The only times the lack of unsigned types causes issues is when doing low-level binary encoding, and most programmers steer clear of that anyhow. I think it's a good tradeoff to make things simpler for most, but a bit more difficult for few.

jatone2• 5 years ago

wait until you learn about signed bytes.

sushsjsuauahab2• 5 years ago

Missing var in java 9?

teh_klev2• 5 years ago

Introduced in Java 10:

https://advancedweb.hu/new-language-features-since-java-8-to...

sushsjsuauahab2• 5 years ago

Wow, my memory failed me! I could have sworn it was 9.

nooorofe• 5 years ago

https://advancedweb.hu/new-language-features-since-java-8-to...

Available since: JDK 11 (Without lambda support in JDK 10)

TOC is missed up, there is no java-10 at all.

tomcam• 5 years ago

Fantastic article for a language-curious person who doesn’t know Java well.

JulianMorrison5• 5 years ago

It's good to see Java starting to waive a lot of the boilerplate. (And frustrating, when stuck on v8.)

xxs10• 5 years ago

A friendly advice: dont be afraid to use public final immutable fields and omit the getters (and setters since you cant have them w/ finals).

vips7L• 5 years ago

Probably should just use records and get all that for free.

JulianMorrison5• 5 years ago

I do. It bothers me this wasn't the Java Way from day one. What is with getters and setters - who subclasses and substitutes the implementation of their data carrier objects?

manishsharan• 5 years ago

Whenever we read about new improvement in Java,it is always inevitably followed by concerns for viability of Kotlin or Scala. However these concerns are never applicable for Closure. I am glad I went all in on Clojure.

e40• 5 years ago

Can you explain that for the Java noobs here, like me?

nikanj• 5 years ago

Scala and Kotlin tried to be a better Java (i.e. Algol-esque syntax). Clojure tries to be a better Lisp, an entirely different family of language.

Though a good flamewar can be had on 1) Is Scala closer to Pascal 2) Is Pascal Algol-descendant

dunefox4• 5 years ago

Clojure has many functional features and properties that are unique to Lisps and functional languages and aren't shared by Java. Kotlin and Java are much more similar than either to Lisp, so when Java gets more modern features it might cut into Kotlins 'market share' since it makes it less powerful when compared to Java.

sgt• 5 years ago

Yeah I think most Java devs are a bit in awe of Clojure, just not sure about the leap needed to get there.

hota_mazi5• 5 years ago

Anyone who values static typing will never be in awe of Clojure. Or any dynamically typed language, for that matter.

And Java developers care a lot about static typing.

Thaxll• 5 years ago

Isn't closure on its way out though, not like Perl level but going downhill? Kotlin on the other hand is raising.

The_Colonel2• 5 years ago

It's not applicable, because Clojure already lost the momentum and sinks deeper and deeper into its niche.

fulafel2• 5 years ago

I don't think Clojure was ever growing at a huge clip, but it seems to be doing about the same as Scala, see eg the pie at https://snyk.io/blog/kotlin-overtakes-scala-and-clojure-to-b...

Kotlin is just Java with improvements and it has major corporate push from Google, so it's natural for it to ride the big volumes.

I think long term Clojure is going to keep doing well, despite modest pie slice of JVM dev, because lots of people continue to prefer its simplicity + dynamic FP + unique approach to data, plus the excellent ClojureScript side, and it doesn't really have competition or alternatives on the JVM (unlike Scala, where Kotlin/Java are co-opting features).

pjmlp14• 5 years ago

Most of which unavailable on Android Java flavour, sorry Google's J++.

hn_throwaway_99• 5 years ago

If you're on Android I'd be programming in Kotlin in any case.

pjmlp14• 5 years ago

I rather do Android Java and C++ in what concerns my use cases.

https://developer.android.com/games/agdk

evacchi2• 5 years ago

Shameless plug: I recently wrote a blog post on Java 17's new features using the implementation of a tiny actor runtime as the running example. If you are interested you can find it here https://evacchi.github.io/java/records/jbang/2021/10/12/lear...

mabbo• 5 years ago

Is there a reason for that?

I'd really love to get into android development, but I'm loathe to give up some of the nicer language features in Java. What version of Java is android supporting? At least 8, right?

hota_mazi5• 5 years ago

Java's supported version on Android is a moot point: all new Android development should be made in Kotlin.

pjmlp14• 5 years ago

Many got sold on the idea that they adopted OpenJDK, but that is quite far from the truth, so in reality they cherry pick the features and standard library classes/methods that are somehow relevant to port key Java libraries into Android.

Currently they support a Java 11 subset.

You can track them on AOSP Gerrit commits.

Apparently starting with Android 12 , ART can be updated via Play Store and they should provide better updates.

Although there is also the question how they were naive to think Java would never require updates, or possibly related to the Oracle dispute, which anyway proves the point that they behave just like Microsoft did with J++.

bobthedino• 5 years ago

I also recently found this site, which for example can show you an API diff between Java 8 and 17: https://javaalmanac.io/jdk/17/apidiff/8/

didip• 5 years ago

To be honest, what I really need is a list of backward incompatible changes and a list of projects that can shim those incompatible changes.

Just like Javascript.

InsaneOstrich• 5 years ago

There are very, very few backward incompatible changes in Java

r0f1• 5 years ago

Is there something similar for Python? They are releasing new Python standards with a crazy fast speed. Would be really helpful for me.

moffkalast3• 5 years ago

It would sure be helpful if they took some effort to focus less on adding crazy new stuff every 2 days and instead on maintaining older versions for a change.

Maintaining a python dependant system these days is an absolute nightmare, at least with C++ you know that new compilers will be backwards compatible, gah.

afandian• 5 years ago

How does this feel with Python being dynamic? I always felt very uneasy writing Python precisely because if some random module became incompatible, especially via a transitive depndency, I might not find out until it was running in production.

bradbeattie• 5 years ago

https://docs.python.org/3/whatsnew/index.html, each subpage of which has summary highlights.

bobbyi• 5 years ago

I imagine there's a reason it's necessary, but it's weird that "sealed" is basically "final" with the ability to do "permits" instead of just adding "permits" as a keyword that can be put on "final" classes

Twisol8• 5 years ago

I suspect it has something to do with classfile format backwards compatibility. From a pure syntax standpoint, I would agree with you, but there's probably some value to making a very clear separation for classfile loading.

pharmakom3• 5 years ago

Glad to see Java improve, but I still would like to see more ML features:

- ~Exhaustive pattern matching~ it’s here!

- Algebraic data types

- Tail call optimisation

- Do notation

- Operator overload

Why not use another language? Well, the name “Java” guarantees buy-in at this point. Maybe it will eventually be a Trojan horse for ML :)

cyberbanjo• 5 years ago

What would do notation add to Java?

pharmakom3• 5 years ago

There are lots of places where it can help, but to give one example consider the Java 8 Optional type.

It’s great for avoiding nulls, but you get excessive nesting with many isPresent checks. Do notation can fix this.

The language even provides a bind function, but no reasonable way to use it!

emptysea• 5 years ago

Not the parent, but presumably it would allow for fancy monad stuff like Scala's Cats Effects[0] and Zio[1] which can make async programming easier to follow without having to introduce async/await

[0] https://typelevel.org/cats-effect/ [1]: https://zio.dev

mhh__2• 5 years ago

Not specifically for Java but I have found myself wanting do-notation in non-functional languages so that I can basically write a very expressive library while also forcing users of that library to go down my road i.e. I hacked around it in the end as I didn't have a do-like abstraction but I had (in-effect, it wasn't quite a DSL) written a DSL that represented certain constructs just fine using operator overloading, but you can't overload control flow. Therefore building the notions I wanted to in code was very painful without some kind of (equivalent notion to) do-notation.

karmakaze2• 5 years ago

The unfortunate stance on ADTs is that Java doesn't want them generalized. The standard answer is use Records and Sealed classes.

What does this mean? Well with generics we can have two libraries that know about Map<> and concrete types TypeA and TypeB and can interface type-safely using Map<TypeA, TypeB>.

What we can't do is have two libraries that know about TypeA and TypeB interface type-safely using a sealed type of TypeA and TypeB. Even without considering libraries, another use we may want to talk about a sealed type of TypeA and TypeC, but of course TypeA can only be in one of the sealed class trees.

The worst part is that Java already has a Union type that's only ever used in multi catch(ExceptionA|ExceptionB e).

karmakaze2• 5 years ago

I've been thinking about the lack of ad-hoc SumTypes in Java. The sealed class approximation isn't good enough. I'm seriously considering taking up TypeScript in earnest as my 'go to' language. It's an outlier in supporting A | B | C and being mainstream with pretty good runtime performance.

One thing I'd have to check is the quality of IDE support for refactoring tooling. Refactoring operations for Java using IntelliJ almost always works and as I expect or better.

Twisol8• 5 years ago

For myself, I'd like to see use-site variance replaced with declaration-site variance. It's really painful sometimes to have type arguments within generics more than one level deep; you have to start adding `? extends` (usually; or `? super` occasionally) at all the intermediate levels.

I somewhat suspect Java is locked into its current approach to variance, but gosh, I much prefer Scala's approach here.

temporallobe2• 5 years ago

I’m stuck on 8 and 11 in my current projects, so I haven’t seen much of these in the field other than the new record feature. What I am really surprised about is the var construct. Honestly, this leaves me a little conflicted since it 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? I would perhaps argue against it being dynamically-typed since by definition type inference happens at runtime, but it certainly leaves Java in a sort of limbo. I don’t personally care, but I know at some point the topic will come up amongst my dev peers, at which point there will sure to be a (mostly friendly) debate.

dunefox4• 5 years ago

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.

abraxas2• 5 years ago

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.

temporallobe2• 5 years ago

Java is not usually considered to be a statically-typed language and I was not implying that it was. And the definition of dynamic typing is somewhat vague to me, although allowing unspecified type inference is somewhat dynamic, even though one cannot reassign the variable to a different type at a later point.

And my point about was that Java was designed to be verbose, except that now “var” breaks this verboseness. I am sure there was plenty debate on this topic already, but I thought it would be interesting to reason about how this changes the character and perception of Java.

kaba017• 5 years ago

It’s just “simple” type inference.

As for what style is preferred: yeah I have also seen plenty of not so friendly debate on it, but I think it is fairly simple (and we do have “prior art”, with Scala Haskell, etc): in case the type is trivial, use var. Like new SomeLongAssClassName is a perfect candidate for var as having the typename twice doesn’t constitute any additional information. I would wager that with good method names, it can also be used for things like `obj.getLocation()`, where we happen to have a Location class as well. The other use case is when we just don’t care about the type, either because it is very complex with low info density (like a Map with a nested generic value type, which is easy to recognize from context and variable names), or because it is trivial (like I like to use things like var i = 2)

filoeleven9• 5 years ago

The “keep readability in mind” tip exposes more Java/OOP icebergs.

  var date = LocalDate.parse("2019-08-13");
  var dayOfWeek = date.getDayOfWeek();
  var dayOfMonth = date.getDayOfMonth();

> The first one is pretty intuitive, the parse method returns a LocalDate object. However, for the next two, you should be a little bit more familiar with the API: dayOfWeek returns a java.time.DayOfWeek, while dayOfMonth simply returns an int.

Java.time.dayOfWeek takes a TextStyle and a Locale, both of which have a list of properties and methods I have to read all about before using. dayOfMonth returns an int, and I can see if it’s 0- or 1-indexed then do what I want with it from there. Why does DayOfWeek have a class instead of being a function that I can throw a number at like dayOfMonth?

I’m also skeptical about Java.LocalDate being “pretty intuitive,” having worked on local vs server vs data-store timestamps, as most of us have. At least LocalDate doesn’t have mutable setter methods like other Java dates…

xxs10• 5 years ago

Why does DayOfWeek have a class instead...

B/c in most of the world, the 1st day of the week is Monday, unlike the US where it happens to be Sunday. Having it enum is a pretty decent choice.

filoeleven9• 5 years ago

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 should be the responsibility of a library. Maybe even the standard library, but it should not mask the core data values in the system by default.

dayOfWeek(n) should be something that you apply to a value, not something that returns a value with no args based on your locale. Or, if it does, the function itself should accept an override locale instead of assuming it from a higher level.

Timestamps are hard and maybe not the best example. It was what’s in the article though, and I’m also pretty salty about them after some recent work stuff.

ohgodplsno• 5 years ago

Because dates are actually complicated, and so is the real world. You may be content in having just an int to display Sun 24-10-2021 to your users, but there are needs to get the actual weekday. From locale differences (US has the start of week on Sunday, most of the world on Monday), to locale differences (Country X nuked 43 days on year Y, your basic algorithm doesn't handle that because it's not working with tz-data, and it's broken now), to locale differences (how do you plan on displaying it? Short form? Translated?), to infinitely more date fuckeries that _have_ to be handled if you want your Date API to be credible.

filoeleven9• 5 years ago

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 display that you need out of it. Your example with Country X means that dayOfWeek() AND dayOfMonth() are already both broken unless/until the language itself makes an emergency update to account for the change.

With dayOfMonth() I could substitute another function that handles the change. With dayOfWeek() I’d have to override the whole class, if possible.

I have seen this in action. A company I worked for was stuck with using outdated time libraries in Java because of IBM WebSphere (1.7? 1.8?). Those didn’t match the more recent libraries in Javascript (moment.js) and the differences caused significant problems, since the same locale keys had different time offsets.

alkonaut• 5 years ago

Does java have a decent story on value types now e.g can I make an ArrayList<long> and trust that it’s one array of longs on the heap and not an array of pointers to Longs? This was what made me ragequit Java 10 years ago.

bradleyjg3• 5 years ago

No. You can’t make an ArrayList<long> at all. You can make an ArrayList<Long> and trust the JVM to optimize as it may or you can use c++.

kjeetgill2• 5 years ago

You can mostly trust the JVM to not optimize this the way you'd want for primitives. ValueTypes are int he works though, and using a supplementary library for primitive specialization like Trove or fastutil have become the norm for now. Not ideal, but tolerable!

Twisol8• 5 years ago

Not yet. You can track Project Valhalla [0], the incubator for value/inline types in OpenJDK. But I don't get the sense it's landing particularly soon.

https://openjdk.java.net/projects/valhalla/

Skinney5• 5 years ago

Really? They’ve already written the JEPs. It seems to me that they just have a few more details to iron out. Wouldn’t be surprised to see something land for Java 19.

silvestrov• 5 years ago

The FastUtil library is very good for this: https://fastutil.di.unimi.it

p2t2p• 5 years ago

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 think that they know better than me what I need.

Groxx3• 5 years ago

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.

Ericson23142• 5 years ago

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

lmm2• 5 years ago

Don't think of it as a less powerful class, think of it as a more powerful enum. At least that's how it's meant to be used. It's a good feature in other languages, and like you said, "final" already exists, so you're no worse off on that front.

Jweb_Guru• 5 years ago

Without sealed classes it's impossible to enforce most interesting invariants. If anything the other way is a mistake.

shagie• 5 years ago

Reasonable arguments can be made that sealed classes should be the default.

From https://news.ycombinator.com/item?id=16952659 (and all the related links to that comment and the original article - The Impoliteness of Overriding Methods)

int_19h3• 5 years ago

IMO sealing for classes is unnecessary, so long as methods are opt-in for overriding (e.g. as in C++ or C#, where you need to explicitly say "virtual"). If you can't override anything in a derived class, how can you break invariants?

AlphaSite• 5 years ago

Sealed classes are better enums, akin to swifts, etc and are built to allow pattern matching and error reporting on missed cases.

xxs10• 5 years ago

PowerMock is a mistake on its right own; I outright reject pull requests if anyone attempts writing unit tests that need modification of final state.

goto11• 5 years ago

You shouldn't need to mock a sealed class in the first place. Consider them like a more powerful enum or an algebraic data type.

You wouldn't mock en enum either (hopefully).

pulse7• 5 years ago

I've seen projects where the whole architecture/design was screwed just because someone wanted to mock >>everything<< during unit testing...

titzer• 5 years ago

I used to really love Java, it was my second "real" programming language after C/C++, and GC, type safety, and object orientation really changed the way I thought. I also learned almost all I knew about high-performance VMs (up to 2013) in the context of JVMs.

But these days it seems like Java is engaged in one long apology for the "everything is an object" mindset it started out with. It both took it too far and not far enough. Erased generics were the start of the problem. Parametric types! You were the chosen one! You were supposed to unify the primitive types and the object types! And never adding syntax for function types, just single-method interfaces...just ugly and clunky IMHO.

C# did generics right. Well, almost. "void" isn't a real type, so you can't be generic over it.

It is really important in language design that generics can range over any type. It allows the full combinatorial space. I worked really hard to make the Virgil compiler support arbitrary combinations of tuples, arrays, function types, and all of those work together seemlessly in the polymorphic type system. Everything else is a unfortunate shortcut, IMHO.

akra• 5 years ago

Its not universal to all of .NET though.

F# does support this (e.g. Task<unit>) because in F# every function has only one input and one output. Therefore it needs a unit/void type at the lang level at least. This simplification surprisingly results in more power and less code compared to C#. Its part of the base design of the language, and an example of something that is hard to change afterwards in future versions.

In F# overloads for different amounts of type args to a function are not common, unlike C# with different types for each Func<T1, T2, T3, ... TResult> or Java with both Supplier and Function types and needing a custom function type for more args last time I checked. A use case that has come up for me would be to dispatch on variadic template args (e.g. loggers) in a typesafe way without reflection penalty, or looking at some of the libraries using overloads that could be reduced (especially in conjunction with inline for the value type overloads I suspect such as found in LINQ). When I see libraries with overloads for parameters like 'Func<T1,T2,T3,T4,T5,T6,T7,T8,T9,T10,TResult>' I think of this. Wherever you see multiple overloads in C#/Java just for the sake of multiple generic arguments; that can often be simplified if required/worth it.

Skinney5• 5 years ago

Parametric types and the unification of primitive and reference types is the goal of project valhala.

New language features since Java 8 to 17

Related Stories