
Records and Sealed Types – Coming Soon to a JVM Near You - pjmlp
https://www.infoq.com/presentations/java-language-records-sealed-types/
======
MrBuddyCasino
Too bad records won't have named arguments, this would really have helped for
large records. Kotlin is once again ahead both in time as in design.

~~~
pron
They don't now but they likely will. See "named invocation" here:
[https://cr.openjdk.java.net/~briangoetz/amber/datum.html](https://cr.openjdk.java.net/~briangoetz/amber/datum.html)

Kotlin is actually at a disadvantage when it comes to design. It has little to
no influence on the Java platform it targets and its ecosystem (or on the
Javascript platform and ecosystem it also targets), and so it is forced to
shape its designs to fit its environment, while the Java language can shape
the ecosystem and platform with its design. You see this pattern in records
vs. data classes, coroutines vs. Loom, and inline types in both languages.
Kotlin's solutions are always more complex and less harmonious in their
environment; they need more knobs and joints so that they could fit the
contours of the existing constructs around it, on which they have no power.
Don't get me wrong, it's doing fine with the cards it's got, but it's clear
that it does not have the freedoms of a "platform language."

~~~
MrBuddyCasino
> They don't now but they likely will. See "named invocation" here:
> [https://cr.openjdk.java.net/~briangoetz/a](https://cr.openjdk.java.net/~briangoetz/a)

This is good news!

> It has little to no influence on the Java platform it targets and its
> ecosystem

It certainly influenced the ecosystem by showing what is possible, and making
the shortcomings of Java even more obvious. It has replaced Java (and to some
degree, Scala) as the default backend language at some shops, because of less
boilerplate and null-safety, leading to better and more maintainable code. Its
running the apps on worlds biggest smartphone OS. It may not have pull over
the JVM‘s direction, but afaik that had not been a problem so far. Kotlin‘s
performance is on-par with Java.

~~~
pron
> It certainly influenced the ecosystem by showing what is possible

Not really. The new features are much similar to their ML (and Scala)
counterparts, and ML was well-known to Java's original designers. It is simply
a matter of priorities and familiarity. It is true that Kotlin made some ideas
more familiar to the point that Java was able to adopt them, and that is why
Java benefits from Kotlin existing as an option on the Java platform. The Java
language tries not to adopt a feature until it has been tried for a long-
enough time by a large-enough number of developers.

> It has replaced Java (and to some degree, Scala) as the default backend
> language at some shops

Yes, but to put it in perspective, its penetration on the Java platform is
around 2-5%, not higher than Scala's penetration ten years ago.

> leading to better and more maintainable code.

That is a hypothesis that some believe but does not seem to have any actual
empirical support.

> Kotlin‘s performance is on-par with Java.

Yes, and that is a big problem for Kotlin. Kotlin was created at a time of
stagnation for Java -- Sun's last years and the first years at Oracle -- and
when Android was still similar to Java. Those two platforms have now diverged
greatly, and will diverge even more, and it will be impossible to have a
language that is at once the same on those different platforms and aims not to
introduce performance overheads. Kotlin will either split into two languages
(like Java and Android's "Java"), focus on one platform, or introduce
performance overheads.

------
doctor_eval
Serious question: why are there accessor methods on records?

Record fields are final, so they can’t be modified. Records can’t be extended;
so the methods can’t be overridden, which means that the accessor methods
don’t protect the fields from change or allow for redefinition. Accessor
methods are not appropriately named for JavaBeans, so that’s not the reason
either.

AFAIK the accessor methods generated by the compiler are in all ways
functionally equivalent to simply accessing the fields directly.

But the accessor methods take up more space and add code to the class which
increases class size and could be avoided. It’s slightly more cumbersome to
use value() instead of just value. And, presumably, compilation takes slightly
longer as the compiler (hopefully?) elides the method call and... replaces it
with a direct field access.

There must be a benefit to all these costs, but what is it? what is their
purpose? why do they exist?

Serious question, I can’t work it out and it’s driving me nuts.

Edit: turns out I’m wrong, methods can be overridden, I misread an article. It
makes more sense now.

~~~
kasperni
There are things such as arrays that you cannot really make immutable as
things are at the moment. So you will have to override the accessor and
provide a copy of the array. If the components were fields you would not be
able to do this.

Also if you are designing APIs for others to use. You might in some situations
want to expose an interface instead of an actual record. As records are
difficult to evolve. So having methods are much easier than fields in those
situations. For example, the JDK itself mostly plans to use records behind
interfaces.

~~~
doctor_eval
It’s not clear that this is how records work though. I think only the top
level fields are final - I don’t think there’s an expectation that the array
contents would be immutable - and since you can’t redefine the methods, this
would have to be done by the compiler and I don’t think that’s the case.

Also, same problem happens with fields which are instances of classes;
although the record is mutable, the instances are not. So I don’t think that’s
the answer.

I also don’t think records can implement interfaces.

~~~
kasperni
Yes, you can override accessors and mutability is the main reason. It has been
discussed a number of times on the various amber mailing lists, here is one
[1].

Yes, records can implement interfaces. The syntax is {ClassModifier} record
TypeIdentifier [TypeParameters] RecordHeader [SuperInterfaces] RecordBody

[1] [https://mail.openjdk.java.net/pipermail/amber-spec-
experts/2...](https://mail.openjdk.java.net/pipermail/amber-spec-
experts/2019-March/001046.html)

~~~
doctor_eval
OK thanks. I misread an article as saying that records couldn’t be extended,
but on rereading, it actually said that java.lang.Record couldn’t be extended
other than by declaring a record. That makes a lot more sense, and certainly
explains the use of methods instead of fields. Thanks!

(I continue to dislike the syntax, FWIW)

------
rienbdj
It will be interesting to see how Java developers who argued against
functional programming will react to these features.

~~~
pron
The Java community has the population of a mid-sized country and is far from
homogenous on any axis, and so the 0.1% of Java developers who use it to, say,
write embedded control software [1] outnumber those who do it in Rust at least
100 to 1, and the 1% of professional Java developers who use monadic (ish)
composition for IO [2] outnumber those who use it in Haskell 50 to 1.

So there could be a million Java developers who'd like to see more functional
features, a million who'd like to see less, and then a group the size of, say,
the population of Ireland that doesn't really care (with a sampling error of
several Haskells).

[1]: [https://www.aicas.com/](https://www.aicas.com/)

[2]:
[https://docs.oracle.com/en/java/javase/14/docs/api/java.base...](https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/util/concurrent/CompletionStage.html)

~~~
BlargMcLarg
Unfortunately, many of us tend to run into the 99% of professional Java devs
still stuck in the old, almost meme-level culture of pre-Java 8, where:

* var is a sin (if the Java version is even high enough to utilize it)

* Methods frequently have 3 arguments by default * Getters and setters are nigh-on useless and verbose, existing primarily because one doesn't trust the coder next to him

* Names are atrociously long and laid out in a way auto-complete helps zilch (25+-char names are not uncommon even for local variables)

* Methodology is still primarily stuck in its old GoF OOP AbstractCreatorFactoryFactory ways

Java is doing good and making leaps to improve. I can't say the same for the
culture, which is mostly due to it attracting tons of people who have no
innate skill or desire to learn programming, mostly there to occupy a job that
pays decently well and make zero effort to improve. Or worse, it used to
attract those kinds of people, who now occupy senior/principal/lead positions
and enforce the old way of programming under the guise of "consistency"
(Consistency is important, but using it as an excuse to not adapt is simple
abuse). That attitude is a lot less prevalent in Haskell communities, where
the environment itself preselects for programmers with an innate interest.

~~~
hocuspocus
Sometimes I wonder where the blame truly lies. Is it complacent developers? Or
a decade of bad practices encouraged by big frameworks? Probably a bit of both
and now we have a vicious circle. Unfortunately, there's real demand for poor
software quality in our industry, for good and bad reasons.

I moved to Scala as my main language on the job because I wanted to make sure
I'd work with coworkers who are open to adapt and learn new things. But I
cannot deny the churn has a real cost if you aren't careful.

~~~
pron
I think the blame lies with those who fail to understand that you cannot
compare the "culture" of an ecosystem the size of a university with the
"culture" of an ecosystem the size of the country that contains it, and
several others like it. Go to a Java shop that does robot control, sensor
fusion, simulation, formal methods or spacecraft orbits, and I guarantee you
that you'll find coworkers that are open to adapt and learn new things, things
that are probably far more important, and interesting, than typeclasses and
lenses.

~~~
hocuspocus
Surely, but I'm not in these fields. And it's like screening and interviewing
candidates: I need to pick proxy metrics when I evaluate employers.

------
maxpert
So I have not used Java in production until recently. I was working with
languages like C#, Go, Python, Ruby, etc. and built significantly large
services in those (10 - 50 MAU). Coming back to Java 8 I was surprised that
language made little to no progress, and was significantly painful to use with
modern async eco-systems. I still had to review IDE vomit, and people were
happy doing so. This has changed recently but records/sealed types is one such
example of something that should have been done way back in time.
Unfortunately that has been not the case; project loom is still exploration
phases. I wonder how many people are bothered by this and moved on to
different platform/language due to these shortcomings.

