On Thu, 2 Apr 2026 15:52:40 GMT, Aggelos Biboudis <[email protected]> 
wrote:

> This is the proposed patch for Enhanced Local Variable Declarations (Preview).
> 
> - [x] I confirm that I make this contribution in accordance with the [OpenJDK 
> Interim AI Policy](https://openjdk.org/legal/ai).

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2462:

> 2460:             }
> 2461: 
> 2462:             for (Type supertype : directSupertypes(current)) {

Good!

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2469:

> 2467:                     if (superSym.isSealed()
> 2468:                             && permitted.size() == 1
> 2469:                             && permitted.getFirst().tsym == 
> current.tsym) {

I think this should help reject this:


sealed interface Foo permits Bar { }
final class Bar implements Foo {}
class Test<X extends Foo> {
    void test(Foo foo) {
        X x = foo;
    }
}

But maybe let's add a test just in case.

(Note: unfortunately you can have a type parameter bound refer to an unrelated 
sealed interface).

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 967:

> 965:     }
> 966: 
> 967:     private ExhaustivenessResult 
> checkExhaustiveSwitchProperty(DiagnosticPosition selectorPos, JCPattern 
> patternTree, Type selectorType) {

Should this return an exhaustiveness result, or just a boolean, given how it's 
used?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 3698:

> 3696:             JCExpression vardefinit = 
> make.App(make.Select(make.Ident(itvar), next));
> 3697: 
> 3698:             Assert.check(tree.getDeclarationKind() == 
> EnhancedForLoopTree.DeclarationKind.VARIABLE);

good assertion (here and above) -- if we get here it needs to be a plain 
for-each

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 
1206:

> 1204:             tree.type = syms.booleanType;
> 1205: 
> 1206:             JCIf ifNode = make.If(makeUnary(Tag.NOT,

Nice and simple -- generate pattern instance of, then call translate, which 
will deal with it :-)

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 
1236:

> 1234:                  * <pre>{@code
> 1235:                  *     for (<type-of-coll-item> N$temp : coll) {
> 1236:                  *     switch (N$temp) {

Why is this translated with an `switch` instead of an instanceof (as in the 
other case) ?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java line 
142:

> 140:         Type btarget = target.baseType();
> 141:         if (tree.type.isPrimitive() == target.isPrimitive()) {
> 142:             boolean assignable = types.isAssignable(tree.type, btarget, 
> types.noWarnings);

I wonder if a name like `rawAssignable` might pop out more

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 
3306:

> 3304:                             return VariableDeclKind.LocalVarDecl;
> 3305:                         }
> 3306:                         else if(peekToken(lookahead, COLON) ||  // in 
> the init part of an enhanced for loop

This will also allow ELVD in a non-for each loop, right?

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 
3367:

> 3365:     protected boolean hasDisallowedModifiers(JCModifiers mods) {
> 3366:         return mods != null
> 3367:                 && (mods.annotations.nonEmpty() || (mods.flags & 
> Flags.FINAL) != 0);

Question -- I understand why we reject `final`. By the same token, I'd also 
reject `volatile` or `transient` or any modifier that refers to storage 
semantics. The issue here is that there's no (outer) variable being declared -- 
so IMHO would be simpler to assume no modifiers?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/30556#discussion_r3167051698
PR Review Comment: https://git.openjdk.org/jdk/pull/30556#discussion_r3167089414
PR Review Comment: https://git.openjdk.org/jdk/pull/30556#discussion_r3167108265
PR Review Comment: https://git.openjdk.org/jdk/pull/30556#discussion_r3167127856
PR Review Comment: https://git.openjdk.org/jdk/pull/30556#discussion_r3167149413
PR Review Comment: https://git.openjdk.org/jdk/pull/30556#discussion_r3167166290
PR Review Comment: https://git.openjdk.org/jdk/pull/30556#discussion_r3167116661
PR Review Comment: https://git.openjdk.org/jdk/pull/30556#discussion_r3166971064
PR Review Comment: https://git.openjdk.org/jdk/pull/30556#discussion_r3166942997

Reply via email to