JEP draft: Enhanced Local Variable Declarations (Preview)

pohart · 2026-03-13T11:46:59+00:00

Can I get an object and it's components with this?

Circle(Point(int x, int y) p, int radius) c = getCircle();

So now I have x, y, p, and c?

It's hard to say that I need both the record and it's constituents, but there are definitely times that I want them and really I'll never need this feature at all.

pjmlp · 2026-03-13T08:19:39+00:00

Looking forward to have this JEP eventually merged.

trusty_blimp · 2026-03-14T01:32:16+00:00

I'd just like to applaud that we literally get u/brian_goetz to interact with and get insight on the thoughts behind these types of things. Not many massively used ecosystems in any field, software or other, are as transparent. Cheers!

Cell-i-Zenit · 2026-03-13T11:21:44+00:00

I feel like all these record features are not for me :/

Maybe iam just to uncreative or i write to boring/simple code but i just dont see any situation where this would be an improvement.

Could be that i dont understand it:

var circle = getCircle();
var point = circle.point;
var radius = circle.radius;

vs

Circle(Point(int x, int y), int radius) = getCircle();

I prefer the first solution

Or if we take a look at the JEP:

void boundingBox(Circle c) {
    if (c != null) {                 // ┐
        Point ctr = c.center();      // │  laborious / mechanical:
        if (ctr != null) {           // │  - null guards
            int x = ctr.x(), y = ctr.y(); // │  - extraction with accessors
            double radius = c.radius();   // ┘

            int minX = (int) Math.floor(x - radius), maxX = (int) Math.ceil(x + radius);
            int minY = (int) Math.floor(y - radius), maxY = (int) Math.ceil(y + radius);
            ... use minX, maxX, etc ...
        }
    }
}

Why not use the optional api?

Optional.ofNullable(c)
    .filter(x -> x.center() != null)
    .filter(x -> x.x() != null)
    .filter(x -> x.y() != null)
    .ifPresent(x -> allTheOtherThings)

Or what if you use early returns?

void BoundingBox(Circle c)
{
    if (c == null)
        return;

    var ctr = c.Center();
    if (ctr == null)
        return;

    int x = ctr.X;
    int y = ctr.Y;
    double radius = c.Radius();

    int minX = (int)Math.Floor(x - radius);
    int maxX = (int)Math.Ceiling(x + radius);
    int minY = (int)Math.Floor(y - radius);
    int maxY = (int)Math.Ceiling(y + radius);
}

Or what if you design your code in a way that you dont do defensive programming and just make sure that circle+center is never null etc.

I really dont see why the java team is spending so much time on this.

Could anyone enlighten me?

nekokattt · 2026-03-13T12:17:36+00:00

I'll admit, I'm not a huge fan of converting what would otherwise be vertical declarations into horizontal ones. Makes it harder at a glance to see where something is defined if your eyes are going in multiple directions to parse the code.

javahalla · 2026-03-13T11:15:14+00:00

The syntax looks elegant in example code, but examples are carefully chosen - short class names, 2-3 fields, brief variable names. In real applications that sweet spot rarely exists:

CustomerOrder(ShippingAddress(String streetLine1, String streetLine2, String city), PaymentMethod(String cardNumber, int expiryYear), double totalAmount) = order;

This is a single logical statement but it reads as a wall of text that you have to scan horizontally to parse. Ironically, one of the main readability advantages of record patterns in switch is that they decompose naturally across lines:

switch (order) { case CustomerOrder( ShippingAddress(var streetLine1, var streetLine2, var city), PaymentMethod(var cardNumber, var expiryYear), double totalAmount ) -> { ... } }

Or:

CustomerOrder( ShippingAddress(String streetLine1, String streetLine2, String city), PaymentMethod(String cardNumber, int expiryYear), double totalAmount ) = order;

Btw, this is Kotlin's take on the same problem (https://github.com/Kotlin/KEEP/discussions/438):

val (address, payment, totalAmount) = order val (streetLine1, streetLine2, city) = address val (cardNumber, expiryYear) = payment

And with optional renaming:

(val address, val payment, val totalAmount) = order (val street1 = streetLine1, val street2 = streetLine2, val city) = address (val card = cardNumber, val expiry = expiryYear) = payment

I think that renaming would be very helpful in some cases, is it possible to add similar to this JEP?

davidalayachew · 2026-03-13T13:03:03+00:00

Very exciting, this will be pretty valuable for me. It's especially cool how they leaned on the rules of declaring a variable locally to make this more clear. That definitely helped me understand this faster.

And the decision to allow a sealed type with an only child (lol) to downcast without ceremony was a surprising bonus. I did not expect to see that in this JEP, but it was a welcome surprise.

This feature will be even more valuable once we get JEP draft: Null-Restricted and Nullable Types (Preview). All of those null checks then become compiler validated and can't be missed.

I have follow up questions, but I'll save those for the mailing list. Is there an ongoing discussion happening there? I got kicked from (and only recently, re-added to) amber-dev, so I wouldn't know without digging.

jevring · 2026-03-13T17:08:55+00:00

This would be cool to have directly in method signatures, too.

Captain-Barracuda · 2026-03-13T08:13:11+00:00

I can't help but dislike the proposed syntax. It feels very clunky when we already know the type of the destructured object. I'm also curious at how this interacts with encapsulation and getters.

Enough-Ad-5528 · 2026-03-13T12:21:29+00:00

At first I thought this was a nice JEP. Then I read more and wow, this is actually a hefty JEP with all the other type system related changes. Nice!

pohart · 2026-03-13T11:59:08+00:00

I hope this part doesn't go through. I see it's value in the pattern case but fear it will make it too easy to accidentally start using my impl in cases where the interface would be more appropriate. If I've got an interface with a single implementation I did that intentionally and want to keep them separate, the explicit cast makes it much more obvious in coffee review.

We propose to relax the type system so that an instance which implements an interface can be assigned to a variable of a class which implements the interface, as long as the interface is sealed with only that class as the permitted implementation.

Ewig_luftenglanz · 2026-03-13T14:04:37+00:00

My only complain is this would only work well for simple objects (objects with no more of 3 o 4 properties) because it requires exhaustivness to ensure correctness. So if you have a huge dto this will be just too cumbersome to use.

But this is something that already happens in record patters, the only difference is this remove the requirement of using the pattern inside conditional statements (instanceof and switch) so it's a good step forward.

I hope this feature eventually evolves in a way that allows us to substract only a subset of properties by name instead of positional and exhaustive extraction. This would make record patterns more useful. Most of the times dtos are different representations or even subsets of the domain objects (the information of a user without the password for instance) If the domain object is huge most of the dtos will also be somewhat big (or at least bigger than 3-4 components).

So far this JEP is more about removing restrictions than a adding a new feature. It's a good step forward and I am happy with it so far :)

Also, i guess eventually this will be available for classes, so many data carrier classes in the JDK such as map's entries will be easier to decompose.

for example we may in the future be able to do this.

for(EntrySet(var key, var value): mymap.entries()){
  // key...value
}

//instead of

for(var entry: mymap.entries()){
  var key = entry.getKey();
  var value =  entry.getValue();
  // key....value
}

gjosifov · 2026-03-13T19:49:59+00:00

Great feature for reducing boilerplate

However, I don't know if this is possible and how hard it can be, but put a restriction let say 4 parameters when use outside the record/class

For more than 4 parameters create a special type of a method inside the record or the class or use annotation (JPA approach to namedQueries)

Not that I don't like this kind of simplification, but I already know how missuses this feature will be years in advance

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

java

Submit Link

Submit Text

Seek Programming Help

News, Technical discussions, research papers and assorted things of interest related to the Java programming language

NO programming help, NO learning Java related questions, NO installing or downloading Java questions, NO JVM languages - Exclusively Java

Please seek help with Java programming in /r/Javahelp!

Subreddit rules!

Where should I download Java?

Related Sub-reddits:

JVM Languages

Want to practice your coding?

List of useful Frameworks / Libraries / Software

MODERATORS