Unexpected compile error for sealed-interface without permits inside record

[lukeu]

Given the following, which javac accepts...

	record InterfaceInRecord() {
	    sealed interface I {
	        enum Empty implements I {
	            INSTANCE;
	        }
	        record Single(double value) implements I {
	        }
	    }
	}

... Eclipse issues 2 compiler errors on the lines containing implements I

Here are 2 modifications that (independently) resolve the errors:

• Change the outer record into a class; or
• Following sealed interface I insert permits I.Empty, I.Single (A useful workaround)

Based on this evidence (nb: without reading the language spec) I'm inclined to think the Eclipse compiler is wrong in this case.

Tested using:

• Eclipse Version: 2023-12 (4.30 RC2) - Build id: I20231123-1700
• Running on Java Temurin: jdk-21.0.0.35-hotspot
• Trying both "Compiler Compliance Level" 17 and 21

[lukeu]

@jarthana, @mpalat FYI I've done some digging into the code, and this issue seems related to the functionality added here:

Bug 564498 - [15] JEP 360 error flagged for implicit permits in inner classes
Change-Id: Id649441c9c4cd16cdf227e50c4a20b8ae5751335
Signed-off-by: Jay Arthanareeswaran

There was a further small change added into ClassScope$connectImplicitPermittedTypes later:

-  if (sourceType.id == TypeIds.T_JavaLangObject || sourceType.isEnum()) // already handled
+  if (sourceType.id == TypeIds.T_JavaLangObject || sourceType.isEnum() || sourceType.isRecord()) // already handled

From within this commit:

Bug 565388 - [15] sealed error to be changed to be more meaningful
Change-Id: Ie38d894e11f5ae57cbf6bb3df0c873ca92561ddb
Signed-off-by: Manoj Palat

Which seems to make this method return early, thus not populating the "permitted types" for the inner-most types in this scenario.

Here's a more minimal test-case, which is easier to debug:

	record InterfaceInRecord() { 
	    sealed interface I  {
	        final class C implements I {
	        }
	    }
	}

The innermost class InterfaceInRecord$I$C incorrectly ends up with a blank array of permitted types.

Removing the isRecord() early-exit appears to make the issue go away. However I am out of my depth as to whether that clause is necessary in some other situations.

[mpalat]

Thanks @lukeu for providing the test case and investigating further - will take a look

[lukeu]

Hi, thanks for looking into this. I played around with the fix and I believe similar bugs remain when the sealed interface is inside an enum rather than a record. Here is another test case:

enum InterfaceInEnum {
    INSTANCE;
    sealed interface I  {
        final class C implements I {}
    }
    final class D implements I {}
}

Similarly, Eclipse reports 2x compiler errors here, whereas javac reports none.

However, when attempting to test the workaround, a crash occurs. Specifically, this is thrown after typing: permits I.

java.lang.NullPointerException: Cannot read the array length because "superPermittedTypes" is null
at org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.checkPermitsAndAdd(SourceTypeBinding.java:1342)
at org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.checkPermitsInType(SourceTypeBinding.java:1203)
at org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.checkPermitsInType(SourceTypeBinding.java:1210)
at org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.checkPermitsInType(SourceTypeBinding.java:1210)
at org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.faultInTypesForFieldsAndMethods(SourceTypeBinding.java:1112)
at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInTypes(CompilationUnitScope.java:603)
at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:1314)
at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:790)
at org.eclipse.jdt.core.dom.ASTParser.internalCreateASTCached(ASTParser.java:1242)
at org.eclipse.jdt.core.dom.ASTParser.lambda$0(ASTParser.java:1120)
at org.eclipse.jdt.internal.core.JavaModelManager.cacheZipFiles(JavaModelManager.java:5812)
at org.eclipse.jdt.core.dom.ASTParser.internalCreateAST(ASTParser.java:1120)
at org.eclipse.jdt.core.dom.ASTParser.createAST(ASTParser.java:868)
at org.eclipse.jdt.core.manipulation.CoreASTProvider$1.run(CoreASTProvider.java:294)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:47)
at org.eclipse.jdt.core.manipulation.CoreASTProvider.createAST(CoreASTProvider.java:286)
at org.eclipse.jdt.core.manipulation.CoreASTProvider.getAST(CoreASTProvider.java:199)
at org.eclipse.jdt.core.manipulation.CoreASTProvider.getAST(CoreASTProvider.java:189)
at org.eclipse.jdt.core.manipulation.SharedASTProviderCore.getAST(SharedASTProviderCore.java:138)

This also appears to be to do with permitted types in the AST, so maybe another side of the same coin?

---

Adding a further line creates a different variant of the test case above. (With this it does not seem to trigger the crash):

    final class E implements InterfaceInEnum.I {}

• Observed: 3 compile errors
• Expected: No compile errors - the same as if the user had explicitly written sealed interface I permits I.C, D, E

[mpalat]

Thanks @lukeu for the variants - will check. should have taken care of enums as well..
btw, didn't understand the workaround part of "However, when attempting to test the workaround, a crash occurs. ", which workaround are you referring to? I am not getting this stacktrace

[lukeu]

which workaround are you referring to?

I mean that after: sealed interface I I began typing permits I.C, D, E and as soon as I typed the '.' I saw that stack-trace.

As for my environment, I am debugging Eclipse from Eclipse as described here.

[mpalat]

I mean that after: sealed interface I I began typing permits I.C, D, E and as soon as I typed the '.' I saw that stack-trace.

Ah, I see. Thanks for the immediate response. able to reproduce this - the pr fixes it though its a different issue. -will see whether a fix can be piggybacked with this pr. Thanks

[mpalat]

I mean that after: sealed interface I I began typing permits I.C, D, E and as soon as I typed the '.' I saw that stack-trace.

Ah, I see. Thanks for the immediate response. able to reproduce this - the pr fixes it though its a different issue. -will see whether a fix can be piggybacked with this pr. Thanks

@lukeu I've merged the fix for enums also last week via #1739 - Please let me know whether you see any further issues in your setup. closing this now.