New language features since Java 8 to 17

[cageface]

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.

[p2t2p]

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.

[Jweb_Guru]

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

[Groxx]

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.

[goto11]

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

[xxs]

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.

[lmm]

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.

[pulse7]

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

[AlphaSite]

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

[pharmakom]

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 :)

[bobthedino]

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/

[dmitryminkovsky]

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

[bobbyi]

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

[alkonaut]

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.

[Twisol]

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/

[bradleyjg]

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

[silvestrov]

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

[titzer]

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.

[manishsharan]

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.

[The_Colonel]

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

[Thaxll]

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

[sgt]

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

[rdpintqogeogsaa]

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?

[tomcam]

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

[pjmlp]

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

[r0f1]

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

[bradbeattie]

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

[moffkalast]

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.

[JulianMorrison]

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

[filoeleven]

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…

[temporallobe]

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.

[sushsjsuauahab]

Missing var in java 9?

[nooorofe]

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.

[teh_klev]

Introduced in Java 10:

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

[didip]

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]

There are very, very few backward incompatible changes in Java

[dang]

Please don't take HN threads on boring generic tangents (by making grand shallow claims), and especially please don't take HN threads into tedious programming language flamewar.

Also, you broke the site guideline asking people not to go on about downvotes in the comments. Would you mind reviewing https://news.ycombinator.com/newsguidelines.html and sticking to them in the future? We'd be grateful.

[brundolf]

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

[grishka]

Being verbose is a plus. I really really really hate the terseness of Kotlin and how it's basically unreadable without an IDE.

Languages should be dumb. Standard libraries should be smart. Not the other way around. The number of syntax constructs that generate standard library calls when compiled should be minimized as much as possible.

Edit: one more thing, operator overloading is extremely harmful for readability.

[ksec]

>if the point is to teach OO.

Is it really the point to teach OO though?

Java is being used everywhere. And you get to learn the basic as well as the huge ecosystem behind it. Apart from possibly Python, are there any language that get you both in terms of market and learning?

And Java have make huge improvement in every part of the ecosystem, from languages, standard library, VMs. While I still dont like the language much, but I have gotten off the so called busy and verbose code view as I age. As they do serve some purpose. We need better balance, right now languages design are binary and polarised options.

[dukeyukey]

I agree with everything here except the "should stop being taught as the defacto language in computer science curriculums". Realitically, a CS curriculum needs to at least vaguely prep a student for life in the industry, and Java is not only massively popular, but is also a great way of showing how OO is used in practice i.e. kinda badly. No point teaching everyone about beautifully architected Smalltalk programs just to have them work on hacky Java monoliths from 2003 (not to mention BusinessObjectTpyeFactoryGenerator.java).

[vletal]

There is still a huge market demand for Java. Moreover the recent releases are doing a great job adding features following recent trends. If thought using JDK 16+ a student will be able to move to Kotlin, Swift, Scala, ... much more easily than few years ago. IMO it's more about updating the curricula than dropping Java.

[imheretolearn]

Could you please support your statement with reasons?

[lordnacho]

Java sucking could be a good reason to teach it, no? It's instructive to know what bad choices have been made. Much like your first job, it can be unfortunate to work in a place where everything functions properly, because you won't know what makes it work.

Java is also a good base for looking at other JVM languages, and for looking at the JVM itself. That's gotta be part of a good curriculum too, doesn't it?

[leetcrew]

strictly from a pedagogical perspective, sure, there are better choices. but java is at least decent for most of the core cs curriculum, and it's widely used in industry. when you're trying to get your first internship with no work experience, it's nice to be familiar with the language you'll be using at work.

[ptstomp]

Regardless of OO 'quality' of a language, if you consider that most university degrees are an avenue to successful employment then it's easily one of the best ones to learn due to the current market alone.

[popotamonga]

Still no property literals