(Sealed) Interfaces werden nicht korrekt aus Class-Dateien eingelesen #356

New Issue

jschmidt · 2025-01-03T13:48:04Z

jschmidt commented

2025-01-03 13:48:04 +00:00

Ich verwenden den aktuellen Stand 542389d35b vom PatternMatching Branch, Java Version 23

Folgendes Szenario:

Ein Interface wird in einer Java-Datei erstellt und mit javac kompiliert
Dieses Interface (also die kompilierte class Datei) wird in einer Jav-Datei referenziert
Der JavaTX Compiler wirft eine Fehlermeldung, dass das referenzierte Interface sealed ist und nicht von der Klasse implementiert werden kann (Das Interface ist aber nicht als sealed definiert)

Exception in thread "main" de.dhbwstuttgart.bytecode.CodeGenException: Sealed interface Bar doesn't permit class Foo
        at de.dhbwstuttgart.bytecode.Codegen.generate(Codegen.java:1633)
        at de.dhbwstuttgart.core.JavaTXCompiler.generateBytecode(JavaTXCompiler.java:632)
        at de.dhbwstuttgart.core.JavaTXCompiler.generateBytecode(JavaTXCompiler.java:597)
        at de.dhbwstuttgart.core.JavaTXCompiler.generateBytecode(JavaTXCompiler.java:583)
        at de.dhbwstuttgart.core.ConsoleInterface.main(ConsoleInterface.java:42)

Das Problem scheint also zu sein, wie der JavaTX Compiler class Dateien einliest und parsed. Dabei scheint das "permittedSubtypes" Attribut nicht korrekt gesetzt zu werden. So wie das sehe, sollte dieses Attribute für unsealed Interfaces den Wert "null" annehmen, bei Interfaces die von class-Dateien gelesen werden, nimmt es aber den Wert einer leeren Liste an.

Ich denke das sollte so nicht sein, dann das entspricht von der Logik her einem sealed Interface, welches keiner Klasse die Implementierung erlaubt.

Im Anhang ein Beispielaufbau. Die Interface Datei wurde bereits mit javac kompiliert.
Dazu einfach java -jar JavaTXcompiler.jar Test.jav aufrufen

Ich verwenden den aktuellen Stand 542389d35b vom PatternMatching Branch, Java Version 23 Folgendes Szenario: - Ein Interface wird in einer Java-Datei erstellt und mit javac kompiliert - Dieses Interface (also die kompilierte class Datei) wird in einer Jav-Datei referenziert - Der JavaTX Compiler wirft eine Fehlermeldung, dass das referenzierte Interface sealed ist und nicht von der Klasse implementiert werden kann (Das Interface ist aber nicht als sealed definiert) ``` Exception in thread "main" de.dhbwstuttgart.bytecode.CodeGenException: Sealed interface Bar doesn't permit class Foo at de.dhbwstuttgart.bytecode.Codegen.generate(Codegen.java:1633) at de.dhbwstuttgart.core.JavaTXCompiler.generateBytecode(JavaTXCompiler.java:632) at de.dhbwstuttgart.core.JavaTXCompiler.generateBytecode(JavaTXCompiler.java:597) at de.dhbwstuttgart.core.JavaTXCompiler.generateBytecode(JavaTXCompiler.java:583) at de.dhbwstuttgart.core.ConsoleInterface.main(ConsoleInterface.java:42) ``` Das Problem scheint also zu sein, wie der JavaTX Compiler class Dateien einliest und parsed. Dabei scheint das "permittedSubtypes" Attribut nicht korrekt gesetzt zu werden. So wie das sehe, sollte dieses Attribute für unsealed Interfaces den Wert "null" annehmen, bei Interfaces die von class-Dateien gelesen werden, nimmt es aber den Wert einer leeren Liste an. Ich denke das sollte so nicht sein, dann das entspricht von der Logik her einem sealed Interface, welches keiner Klasse die Implementierung erlaubt. <img width="722" alt="grafik" src="attachments/164ba475-693f-4412-92bd-eaee3efa098b"> Im Anhang ein Beispielaufbau. Die Interface Datei wurde bereits mit javac kompiliert. Dazu einfach `java -jar JavaTXcompiler.jar Test.jav` aufrufen

grafik.png

64 KiB

test.zip

20 MiB

dholle was assigned by jschmidt

2025-01-03 14:07:21 +00:00

jschmidt added a new dependency 2025-01-03 14:07:37 +00:00

#355 Bridge-Methode für Pattern Matching in Funktionsköpfen

jschmidt removed a dependency 2025-01-03 14:07:42 +00:00

#355 Bridge-Methode für Pattern Matching in Funktionsköpfen

jschmidt referenced this issue from a commit

2025-01-26 15:19:23 +00:00