lahodaj commented on PR #9327: URL: https://github.com/apache/netbeans/pull/9327#issuecomment-4234653385
So, I think this is heading in a reasonable direction, but (from my experiments so far) for not quite the right reason. I think the ultimate reason why it fails is that there are no system classes present in the file manager that is used, and then, as a consequence, it will happen that there are two/multiple erroneous representations of `java.lang.String`, and the reading of the `ConstantValue` attribute for `GREETING` fails because of these multiple representations, with a cascading effect. (You can see it in the test - if you comment out `public static final String GREETING = "hello";`, the test will start to pass even for unpatched NB.) It is also true that: a) the `packages`/`classes` handling is broken there (and is probably broken for a very, VERY, long time). And this hole `packages`/`classes` and `setRoot` handling is highly dubious at best. But, there was a reason for that: to avoid creating (and populating) a separate javac instance for each symbol. And while this may be somewhat smaller concern nowadays, I am not completely convinced we can simply ignore the performance aspect. At very least, I think we should evaluate what are the performance implications of creating a javac instance per symbol. And, possibly and ideally, looking at possibilities to create only a single javac instance per (source) root that would be cached while the Open Symbol window would be open, and dropped afterwards. (Maybe held using SoftReference, so avoid going out of memory in extreme cases.) I don't think reusing javac instances across roots is realistic, and such attempts should be dropped/removed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
