jlahoda commented on PR #5174:
URL: https://github.com/apache/netbeans/pull/5174#issuecomment-1368550910

   > If I understand the idea correctly, the indention is, that code completion 
and type resolution of the IDE will work correctly for projects using the 
bundled javac. This is very good @jlahoda. However I checked `java.source.base` 
module and noticed, that only a subset of problems is gone. The module uses 
classes from the `com.sun.tools.javac.tree` package, which is in 
`nb-javac-jdk-19+33.jar`. I tested with this change and all problems are gone:
   > 
   > ```diff
   > --- 
a/apisupport/apisupport.ant/src/org/netbeans/modules/apisupport/project/Evaluator.java
   > +++ 
b/apisupport/apisupport.ant/src/org/netbeans/modules/apisupport/project/Evaluator.java
   > @@ -426,15 +426,9 @@
   >              if (type == NbModuleType.NETBEANS_ORG && 
"true".equals(projectProperties.getProperties().get("requires.nb.javac"))) {
   >                  ModuleEntry javacLibrary = 
ml.getEntry("org.netbeans.libs.javacapi");
   >                  if (javacLibrary != null) {
   > -                    List<String> bootstrapAPIs = new ArrayList<>();
   > -                    for (String ext : 
javacLibrary.getClassPathExtensions().split(Pattern.quote(File.pathSeparator))) 
{
   > -                        if (ext.endsWith("-api.jar")) {
   > -                            bootstrapAPIs.add(ext);
   > +                    
buildDefaults.put(ClassPathProviderImpl.BOOTCLASSPATH_PREPEND, 
javacLibrary.getClassPathExtensions());
   >                          }
   >                      }
   > -                    
buildDefaults.put(ClassPathProviderImpl.BOOTCLASSPATH_PREPEND, 
bootstrapAPIs.stream().collect(Collectors.joining(File.pathSeparator)));
   > -                }
   > -            }
   >              
   >              baseEval = PropertyUtils.sequentialPropertyEvaluator(predefs, 
providers.toArray(new PropertyProvider[providers.size()]));
   > ```
   
   That's what I don't want to do blindly - that would mean that any module 
could seemingly use javac internals, which does not sound right. (There are 
many limitations on this, so some modules have an impl. dependency even though 
they should not, the impl might be partially visible in the editor anyway, and 
the build also uses everything including the impl. OTOH, runtime is strict, and 
I don't think we should make the situation worse.) But, we may be able to parse 
the javac dependency, and if it is an impl. dependency, use even the 
implementation. (Of course, the very correct way would be to only use exported 
packages, but we don't do that in the IDE for anything.) Please see 
https://github.com/apache/netbeans/pull/5174/commits/441cd888642002d9e52632d08aa31c08f318bc37.
 
   


-- 
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

Reply via email to