Community
Participate
Working Groups
As observed in ModuleCompilationTests.testReleaseOption13 But can be easily reproduced using a module-info and running Main with --release 9 option We get errors of the kind java.lang.Object cannot be resolved. This is because ClasspathJep247, which is used when compiling for a lower release version, does not build the modules cache. Need to investigate if the modules information can be gathered from ct.sym as well
(In reply to Sasikanth Bharadwaj from comment #0) > Need to investigate if the modules information can be gathered from ct.sym > as well I am sure it can be. The ClasspathJrt for IDE implements correctly. Also worth noting is that version "10" is represented in the ct.cym as "A". So, looks like we need to shift from String to number representation of version in this area.
So, here's what the format of ct.sym looks like as of today: 1. Release versions are represented in Hex format. Release 10 is 'A'. 2. Since 9, each version appear to get two folders, for e.g. "9-modules" for module class files and "9" for rest of the classes. 3. The current version folder contains a file named ""system-modules", which is the symbolic link to the latest modules. Perhaps we can pass this path to the JRTUtil to load the modules, if there is any benefit in it.
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.
