[ 
https://issues.apache.org/jira/browse/LUCENE-4570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13577392#comment-13577392
 ] 

Dawid Weiss commented on LUCENE-4570:
-------------------------------------

Uwe -- the location of standard libraries is indeed a problem under various 
distros. J9 in particular has things scattered all over different JAR archives. 
My trick of the past was to enumerate several library classes (from different 
packages) and locate their bytecode based on their own class loader's 
getResourceAsURL call pointing to those classes' bytecode. This still won't 
work for certain classes that are native in J9, for example.

I needed it for proguard but it's essentially the same problem -- where the 
heck the library classes are.
{code}
public class DetectRtJar {
  public static void main(String[] args) throws Exception {
    Set<File> jars = new TreeSet<File>();

    Class<?> [] keyClasses = {
        java.lang.annotation.Annotation.class,
        java.lang.management.ManagementFactory.class,
        java.util.logging.Logger.class,
        java.awt.Component.class,
        java.beans.BeanDescriptor.class,
        java.io.File.class,
        java.lang.Object.class,
        java.math.BigDecimal.class,
        java.net.URL.class,
        java.nio.Buffer.class,
        java.security.Security.class,
        java.sql.Array.class,
        java.text.Collator.class,
        java.util.List.class,
        java.util.concurrent.ConcurrentHashMap.class,
        java.util.zip.ZipEntry.class,
        org.w3c.dom.Document.class,
    };

    ClassLoader cl = ClassLoader.getSystemClassLoader();
    for (Class<?> clazz : keyClasses) {
      URL url = cl.getResource(
          clazz.getName().replace('.', '/') + ".class");
      if (url.getProtocol().equals("jar")) {
        JarURLConnection juc = (JarURLConnection) url.openConnection();
        jars.add(new File(juc.getJarFile().getName()));
      } else {
        // Other scheme? wtf?
        throw new RuntimeException("Unknown scheme: " + url.toString());
      }
    }

    StringBuilder b = new StringBuilder();
    for (File f : jars) {
      b.append("-libraryjar ").append(f.getAbsolutePath());
      b.append("(java/**)");
      b.append("\n");
    }
  }
} 
{code}
                
> Release ForbiddenAPI checker on Google Code
> -------------------------------------------
>
>                 Key: LUCENE-4570
>                 URL: https://issues.apache.org/jira/browse/LUCENE-4570
>             Project: Lucene - Core
>          Issue Type: New Feature
>          Components: general/build
>            Reporter: Robert Muir
>            Assignee: Uwe Schindler
>             Fix For: 4.2, 5.0
>
>         Attachments: LUCENE-4570-maven-inherited.patch, 
> LUCENE-4570-maven.patch, LUCENE-4570-maven.patch, LUCENE-4570.patch, 
> LUCENE-4570.patch, LUCENE-4570.patch, LUCENE-4570.patch, LUCENE-4570.patch
>
>
> Currently there is source code in lucene/tools/src (e.g. Forbidden APIs 
> checker ant task).
> It would be convenient if you could download this thing in your ant build 
> from ivy (especially if maybe it included our definitions .txt files as 
> resources).
> In general checking for locale/charset violations in this way is a pretty 
> general useful thing for a server-side app.
> Can we either release lucene-tools.jar as an artifact, or maybe alternatively 
> move this somewhere else as a standalone project and suck it in ourselves?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to