Property access not working when using delegation with records

[EotT123]

When using delegation, property-style access doesn’t work as expected for delegated members. Instead of allowing b.foo, the compiler requires b.foo(), even though the property is defined in the delegated type.

interface MyIntf {
    String foo();
}

record A(String foo) implements MyIntf {}

record B(@link A a, String b) implements MyIntf {}

A a = new A("foo");
B b = new B(a, "b");
String foo = a.foo; // Works as expected
b.foo; // Not working, b.foo() is required.

Environment:

• Java/JDK version: Jdk 25
• Manifold version: 2025.1.27

Related question: Should it be possible to define the getters in the interface as properties? It works for normal classes, but not for records:

interface MyIntf {
    @val String foo;
}

record A(String foo) implements MyIntf {} // ERROR

class C implements MyIntf {
    @val @override String foo; // OK
}

I'm not sure this is even possible. The interface defines the contract - in this case, a getter method. However, since a regular getter method is generated, it doesn’t align with the record accessor naming convention.
I think many of these issues could be avoided if Java simply followed the standard getter conventions, but that's not something that can be changed anymore...

[rsmckinney]

Related question: Should it be possible to define the getters in the interface as properties? It works for normal classes, but not for records:

It works for classes because properties generate get/set methods that directly implement the interface. Not so for records since they don't have get/set methods. I agree with you that records should have used standard conventions; I've considered generating getters for records for this reason.

If it's any consolation manifold's structural interfaces do support records.

@Structural 
interface MyInterface {
    @val String foo;
}

record A(String foo) {}

MyInterface mi = new A("hi");
out.println(mi.foo);

Structural assignability is much looser than nominal, it works with fields and record components, and supports variance wrt params and return types. Yet another feature Java should have by now, but in all likelihood will never provide.

[EotT123]

Structural interfaces are certainly an option, but they come with their own drawbacks. For example, sealed interfaces can be used in exhaustive switch expressions, while structural ones cannot. Structural interfaces also tend to be less intuitive, and because they are loosely coupled with their implementing classes, it’s easier to accidentally break something.

[rsmckinney]

Structural interfaces are certainly an option, but they come with their own drawbacks.

For sure. In my view structural types should only be used where nominal types impose unwanted limits or over-complicate design and usage.

But structural types can really improve architecture when used responsibly, for instance as a means to type-safely glue code together that otherwise involves wrappers, proxies, and similar identity-losing hacks.

[rsmckinney]

FYI next up: conditionally generate getter methods to bridge records with the implements clause. This supports your example:

interface MyIntf {
    @val String foo;
}

record A(String foo) implements MyIntf {
    . . .
    // generated to satisfy MyIntf#foo
   bridge public String getFoo() { return foo(); }
}

Note without implements MyIntf the bridge method would not be generated.

Note also, the earlier example where you have MyIntf using the foo() record naming convention:

interface MyIntf {
    String foo();
}

record A(String foo) implements MyIntf {}

record B(@link A a, String b) implements MyIntf {}

A a = new A("foo");
B b = new B(a, "b");
String foo = a.foo; // Works as expected
b.foo; // Not working, b.foo() is required.

This will still result with b.foo as errant because the generated B#foo() impl is not a direct component of B as it is with A, it's just a method. Java designers should have used the language's getXxx convention regardless of their personal preferences. Better yet, they should have added language support for properties 25 years ago and used that with records. Morons. But I digress.

[EotT123]

The bridge method seems like a nice solution!

For the second part, I’m not sure I fully understand it. Something like b.foo is replaced by b.getFoo(), right? Since the getFoo() method is added by Manifold, I would expect it to compile?
Or is the replacement not happening because some required information is missing? If I remember correctly, during one of the early compilation phases, annotations that carry extra information are added. I’m guessing that doesn’t happen here for B?
I'm wondering, since public String foo() { return this.a.foo(); } is generated in B, can't that method provided the necessary information?

Java designers should have used the language's getXxx convention regardless of their personal preferences. Better yet, they should have added language support for properties 25 years ago and used that with records. Morons. But I digress.

Maybe you should join the java architects 😉

[rsmckinney]

For the second part, I’m not sure I fully understand it. Something like b.foo is replaced by b.getFoo(), right? Since the getFoo() method is added by Manifold, I would expect it to compile?

interface MyIntf {
    String foo();
}

record A(String foo) implements MyIntf {}

record B(@link A a, String b) implements MyIntf {}

A a = new A("foo");
B b = new B(a, "b");
String foo = a.foo; // Works as expected
b.foo; // Not working, b.foo() is required.

This works for A because A#foo is a direct record component in A and since record components are properties by another name, manifold compiles A.foo as A.foo(). It is purely sugar to support property syntax for record components; no getFoo() method is required.

B is different because it doesn't have a foo record component. It uses manifold delegation to implement an MyIntf#foo(), which again is just an arbitrary interface method, not a property - the details of foo() being implemented by a record component aren't captured anywhere.

I agree with the expectation that it should work, which is perhaps a failing of manifold's delegation and properties subsystems by not cooperating fully. For instance, delegation code gen could annotate the generated A#foo() method as, say @DelegatedRecordComponent, or some such. With that, properties code gen could connect the dots.