Community
Participate
Working Groups
Steps to reproduce. 1) Create a java project with Java 16 compliance and previews enabled.(Do not create module-info.java) 2) Create 2 Packages Pkg1 and Pkg2 3) Create 2 classes Cls1 and Cls2 in Pkg1 such that Cls1 is a sealed class which permits Cls2 and Cls2 implements Cls1. 4) Create a class final Cls3 in Pkg2 and select Cls1 as its super class An error is reported in Cls3 that Cls3 is not a permitted type of Cls1. But adding Cls3 to permitted types of Cls1 does not fix the problem as this is a non-modular project and the classes are in different packages. So, In a non-modular project all sealed and permitted classes should belong to the same package. An appropriate error needs to be thrown here that Cls3 cannot extend Cls1 as it is a sealed class in a different package. Similarly if the project is modular, both Cls1 and Cls3 need to belong to same module. Appropriate error also needs to be thrown here. Similarly if the sealed Super Class is coming from an external jar (read-only) then too an appropriate error needs to be thrown.
(In reply to Kalyan Prasad Tatavarthi from comment #0) > Steps to reproduce. > > 1) Create a java project with Java 16 compliance and previews enabled.(Do > not create module-info.java) > 2) Create 2 Packages Pkg1 and Pkg2 > 3) Create 2 classes Cls1 and Cls2 in Pkg1 such that Cls1 is a sealed class > which permits Cls2 and Cls2 implements Cls1. > 4) Create a class final Cls3 in Pkg2 and select Cls1 as its super class > > An error is reported in Cls3 that Cls3 is not a permitted type of Cls1. > > But adding Cls3 to permitted types of Cls1 does not fix the problem as this > is a non-modular project and the classes are in different packages. So, In a > non-modular project all sealed and permitted classes should belong to the > same package. > > An appropriate error needs to be thrown here that Cls3 cannot extend Cls1 as > it is a sealed class in a different package. > > Similarly if the project is modular, both Cls1 and Cls3 need to belong to > same module. Appropriate error also needs to be thrown here. > > Similarly if the sealed Super Class is coming from an external jar > (read-only) then too an appropriate error needs to be thrown. Correction: In a non-modular project a sealed and all its permitted classes should belong to the same package.
New Gerrit change created: https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/182572
Gerrit change https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/182572 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=422f83bea86ddf732e0bd112c3d73f56350f5b79
Creating a new sub class Cls4 with Cls1 as super class using the "New Class Creation Wizard" reports error that Cls4 is in a different package even if they are in the same packages
New Gerrit change created: https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/182833
Gerrit change https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/182833 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=5e0f23fc9ed2a44d9d2186f1bc5c27a1d1b53d83
Keeping this bug open so as to figure out the issue that was happening in Comment 4 . The fix added now is only to not give a wrong error.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
