I am using some third party code which when given a &#39;-classpath&#39; command line argument doesnt set the java.class.path, but instead just creates a classloader, adds all the urls for the items on the command line specified classpath to the classloader, and then sets it to be the context classloader.
In a plugin class to this code that I have written, I get an instance of this classloader, and somehow need to use it to get back  the underlying classpath, so that I can use it in an invocation of JavaCompiler.getTask(...) and compile some other code on the fly.
However there doesn&#39;t seem to be anyway to get the ClassPath from the ClassLoader, and as java.class.path is unset, I can&#39;t seem to access the underlying classpath that the application was initially invoked with...Any ideas?


How to get classpath from classloader?

How do I search the whole classpath for an annotated class?

I&#39;m doing a library and I want to allow the users to annotate their classes, so when the Web application starts I need to scan the whole classpath for certain annotation.

I&#39;m thinking about something like the new functionality for Java EE 5 Web Services or EJB&#39;s. You annotate your class with `@WebService` or `@EJB` and the system finds these classes while loading so they are accessible remotely.

Scanning Java annotations at runtime

What is the difference between a thread&#39;s context class loader and a normal class loader?

That is, if `Thread.currentThread().getContextClassLoader()` and `getClass().getClassLoader()` return different class loader objects, which one will be used?

Difference between thread&#39;s context class loader and normal classloader

I wonder what the difference is between `Class.getResource()` and `ClassLoader.getResource()`?

*edit: I especially want to know if any caching is involved on file/directory level. As in &quot;are directory listings cached in the Class version?&quot;*

AFAIK the following should essentially do the same, but they are not:

    getClass().getResource() 
    getClass().getClassLoader().getResource()

I discovered this when fiddling with some report generation code that creates a new file in `WEB-INF/classes/` from an existing file in that directory. When using the method from Class, I could find files that were there at deployment using `getClass().getResource()`, but when trying to fetch the newly created file, I recieved a null object. Browsing the directory clearly shows that the new file is there. The filenames were prepended with a forward slash as in &quot;/myFile.txt&quot;.

The `ClassLoader` version of `getResource()` on the other hand did find the generated file. From this experience it seems that there is some kind of caching of the directory listing going on. Am I right, and if so, where is this documented?

From the [API docs][1] on `Class.getResource()`
&gt; Finds a resource
&gt; with a given name. The rules for
&gt; searching resources associated with a
&gt; given class are implemented by the
&gt; defining class loader of the class.
&gt; This method delegates to this object&#39;s
&gt; class loader. If this object was
&gt; loaded by the bootstrap class loader,
&gt; the method delegates to
&gt; ClassLoader.getSystemResource(java.lang.String).

To me, this reads &quot;Class.getResource is really calling its own classloader&#39;s getResource()&quot;. Which would be the same as doing `getClass().getClassLoader().getResource()`. But it is obviously not. Could someone please provide me with some illumination into this matter?


  [1]: http://download.oracle.com/javase/1,5.0/docs/api/java/lang/Class.html#getResource%28java.lang.String%29

What is the difference between Class.getResource() and ClassLoader.getResource()?

In Java, you can load all kinds of resources using the same API but with different URL protocols:

    file:///tmp.txt
    http://127.0.0.1:8080/a.properties
    jar:http://www.foo.com/bar/baz.jar!/COM/foo/Quux.class

This nicely decouples the actual loading of the resource from the application that needs the resource, and since a URL is just a String, resource loading is also very easily configurable.

Is there a protocol to load resources using the current classloader?
This is similar to the Jar protocol, except that I do not need to know which jar file or class folder the resource is coming from.

I can do that using [`Class.getResourceAsStream(&quot;a.xml&quot;)`][1], of course, but that would require me to use a different API, and hence changes to existing code. I want to be able to use this in all places where I can specify a URL for the resource already, by just updating a property file.


  [1]: http://docs.oracle.com/javase/7/docs/api/java/lang/Class.html#getResourceAsStream(java.lang.String)

URL to load resources from the classpath in Java

Does anyone know how to programmaticly find out where the java classloader actually loads the class from?  

I often work on large projects where the classpath gets very long and manual searching is not really an option.  I recently had a [problem][1] where the classloader was loading an incorrect version of a class because it was on the classpath in two different places.

So how can I get the classloader to tell me where on disk the actual class file is coming from?

***Edit:*** What about if the classloader actually fails to load the class due to a version mismatch (or something else),  is there anyway we could find out what file its trying to read before it reads it?

  [1]: https://stackoverflow.com/questions/226280/eclipse-class-version-bug &quot;problem&quot;

Find where java class is loaded from

I cannot for the life of me find a definition of what the Java VM flag `CMSClassUnloadingEnabled` actually does, other than some very fuzzy high-level definitions such as &quot;gets rid of your PermGen problems&quot; ([which it doesn&#39;t][1], btw).

I have looked on Sun&#39;s/Oracle&#39;s site, and even [the options list][2] doesn&#39;t actually say what it does.

Based upon the name of the flag, I&#39;m guessing that the CMS Garbage Collector doesn&#39;t by default unload classes, and this flag turns it on - but I can&#39;t be sure.




  [1]: https://stackoverflow.com/questions/3333807/the-various-options-for-solving-permgen-problems/3334397#3334397
  [2]: http://blogs.oracle.com/watt/resource/jvm-options-list.html

What does JVM flag CMSClassUnloadingEnabled actually do?

I have a custom class loader so that a desktop application can dynamically start loading classes from an AppServer I need to talk to. We did this since the amount of jars that are required to do this are ridiculous (if we wanted to ship them). We also have version problems if we don&#39;t load the classes dynamically at run time from the AppServer library.

Now, I just hit a problem where I need to talk to two different AppServers and found that depending on whose classes I load first I might break badly... Is there any way to force the unloading of the class without actually killing the JVM?

Hope this makes sense


Unloading classes in java?

In a few simple sentences, what is a Java ClassLoader, when is it used and why?

OK, I read a wiki article. ClassLoader loads classes. OK. So if I include jar files and import, a ClassLoader does the job.

Why should I bother with this ClassLoader? I&#39;ve never used it and didn&#39;t know it existed.

The question is, why does the ClassLoader class exist? And also, how do you use it in practice? (Cases exist, I know.)

What is a Java ClassLoader?

I am not in front of an IDE right now, just looking at the API specs.

    CodeSource src = MyClass.class.getProtectionDomain().getCodeSource();
    if (src != null) {
        URL jar = src.getLocation();
    }

I want to determine which JAR file a class is from. Is this the way to do it?


Determine which JAR file a class is from

In my office, the mere mention of the word Xerces is enough to incite murderous rage from developers. A cursory glance at the other Xerces questions on SO seem to indicate that almost all Maven users are &quot;touched&quot; by this problem at some point.  Unfortunately, understanding the problem requires a bit of knowledge about the history of Xerces...

# History #

 - Xerces is the most widely used XML parser in the Java ecosystem.  Almost every library or framework written in Java uses Xerces in some capacity (transitively, if not directly).

 - The Xerces jars included in the [official binaries][1] are, to this day, not versioned.  For example, the Xerces 2.11.0 implementation jar is named `xercesImpl.jar` and not `xercesImpl-2.11.0.jar`.

 - The Xerces team [does not use Maven][2], which means they do not
   upload an official release to [Maven Central][3].

 - Xerces used to be [released as a single jar][4] (`xerces.jar`), but was split into two jars, one containing the API (`xml-apis.jar`) and one containing the implementations of those APIs (`xercesImpl.jar`).  Many older Maven POMs still declare a dependency on `xerces.jar`.  At some point in the past, Xerces was also released as `xmlParserAPIs.jar`, which some older POMs also depend on.

 - The versions assigned to the xml-apis and xercesImpl jars by those who deploy their jars to Maven repositories are often different.  For example, xml-apis might be given version 1.3.03 and xercesImpl might be given version 2.8.0, even though both are from Xerces 2.8.0.  This is because people often tag the xml-apis jar with the version of the specifications that it implements.  There is a very nice, but incomplete breakdown of this [here][5].

 - To complicate matters, Xerces is the XML parser used in the reference implementation of the Java API for XML Processing (JAXP), included in the JRE. The implementation classes are repackaged under the `com.sun.*` namespace, which makes it dangerous to access them directly, as they may not be available in some JREs.  However, not all of the Xerces functionality is exposed via the `java.*` and `javax.*` APIs; for example, there is no API that exposes Xerces serialization. 

 - Adding to the confusing mess, almost all servlet containers (JBoss, Jetty, Glassfish, Tomcat, etc.), ship with Xerces in one or more of their `/lib` folders.

# Problems #

### Conflict Resolution ###

For some -- or perhaps all -- of the reasons above, many
organizations publish and consume custom builds of Xerces in their
POMs.  This is not really a problem if you have a small application and are only using Maven Central, but it quickly becomes an issue for enterprise software where Artifactory or Nexus is proxying multiple repositories (JBoss, Hibernate, etc.):

![xml-apis proxied by Artifactory][6] 

For example, organization A might publish `xml-apis` as:  

    &lt;groupId&gt;org.apache.xerces&lt;/groupId&gt;
    &lt;artifactId&gt;xml-apis&lt;/artifactId&gt;
    &lt;version&gt;2.9.1&lt;/version&gt;

   
Meanwhile, organization B might publish the same `jar` as:
   
    &lt;groupId&gt;xml-apis&lt;/groupId&gt;
    &lt;artifactId&gt;xml-apis&lt;/artifactId&gt;
    &lt;version&gt;1.3.04&lt;/version&gt;

   
Although B&#39;s `jar` is a lower version than A&#39;s `jar`, Maven does not know
that they are the same artifact because they have different
`groupId`s. Thus, it cannot perform conflict resolution and both
`jar`s will be included as resolved dependencies:

![resolved dependencies with multiple xml-apis][7]

### Classloader Hell ###

As mentioned above, the JRE ships with Xerces in the JAXP RI.  While it would be nice to mark all Xerces Maven dependencies as `&lt;exclusion&gt;`s or as `&lt;provided&gt;`, the third-party code you depend on may or may not work with the version provided in JAXP of the JDK you&#39;re using.  In addition, you have the Xerces jars shipped in your servlet container to contend with. This leaves you with a number of choices: Do you delete the servlet version and hope that your container runs on the JAXP version? Is it better to leave the servlet version, and hope that your application frameworks run on the servlet version? If one or two of the unresolved conflicts outlined above manage to slip into your product (easy to happen in a large organization), you quickly find yourself in classloader hell, wondering which version of Xerces the classloader is picking at runtime and whether or not it will pick the same jar in Windows and Linux (probably not).

# Solutions? #

We&#39;ve tried marking all Xerces Maven dependencies as `&lt;provided&gt;` or as an `&lt;exclusion&gt;`, but this is difficult to enforce (especially with a large team) given that the artifacts have so many aliases (`xml-apis`, `xerces`, `xercesImpl`, `xmlParserAPIs`, etc.).  Additionally, our third party libs/frameworks may not run on the JAXP version or the version provided by a servlet container.

**How can we best address this problem with Maven?  Do we have to exercise such fine-grained control over our dependencies, and then rely on tiered classloading?  Is there some way to globally exclude all Xerces dependencies, and force all of our frameworks/libs to use the JAXP version?**

----------

**UPDATE**: Joshua Spiewak has uploaded a patched version of the Xerces build scripts to [XERCESJ-1454][8] that allows for upload to Maven Central.  Vote/watch/contribute to this issue and let&#39;s fix this problem once and for all.


  [1]: http://xerces.apache.org/mirrors.cgi#binary
  [2]: https://issues.apache.org/jira/browse/XERCESJ-1454?focusedCommentId=12881865&amp;page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12881865
  [3]: http://search.maven.org/
  [4]: http://xerces.apache.org/xerces2-j/faq-general.html#faq-3
  [5]: http://web.archive.org/web/20140113103608/http://swordsystems.com/2011/06/29/xerces-and-xml-api-dependency-hell/
  [6]: http://i.stack.imgur.com/Fe9Xa.png
  [7]: http://i.stack.imgur.com/4X1ts.png
  [8]: https://issues.apache.org/jira/browse/XERCESJ-1454

Dealing with &quot;Xerces hell&quot; in Java/Maven?

Recently I switched to the Java 11 and start to debug my app and saw this message:

&gt; OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot
&gt; loader classes because bootstrap classpath has been appended

Found only [this commit][1] and [ticket][2], but it doesn&#39;t tell me much. 

Do I need to worry about it?


  [1]: http://hg.openjdk.java.net/jdk/jdk/rev/18fba780c1d1
  [2]: https://bugs.openjdk.java.net/browse/JDK-8203031

How to avoid &quot;Sharing is only supported for boot loader classes because bootstrap classpath has been appended&quot; warning during debug with Java 11?

I know this may be a silly question for experienced coders. But I have a library (an http client) that some of the other frameworks/jars used in my project require. But all of them require different major versions like:

    httpclient-v1.jar =&gt; Required by cralwer.jar
    httpclient-v2.jar =&gt; Required by restapi.jar
    httpclient-v3.jar =&gt; required by foobar.jar

Is the classloader intelligent enough to seperate them somehow? Most likely not? How does the Classloader handle this, in case a Class is the same in all three jars. Which one is loaded and why? 

Does the Classloader only pickup exactly one jar or does it mix classes arbitrarily? So for example if a class is loaded from Version-1.jar, all other classes loaded from the same classloader will all go into the same jar? 

How do you handle this problem?

Is there some trick to somehow &quot;incorporate&quot; the jars into the &quot;required.jar&quot; so that the are seen as &quot;one unit/package&quot; by the `Classloader`, or somehow linked?


Java, Classpath, Classloading =&gt; Multiple Versions of the same jar/project

Is there a way in Java to construct a `File` instance on a resource retrieved from a jar through the classloader?

My application uses some files from the jar (default) or from a filesystem directory specified at runtime (user input). I&#39;m looking for a consistent way of&lt;br /&gt;
a) loading these files as a stream&lt;br /&gt;
b) listing the files in the user-defined directory or the directory in the jar respectively

Edit: Apparently, the ideal approach would be to stay away from `java.io.File` altogether. Is there a way to load a directory from the classpath and list its contents (files/entities contained in it)?

Java resource as File

I have a JAR file and I need to get the name of all classes inside this JAR file. How can I do that?

I googled it and saw something about JarFile or Java `ClassLoader` but I have no idea how to do it.


How to get names of classes inside a jar file?

I am using Maven in my standalone application, and I want to package all the dependencies in my JAR file inside a library folder, as mentioned in one of the answers here:

*https://stackoverflow.com/questions/574594/how-can-i-create-an-executable-jar-with-dependencies-using-maven*

I want my final JAR file to have a library folder that contains the dependencies as JAR files, not like what the `maven-shade-plugin` that puts the dependencies in the form of folders like the Maven hierarchy in the .m2 folder.

Well, actually the current configuration does what I want, but I am having a problem with loading the JAR files when running the application. I can&#39;t load the classes.

Here&#39;s my configuration:

&lt;!-- language: xml --&gt;

    &lt;plugins&gt;

        &lt;plugin&gt;
            &lt;groupId&gt;org.apache.maven.plugins&lt;/groupId&gt;
            &lt;artifactId&gt;maven-dependency-plugin&lt;/artifactId&gt;
            &lt;executions&gt;
                &lt;execution&gt;
                    &lt;id&gt;copy-dependencies&lt;/id&gt;
                    &lt;phase&gt;prepare-package&lt;/phase&gt;
                    &lt;goals&gt;
                        &lt;goal&gt;copy-dependencies&lt;/goal&gt;
                    &lt;/goals&gt;
                    &lt;configuration&gt;
                        &lt;outputDirectory&gt;${project.build.directory}/classes/lib&lt;/outputDirectory&gt;
                        &lt;overWriteReleases&gt;false&lt;/overWriteReleases&gt;
                        &lt;overWriteSnapshots&gt;false&lt;/overWriteSnapshots&gt;
                        &lt;overWriteIfNewer&gt;true&lt;/overWriteIfNewer&gt;
                    &lt;/configuration&gt;
                &lt;/execution&gt;
            &lt;/executions&gt;
        &lt;/plugin&gt;

        &lt;plugin&gt;
            &lt;groupId&gt;org.apache.maven.plugins&lt;/groupId&gt;
            &lt;artifactId&gt;maven-jar-plugin&lt;/artifactId&gt;
            &lt;configuration&gt;
                &lt;archive&gt;
                    &lt;manifest&gt;
                        &lt;addClasspath&gt;true&lt;/addClasspath&gt;
                        &lt;classpathPrefix&gt;lib/&lt;/classpathPrefix&gt;
                        &lt;mainClass&gt;com.myapp.MainClass&lt;/mainClass&gt;
                    &lt;/manifest&gt;
                &lt;/archive&gt;
            &lt;/configuration&gt;
        &lt;/plugin&gt;

        &lt;plugin&gt;
            &lt;groupId&gt;org.apache.maven.plugins&lt;/groupId&gt;
            &lt;artifactId&gt;maven-compiler-plugin&lt;/artifactId&gt;
            &lt;configuration&gt;
                &lt;source&gt;1.6&lt;/source&gt;
                &lt;target&gt;1.6&lt;/target&gt;
            &lt;/configuration&gt;
        &lt;/plugin&gt;

        &lt;plugin&gt;
            &lt;groupId&gt;org.apache.maven.plugins&lt;/groupId&gt;
            &lt;artifactId&gt;maven-dependency-plugin&lt;/artifactId&gt;
            &lt;executions&gt;
                &lt;execution&gt;
                    &lt;id&gt;install&lt;/id&gt;
                    &lt;phase&gt;install&lt;/phase&gt;
                    &lt;goals&gt;
                        &lt;goal&gt;sources&lt;/goal&gt;
                    &lt;/goals&gt;
                &lt;/execution&gt;
            &lt;/executions&gt;
        &lt;/plugin&gt;

        &lt;plugin&gt;
            &lt;groupId&gt;org.apache.maven.plugins&lt;/groupId&gt;
            &lt;artifactId&gt;maven-resources-plugin&lt;/artifactId&gt;
            &lt;version&gt;2.5&lt;/version&gt;
            &lt;configuration&gt;
                &lt;encoding&gt;UTF-8&lt;/encoding&gt;
            &lt;/configuration&gt;
        &lt;/plugin&gt;

    &lt;/plugins&gt;

The project runs fine from Eclipse, and the JAR files are put in the library folder inside my final JAR file as I want, but when running the final JAR file from the target folder I always get `ClassNotFoundException`:

    Exception in thread &quot;main&quot; java.lang.NoClassDefFoundError: org/springframework/context/ApplicationContext
    Caused by: java.lang.ClassNotFoundException: org.springframework.context.ApplicationContext
            at java.net.URLClassLoader$1.run(Unknown Source)
            at java.security.AccessController.doPrivileged(Native Method)
            at java.net.URLClassLoader.findClass(Unknown Source)
            at java.lang.ClassLoader.loadClass(Unknown Source)
            at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
            at java.lang.ClassLoader.loadClass(Unknown Source)
    Could not find the main class: com.myapp.MainClass. Program will exit.

How can I fix this exception?


How do I put all required JAR files in a library folder inside the final JAR file with Maven?

When dynamically loading a class, when is it appropriate to use

    Class.forName(&quot;SomeClass&quot;);

and when should I use 

    ClassLoader.getSystemClassLoader().loadClass(&quot;SomeClass&quot;);

Or, are they two ways of doing the same thing?

Class.forName() vs ClassLoader.loadClass() - which to use for dynamic loading?

So as of yesterday morning I hadn&#39;t a clue as to what OSGi even was. *OSGi* was just some buzzword that I kept seeing cropping up over and over again, and so I finally set aside some time to brush up on it.

It actually seems like pretty cool stuff, so I&#39;d like to start off by stating (for the record) that I&#39;m not anti-OSGi in any respect, nor is this is some &quot;OSGi-bashing&quot; question.

At the end of the day, it seems that OSGi has - essentially - addressed [JSR 277](http://www.jcp.org/en/jsr/detail?id=277) on Java Modularity, which recognized that there are shortcomings with the `JAR` file specification that can lead to namespace resolution and classloading issues in certain corner cases. OSGi also does a lot of other really cool stuff, but from what I can ascertain, that&#39;s its biggest draw (or one of them).

To me - as a fairly new (a few years now) Java EE developer, it is absolutely mind-boggling that we are in the year 2011 and currently living in the era of Java 7, and that these classloading issues are still present; particularly in enterprise environments where one app server could have hundreds of JARs on it, with many of them depending on different versions of one another and all running (more or less) concurrently.

**My question:**

As interested as I am in OSGi, and as much as I want to start learning about it to see where/if it could be of use to my projects, I just don&#39;t have the time to sit down and learn something that large, at least now.

**So what are non-OSGi developers to do when these problems arise?** What **Java** (Oracle/Sun/JCP) solutions currently exist, if any? Why was Jigsaw cut from J7? How sure is the community that Jigsaw will get implemented next year in J8? Is it possible to get Jigsaw for your project even though its not a part of the Java platform yet?

I guess what I&#39;m asking here is a combination of panic, intrigue and a facepalm. Now that I finally understand what OSGi is, I just don&#39;t &quot;get&quot; how something like Jigsaw has taken 20+ years to come to fruition, and then how that could have been canned from a release. **It just seems fundamental.** 

And, as a developer, I am also curious as to what my solutions are, sans OSGi.

Also, **Note**: I know this isn&#39;t a &quot;*pure programming*&quot;-type question, but before some of you get your noses bent out of shape, I wanted to state (again, for the record) that I deliberately put this question on SO. That&#39;s because I have nothing but the utmost respect for my fellow SOers and I&#39;m looking for an architectural-level answer from some of the &quot;Gods of IT&quot; that I see lurking around here every day.

But, for those of you who absolutely *insist* that a SO question be backed with some code segment:

    int x = 9;

(Thanks to anybody who can weigh-in on this OSGi/Jigsaw/classloader/namespace/JAR hell stuff!)

OSGi, Java Modularity and Jigsaw

How can I use `ClassLoader.getResources()` to find recursivly resources from my classpath?

E.g. 

- finding all resources in the `META-INF` &quot;directory&quot;:
  Imagine something like 

  `getClass().getClassLoader().getResources(&quot;META-INF&quot;)`

 Unfortunately, this does only retrieve an `URL` to exactly this &quot;directory&quot;.

- all resources named `bla.xml` (recursivly)

  `getClass().getClassLoader().getResources(&quot;bla.xml&quot;)`

 But this returns an empty `Enumeration`.

And as a bonus question: How does `ClassLoader.getResources()` differ from `ClassLoader.getResource()`?





How to use ClassLoader.getResources() correctly?

I have 2 jars, let&#39;s call them a.jar and b.jar.

b.jar depends on a.jar.

In a.jar, I defined a class, let&#39;s call it StaticClass. In the StaticClass, I defined a static block, calling a method named &quot;init&quot; : 

    public class StaticClass {
      static {
        init();
      } 
    
      public void static init () {
        // do some initialization here
      }
    }

in b.jar, I have a main, so in the main, I expect that the init() method has been called, but actually not. I suspect that is because the StaticClass has not been loaded by the jvm, could anyone tell me

 1. Is my conclusion correct? 
 2. What triggers the jvm to load a class?
 3. How can I get the static block executed automatically?

Thanks

When is the static block of a class executed?

I was asked to build a java system that will have the ability to load new code (expansions) while running. 
How do I re-load a jar file while my code is running? or how do I load a new jar?

Obviously, since constant up-time is important, I&#39;d like to add the ability to re-load existing classes while at it (if it does not complicate things too much).

What are the things I should look out for?
(think of it as two different questions - one regarding reloading classes at runtime, the other regarding adding new classes).


How to load a jar file at runtime

Is there any way to make an Android application to download and use a Java library at runtime? 

Here is an example:

Imagine that the application needs to make some calculations depending on the input values. The application asks for these input values and then checks if the required `Classe`s or `Method`s are available. 

If not, it connects to a server, downloads the needed library, and loads it at runtime to calls the required methods using reflection techniques. The implementation could change depending on various criteria such as the user who is downloading the library.

Is it possible to dynamically load a library at runtime from an Android application?

I am trying to list the order in which the Java class loader is loading my classes. if I use `-verbose` parameter it will list every single interface/class it loads, including tons of interfaces such as Serializable, exceptions etc. Is there a way to tweak this output so it only shows which classes are loaded in the class my main method is defined?

Java verbose class loading

If I use
 
       try {
          Class.forName(&quot;my.package.Foo&quot;);
          // it exists on the classpath
       } catch(ClassNotFoundException e) {
          // it does not exist on the classpath
       }

the static initializer block of &quot;Foo&quot; is kicked off. Is there a way to determine whether a class &quot;my.package.Foo&quot; is on the classpath without kicking off its static initializer?

Check if class exists in Java classpath without running its static initializer?

I am just now beginning to learn the internal architecture of Java. I have roughly understood the concept of class loading which loads the required classes when `jvm` runs, `ClassNotFoundException` is thrown when a class is not found and specific class loader loads the classes referenced by the class. 

Can someone please explain clearly the flow of class loading i.e. the sequence of bootstrap class loading and user-defined class loading in the sample Java code below.

    import java.io.File;
    public class Sample
    {
        public static void main(String[] args)
        {
            String fileName = &quot;sample&quot;;
            File file = new File(fileName);
            file.isFile();
        }
    } 


Also I learnt from a reference material that &quot;`classloader` maintains the namespaces of the classes it loads&quot;. By namespaces, does that mean the literal names of the class? Also can someone please explain the implication/advantage of that?

Flow of class loading for a simple program

Why is it so hard to do this in Java? If you want to have any kind of module system you need to be able to load JAR files dynamically. I&#39;m told there&#39;s a way of doing it by writing your own `ClassLoader`, but that&#39;s a lot of work for something that should (in my mind at least) be as easy as calling a method with a JAR file as its argument.

Any suggestions for simple code that does this?

How to load JAR files dynamically at Runtime?

I&#39;m having trouble when one of the jars that my web app depends on tries to load a properties file from within the jar.  Here is the code in the jar.

	static
	{
		Properties props = new Properties();
        try 
        {
			props.load(ClassLoader.getSystemResourceAsStream(&quot;someProps.properties&quot;));
		} catch (IOException e) 
		{
			e.printStackTrace();
		}
		someProperty = props.getProperty(&quot;someKey&quot;);
	}

The properties file is in my &quot;src/main/resources&quot; directory of the Maven project.  When I run this code from my junit test in Eclipse, it executes just fine.  When the project is built with Maven into a jar, and included as a dependency in my web app, it fails to locate the properties file.  I know that the properties file is at the base directory of the depended on jar, I don&#39;t know how to fix this.

Load properties file in JAR?

Developing a heavily XML-based Java-application, I recently encountered an interesting problem on Ubuntu Linux.

My application, using the &lt;a href=&quot;http://jpf.sourceforge.net/&quot;&gt;Java Plugin Framework&lt;/a&gt;, appears unable to convert a &lt;a href=&quot;http://www.dom4j.org/&quot;&gt;dom4j&lt;/a&gt;-created XML document to &lt;a href=&quot;http://xmlgraphics.apache.org/batik/&quot;&gt;Batik&#39;s&lt;/a&gt; implementation of the SVG specification.

On the console, I learn that an error occurs:
&lt;pre&gt;
Exception in thread &quot;AWT-EventQueue-0&quot; java.lang.LinkageError: loader constraint violation in interface itable initialization: when resolving method &quot;org.apache.batik.dom.svg.SVGOMDocument.createAttribute(Ljava/lang/String;)Lorg/w3c/dom/Attr;&quot; the class loader (instance of org/java/plugin/standard/StandardPluginClassLoader) of the current class, org/apache/batik/dom/svg/SVGOMDocument, and the class loader (instance of &amp;lt;bootloader&amp;gt;) for interface org/w3c/dom/Document have different Class objects for the type org/w3c/dom/Attr used in the signature
    at org.apache.batik.dom.svg.SVGDOMImplementation.createDocument(SVGDOMImplementation.java:149)
    at org.dom4j.io.DOMWriter.createDomDocument(DOMWriter.java:361)
    at org.dom4j.io.DOMWriter.write(DOMWriter.java:138)
&lt;/pre&gt;

I figure that the problem is caused by a conflict between the original classloader from the JVM and the classloader deployed by the plugin framework.

To my knowledge, it&#39;s not possible to specify a classloader for the framework to use. It might be possible to hack it, but I would prefer a less aggressive approach to solving this problem, since (for whatever reason) it only occurs on Linux systems.

Has one of you encountered such a problem and has any idea how to fix it or at least get to the core of the issue?

How to deal with LinkageErrors in Java?

I have created a minimal maven project with a single child module in eclipse helios.

In the src/test/resources folder I have put a single file &quot;install.xml&quot;. In the folder src/test/java I have created a single package with a single class that does:

      @Test
      public void doit() throws Exception {
        URL url = this.getClass().getClassLoader().getResource(&quot;install.xml&quot;);
        System.out.println(url.getPath());
    
      }

but when I run the code as a junit 4 unit test I just get a NullPointerException. This has worked fine a million of times before. Any ideas?

I have followed this guide:

http://www.fuyun.org/2009/11/how-to-read-input-files-in-maven-junit/

but still get the same error.

this.getClass().getClassLoader().getResource(&quot;...&quot;) and NullPointerException

I&#39;ve got an interesting problem in which the org.apache.log4j.Logger class is not found during runtime. I&#39;m trying to get authorized and that is where it&#39;s failing:

`OAuthAuthorizer oauthAuthorizer = new OAuthAuthorizer(OAUTH_CONSUMER_KEY, OAUTH_CONSUMER_SECRET, SAML_PROVIDER_ID, userId);`

I&#39;m using JDeveloper 11.1.1.6. Here is what I know:

1. I&#39;ve looked in my UI.war/WEB-INF/lib directory and I see the log4j-1.2.17.jar there.

2. The class complaining about it is org.opensaml.xml.XMLConfigurator

        Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Logger
        	at org.opensaml.xml.XMLConfigurator.&lt;clinit&gt;(XMLConfigurator.java:60)
        	at org.opensaml.DefaultBootstrap.initializeXMLTooling(DefaultBootstrap.java:195)
        	at org.opensaml.DefaultBootstrap.bootstrap(DefaultBootstrap.java:91)
        	at com.intuit.ipp.aggcat.util.SAML2AssertionGenerator.getSAMLBuilder(SAML2AssertionGenerator.java:156)
        	at com.intuit.ipp.aggcat.util.SAML2AssertionGenerator.createSubject(SAML2AssertionGenerator.java:187)
        	at com.intuit.ipp.aggcat.util.SAML2AssertionGenerator.buildAssertion(SAML2AssertionGenerator.java:114)
        	at com.intuit.ipp.aggcat.util.SAML2AssertionGenerator.generateSignedAssertion(SAML2AssertionGenerator.java:83)
        	at com.intuit.ipp.aggcat.util.SamlUtil.createSignedSAMLPayload(SamlUtil.java:156)
        	at com.intuit.ipp.aggcat.util.OAuthUtil.getOAuthTokens(OAuthUtil.java:60)
        	at com.intuit.ipp.aggcat.core.OAuthAuthorizer.&lt;init&gt;(OAuthAuthorizer.java:85)
        	at com.incomemax.view.intuit.WebUtil.getAggCatService(WebUtil.java:91)

    &lt;!-- --&gt;

        Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Logger
        	at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
        	at java.security.AccessController.doPrivileged(Native Method)
        	at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
        	at java.lang.ClassLoader.loadClass(ClassLoader.java:305)
        	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
        	at java.lang.ClassLoader.loadClass(ClassLoader.java:246)
        	... 64 more

3. I decomplied XMLConfigurator and oddly it doesn&#39;t import org.apache.log4j.Logger It uses org.slf4j.Logger which is also in my jars directory (slf4j-api-1.7.5.jar). Also interesting is that line 60 (see stack trace) is a blank line in my decompile.

4. Of course if I add Logger.xxxxx during design time, it finds it just fine.

5. I&#39;m using the code/jars directly from the sample java code, but imported into my existing application.

I&#39;ve been scouring the web for answers and I believe I&#39;ve checked all the areas I can think of. I also referenced this very good page: http://myarch.com/classnotfound/

Given authorization is step 1 in using the Intuit Developer API, I&#39;m kinda stuck.

Adding output from @jhadesdev suggestion:

All versions of log4j Logger: 

- zip:C:/Users/Chris/AppData/Roaming/JDeveloper/system11.1.1.6.38.61.92/DefaultDomain/servers/DefaultServer/tmp/_WL_user/j2ee-app/lt5l71/war/WEB-INF/lib/log4j-1.2.17.jar!/org/apache/log4j/Logger.class

All versions of log4j visible from the classloader of the OAuthAuthorizer class: 

- zip:C:/Users/Chris/AppData/Roaming/JDeveloper/system11.1.1.6.38.61.92/DefaultDomain/servers/DefaultServer/tmp/_WL_user/j2ee-app/lt5l71/war/WEB-INF/lib/log4j-1.2.17.jar!/org/apache/log4j/Logger.class

All versions of XMLConfigurator: 

- jar:file:/C:/Oracle/Middleware11116/modules/com.bea.core.bea.opensaml2_1.0.0.0_6-1-0-0.jar!/org/opensaml/xml/XMLConfigurator.class

- zip:C:/Users/Chris/AppData/Roaming/JDeveloper/system11.1.1.6.38.61.92/DefaultDomain/servers/DefaultServer/tmp/_WL_user/j2ee-app/lt5l71/war/WEB-INF/lib/ipp-java-aggcat-v1-devkit-1.0.2.jar!/org/opensaml/xml/XMLConfigurator.class

- zip:C:/Users/Chris/AppData/Roaming/JDeveloper/system11.1.1.6.38.61.92/DefaultDomain/servers/DefaultServer/tmp/_WL_user/j2ee-app/lt5l71/war/WEB-INF/lib/xmltooling-1.3.1.jar!/org/opensaml/xml/XMLConfigurator.class

All versions of XMLConfigurator visible from the class loader of the OAuthAuthorizer class:

- jar:file:/C:/Oracle/Middleware11116/modules/com.bea.core.bea.opensaml2_1.0.0.0_6-1-0-0.jar!/org/opensaml/xml/XMLConfigurator.class

- zip:C:/Users/Chris/AppData/Roaming/JDeveloper/system11.1.1.6.38.61.92/DefaultDomain/servers/DefaultServer/tmp/_WL_user/j2ee-app/lt5l71/war/WEB-INF/lib/ipp-java-aggcat-v1-devkit-1.0.2.jar!/org/opensaml/xml/XMLConfigurator.class

- zip:C:/Users/Chris/AppData/Roaming/JDeveloper/system11.1.1.6.38.61.92/DefaultDomain/servers/DefaultServer/tmp/_WL_user/j2ee-app/lt5l71/war/WEB-INF/lib/xmltooling-1.3.1.jar!/org/opensaml/xml/XMLConfigurator.class

I&#39;m still working on interpreting the results.

All Classloader Solutions on Gang of Coders

Total of 30 Classloader Solutions