JEP Draft – Derived Record Creation (Preview)
bugs.openjdk.org
bugs.openjdk.org
I am very excited for this feature and has been a long time coming. This will make immutable transformation code much easier to write and reason about.
That said, I'm a little uneasy with the idea that we don't even have the option to write out our deconstruction pattern. That feels like a foot gun. I know that records come pre-baked with a deconstructor, I'm not asking to be able to choose. I am more asking for the ability to see the variable that I am overwriting. And I am not asking that every Java developer should have to shoulder that burden -- keep it implicit for those who want it. But I feel uneasy that I don't even have the option to write out the variables in my deconstructor.
I will try it out before taking issue with it, but these are my initial, uninformed feelings from looking at it. Regardless, even if my fears become true, this feature is well worth it, and I'm very happy to have it!
That does raise a good point -- If this concept might one day go over to the every day class, it sounds like they might be forced to list the deconstruction pattern used to do "reconstruction".
Either way, my main point is that -- the implicitness of this feature is appreciated, but I don't know if I want to be forced between implicit or just not using this feature, since my uninformed gut feels like I would appreciate the explicit clarity of seeing the variables I am working with. It might feel like a step back, but again, this is my opinion before having a chance to try this thing.
Scala is also on the edge of turning into Coffee Script, its relevance wanning.
20 years is pushing it, by the way.
Java is doing quite well on the Java Virtual Machine, it isn't going anywhere for not adopting every feature from Beanshell, Groovy, jTcl, jython, Frege, Ruby, Scala, Kotlin, and whatever else comes that needs to implement on top of Java to exist in first place.
It is like using Web and avoiding JavaScript, or UNIX and avoiding C/C++.
Sure it is possible to pretend it isn't there, until one needs to do serious stuff that requires understanding the platform and its ecosystem.
By the way, once upon a time Spring was also all hot on Groovy, then it was Scala, now it is Kotlin.
There is a certain irony complaining about Java programming language features and them going into Go, the epitome of programming language design.
It also hinders adoption of new features as people will prefer to maintain consistency in their codebases.
Stuff like Lombok are persona non grata when coding in Java, other than when imposed on us via 3rd parties without alternatives.
The alternative is to write this code by hand which isn't any better.
Yes, because records are still slowly being improved, it means that people will put together workarounds and temporary solutions so that they can get their desired feature as soon as possible. It also means that some will just throw up their hands in frustration and say "It's half-baked!", then disregard the feature entirely. It's a tradeoff that the Java team considers on a regular basis.
It was a similar tradeoff that led to them releasing Virtual Threads before they had a solution implemented for the pinning problem. That one wasn't so much that they needed feedback before they could fix the problem, but moreso that they didn't want to miss out on potential feedback while they were fixing the pinning problem. So, they released VT with this (temporary) deficiency, and they are working on it now while gathering as much insight as possible into how VT's are being used across the ecosystem.
Tradeoffs like this are painful, but they make for a better language. Not to mention, for faster long term progress. A well designed feature becomes easy to extend. A poorly designed one is easy to extend initially, but becomes far more difficult in the long run.
Don't think like Java is a good example of that, more like the anti-example. Plenty of more sophisticated languages move way faster without negative effects on long term progress (C#, Kotlin, to some extent Scala)
> A well designed feature becomes easy to extend. A poorly designed one is easy to extend initially, but becomes far more difficult in the long run.
Most of Java problems come down to unfortunate design choices in the past. E.g. checked exceptions vs lambdas
Also moving fast and breaking things newly adopted .NET culture is the reason I am mostly stuck on .NET Framework for corporate production apps, unless we're doing newly written microservices, and some big names like Sitecore decided it was easier to buy products written in other languages than rewrite their stuff into .NET Core.
Just an idea - maybe you can use CodeQL?
The transition to .NET core is indeed rather painful but it's just Microsoft's choice. Things were dropped/backwards compatibility broken mostly to simplify runtime but I saw nothing that couldn't have been emulated with some modest effort.
Also they could've easily softened the transition by continuing development of .NET Standard a bit longer and allowing side by side hosting of 4.x and Core in same process as that seemed to be the plan in the beginning. I guess they don't care.
.NET Standard existed and still exists as a bridge for .NET Framework and "odd" platforms like UWP (effectively dead), Unity and maybe a couple of others - you never know! Fortunately it slowly but surely fades into obscurity as all the actively developed platforms are converging around pure 'net6+'-based TFMs.
Special note regarding "being stuck with .NET Framework" - this may be true for some enterprise scenarios but I have grown to adopt a mental model of considering opinions like these as nonsensical or deeply out of touch with reality as much more useful way of dealing with audience that still lives in this camp. It is not worth entertaining, nor it is reasonable to respond to "move fast and break things" criticism after all these years - some people just have a bone to pick, for the pace is "moderate" and there are no changes made like in the early days of .NET Core 1.x and 2.x when the platform's fate was uncertain.
Or how about C# Source Generators that were introduced just few years ago and are stuck on .NET Standard 2.0 because of Visual Studio using .NET framework?
There is a lot of actively developed software out there either built in .NET or using it to provide extensibility that is now stuck as you can't add support for .NET Core without breaking all existing plugins.
The only alternative is complete redesign with out-of-process architecture which is not going to be compatible and might be inappropriate in some scenarios.
Funnily enough, your example has actually supported my point.
They just released a proposal that effectively side-steps the problem of checked-exceptions-in-lambdas. Here is a link -- https://inside.java/2023/12/15/switch-case-effect/
This is still just a proposal, so nothing is hammered out. And we can talk about the merits of this solution. But my point is, by focusing on designing features the way they have, you can minimize intrusion while maximizing the value provided. I think this proposal demonstrates that extremely well.
This proposal allows the developer to maintain all the good parts about checked exceptions and lambdas, while being able to side-step the major downside.
> Don't think like Java is a good example of that, more like the anti-example. Plenty of more sophisticated languages move way faster without negative effects on long term progress (C#, Kotlin, to some extent Scala)
To be clear, when I say long term, I am measuring on the scale of decades. In that respect, I actually don't think your statement is correct.
To give an example with Kotlin, someone (I think Brian) talked about Kotlin's release strategy for features being great for short term, but costly in the long term. Kotlin had record-esque classes long before Java ever got theirs, but now that Java finally has theirs, Kotlin is using an annotation to disambiguate between Java style records and Kotlin style records -- https://kotlinlang.org/docs/jvm-records.html#declare-records.... While this isn't some critical problem on its own, this type of rift growing wider means that Kotlin is going to have to wrestle with how much they want to allow Java representation of concepts to exist in Kotlin. For example, how will Kotlin handle Java's version of pattern-matching vs their own? The 2 are not the same, so you cannot just call them aliases of each other - they have different semantics.
To give another example with C#, there has been a lot of recent discussion about finding potential alternatives to their async-await concurrency model. They cite the level of effort it takes to maintain the async await style code and the costs that come from this. Rust had a similar conversation not too long ago too.
The point I am trying to say is that, I think Java's strategy of play it slow and conservative is actually paying off for them, but on the scale of decades. Some of the languages it gets compared too aren't even that old yet.
This is fine but removes only about 10% of the pain of mandatory exception handling inside typical lambda.
Nothing short of making exceptions transparent to lambda receivers will cut it for me.
> Kotlin is using an annotation to disambiguate between Java style records and Kotlin style records
This is inherent risk of building on top of something you don't control. Don't really see this as fair comparison. It's a known design constraint. The only way to avoid it is to not build on top of Java or not adding any features on top of Java.
> To give another example with C#, there has been a lot of recent discussion about finding potential alternatives to their async-await concurrency model. They cite the level of effort it takes to maintain the async await style code and the costs that come from this.
I had a very different take-away. They did PoC with virtual threads and decided it's not worth the switch now and async-await that they have is good enough.
https://github.com/dotnet/runtimelab/issues/2398
> Some of the languages it gets compared too aren't even that old yet.
C# is more than old enough to drink and Scala just had its 20th birthday this weekend :) Java is only 4 years older than C#.
If your wish is to have Checked Exceptions be throwable from the lambda, then I understand your point. Still, I stand by argument, which is that they are actively addressing these pain points, but doing so slowly in ways that minimize intrusion.
> Kotlin
If it's not a fair comparison in your eyes, I'll leave it.
> async await in C#
I'd be more willing to accept your point of view if there wasn't so much discussion online about how painful async await is via color-my-function. And that's ignoring the fact that languages such as Go and Erlang have been garnering a big following, in large part due to their concurrency model and how simple it is.
I have had my share of async await too. I think it's no coincidence that many language designers are looking more and more into moving away from async await, thus prompting these PoC's and experiments.
As for the C# link specifically, I interpreted that to be that they felt the pain of async await strongly, and did the PoC in response. However, the PoC did not play well with their async await world, and trying to change the world to make room for it would be too much of a lift. Therefore, they stick with async. I did not interpret it to be that async await was good enough for them, but rather, that improving async await is the best option available to them for now.
> Age of languages
Sure, there are some languages that are a similar age to Java. But those are the languages where I believe the costs for the decisions they made are becoming more apparent. I already gave 1 example with C#. And I think we can both agree that Scala's design philosophy served as a great learning experience for other languages, but was a poor survivability tactic as a language. It feels like the language is buckling under its own weight.
Either way, I am not trying to say that these other languages are bad. Merely that their design philosophies benefit them in the short term, but show cracks in the long term. Java's philosophy, meanwhile, minimizes intrusion, and thus, allows it to sidestep alot of the problems that these other languages are trying to get out of.
The main problem of checked exception in lambdas is that Java's type system does not allow expressing statements like "`forEach` throws whatever the lambda throws". Here are two links:
http://james-iry.blogspot.com/2012/02/checked-exceptions-mig...
https://blog.jooq.org/javas-checked-exceptions-are-just-weir...
The proposed syntax puts the exceptions on equal footing with the happy path. Not a bad idea, but irrelevant to the main problem.
Part of that means that they will release minimal versions of a feature (records), and then observe how people use them before they start adding the "obvious" Quality-of-Life changes.
It's painful for those of us who are here when these features are just now releasing. But the end result is a feature that has less chance of screwing over other potential features.
It's best to think of it as a short term cost for a much longer term gain. Moving slow like this means that they will release a feature that is more cohesive than it otherwise could be.
https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...
That is important because it communicates that this feature is actually not yet in Preview, but is on its way to being that.
Being in the JEP Draft state sets expectations about what part of this proposal is up for debate and criticism, and what parts are merely placeholder until the "heavier topics" have been hammered out.
Because you changed the title to this, it is actually not communicating the true intent, and thus, might invite discussion (read - criticisms) that this JEP Draft was never meant to contest.
A shame that you can't ping them directly through this application (like you can in Reddit), but the response time was quick, so that is appreciated.
Point newLoc = oldLoc with {
x *= 2;
y *= 2;
z *= 2;
};
val newLoc = oldLoc.copy(
x = oldLoc.x * 2,
y = oldLoc.y * 2,
z = oldLoc.z * 2
)
val newLoc = oldLoc.run { copy(x = x * 2, y = y * 2, z = z * 2) }It should be 1 of the above. They also made the same weird new syntax choice with string template.
One of the most important things about a language is coherence and consistency. That’s why a language designer is a role/talent
They save things like syntax until the very end, right before they decide to submit this as an actual JEP instead of a JEP Draft. This JEP entered the Draft stage only a few hours ago.
All that is to say -- your comment makes sense, but you are criticizing the part of this JEP Draft that is not only the least relevant to the discussion, but the thing that is most likely to change before it exits the Draft stage. Oftentimes, they even put in placeholder syntax to highlight this fact.
I'd limit criticisms of syntax until they submit this JEP for actual review.
Seems very intuitive to me (and same as C#).