[GitHub] timboudreau commented on a change in pull request #537: Maven Indexing Optimizations

[GitBox <gi...@apache.org>]

timboudreau commented on a change in pull request #537: Maven Indexing Optimizations
URL: https://github.com/apache/incubator-netbeans/pull/537#discussion_r187471589
 
 

 ##########
 File path: maven.indexer/src/org/netbeans/modules/maven/indexer/ClassDependencyIndexCreator.java
 ##########
 @@ -213,39 +217,112 @@ static void search(String className, Indexer indexer, Collection<IndexingContext
         return referrers;
     }
 
+    static final Predicate<String> JDK_CLASS_TEST = new MatchWords(new String[]{
 
 Review comment:
   It is not so much that the class list is infallible, as that, in practice, even if the test misses a JDK class, it will not result in incorrect behavior.
   
   The test exists, basically, because you do not want to fill the index with all uses of, say `java.lang.Integer` - in practice nobody searches for that, and if they did there would be too many results for it to be useful.
   
   So, what are the possible failure scenarios:
   
   1.  A new package was added to the JDK, and gets indexed:  That's fine and will be for many years - even if it eventually is used as heavily as `java.lang.Integer`, it isn't right now, and there are years to add the package to the test before it's used enough to cause serious index bloat.
   
   2.  We are indexing a library downloaded from Maven which adds classes to a JDK package.  First, in practice, that doesn't happen - the main reasons it might are malicious, and in fact, one of the things JDK 9's module system is there to prevent.  Second, it means paying a performance penalty to handle a corner-case that, that 99.99999% of Maven users will never encounter (and if they do, it's because they downloaded a library that contains malicious code).
   
   Neither of those are cases that justify a more expensive test.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For additional commands, e-mail: notifications-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists