Develop Reference

PsiClass to java.lang.Class

I'm developing plugin for IntelliJ IDEA. How can plugin get the name and version of libraries that are imported to the project that is being checked by plugin? I have PsiClass of the project, but cannot convert it to java.lang.Class. Maybe there's the way to get ClassLoader from PsiElement?
super.visitImportStatement(psiImport);
Class importedClass = Class.forName(psiImport.getQualifiedName(), true, psiImport.getClass().getClassLoader());
PsiImport.getClass().GetClassLoader() - returns ClassLoader of class PsiImportStatementImpl instead of ClassLoader of class that I've imported.

IntelliJ does mostly static analysis on your code. In fact, the IDE and the projects you run/debug have completely different classpaths. When you open a project, your dependencies are not added to the IDE classpath. Instead, the IDE will index the JARs, meaning it will automatically discover all the declarations (classes, methods, interfaces etc) and save them for later in a cache.
When you write code in your editor, the static analysis tool will leverage the contents of this index to validate your code and show errors when you're trying to use unknown definitions for example.
On the other hand, when you run a Main class from your project, it will spawn a new java process that has its own classpath. This classpath will likely contain every dependency declared in your module.
Knowing this, you should now understand why you can't "transform" a PsiClass to a corresponding Class.
Back to your original question:
How can plugin get the name and version of libraries that are imported to the project that is being checked by plugin?
You don't need to access Class objects for this. Instead, you can use IntelliJ SDK libraries. Here's an example:
Module mod = ModuleUtil.findModuleForFile(virtualFile,myProject);
ModuleRootManager.getInstance(mod).orderEntries().forEachLibrary(library -> {
// do your thing here with `library`
return true;
});

com.sun.imageio.plugins.jpeg.JPEGImageReader no longer part of JDK-11

I am trying to migrate a project from JDK8 to JDK11, the issue is that most of the things are no longer part of JDK11 as they used to be in JDK8.
There are some separated jars that I had to add manually due removal of those packages from JDK11, but one issue remains.
The import com.sun.imageio.plugins.jpeg.JPEGImageReader; is no longer part of JDK11 and I am not able to find proper replacement or dependency in order to provide to my code so it can work as it used to.
I've visited docs https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/javax/imageio/package-summary.html but they do not seem like a proper replacement
InputStream iccProfileStream = JPEGImageReader.class.getResourceAsStream("/ISOcoated_v2_300_eci.icc");
//the JPEGImageReader is completely red due missing jar that was removed from JDK11
cmykProfile = ICC_Profile.getInstance(iccProfileStream);
iccProfileStream.close();
Code should compile as it used to do on JDK8 but instead, it keeps popping an error "package com.sun.imageio.jpeg is not visible (package com.sun.imageio.plugins.jpeg is declared in module java.desktop, which does not export it )"

It doesn't seem that you even need that class, at least based on the code you're showing.
Instead of JPEGImageReader.class.getResourceAsStream(.., you can use any Class object as long as it's in the suitable classloading context. The getResourceAsStream method exists in the Class class.
Replace it with getClass().getResourceAsStream(.. and that part of the code will work just fine.

Can I force the order of dependencies in my classpath with Gradle?

A project runs on Google App Engine. The project has dependency that uses a class that can't be invoked on App Engine due to security constraints (it's not on the whitelist). My (very hacky) solution was to just copy a modified version of that class into my project (matching the original Class's name and package) that doesn't need the restricted class. This works on both dev and live, I assume because my source appears in the classpath before my external dependencies.
To make it a bit cleaner, I decided to put my modified version of that class into it's own project that can be packaged up in a jar and published for anyone else to use should they face this problem.
Here's my build.gradle:
// my jar that has 'fixed' version of Class.
compile files('path/to/my-hack-0.0.1.jar')
// dependency that includes class that won't run on appengine
compile 'org.elasticsearch:elasticsearch:1.4.4'
On my local dev server, this works fine, the code finds my hacked version of the class first at runtime. On live, for some unknown reason, the version in the elasticsearch dependency is loaded first.
I know having two versions of the same class in the classpath isn't ideal but I was hoping I could reliably force my version to be at the start of the classpath. Any ideas? Alternatively, is there a better way to solve this problem?

Not really sure if this is what people visiting this question were looking for, but this was what my problem and a solution that I reached at.
Jar A: contains class XYZ
Jar B: also contains class XYZ
My Project needs Jar B on the classpath before Jar A to be able to get compiled.
Problem is Gradle sorts the dependencies based on alphabetical order post resolving them which meant Jar B will be coming after Jar A in the generated classpath leading to error while compiling.
Solution:
Declare a custom configuration and patch the compileClasspath. This is how the relevant portion of build.gradle might look like.
configurations {
priority
sourceSets.main.compileClasspath = configurations.priority + sourceSets.main.compileClasspath
}
dependencies {
priority 'org.blah:JarB:2.3'
compile 'org.blah:JarA:2.4'
...
}

It's the app engine classloader I should have been investigating, not gradle...
App Engine allows you to customise the class loader JAR ordering with a little bit of xml in your appengine-web.xml. In my case:
<class-loader-config>
<priority-specifier filename="my-hack-0.0.1.jar"/>
</class-loader-config>
This places my-hack-0.0.1.jar as the first JAR file to be searched for classes, barring those in the directory war/WEB-INF/classes/.
...Thanks to a nudge in the right direction from #Danilo Tommasina :)
UPDATE 2020:
I just hit the same problem again and came across my own question... This time, live appengine was loading a different version of org.json than was being loaded in dev. Very frustrating and no amount of fiddling the build script would fix it. For future searchers, if you're getting this:
java.lang.NoSuchMethodError: org.json.JSONObject.keySet()Ljava/util/Set;
It's because it's loading an old org.json dependency from god-knows-where. I fixed it by adding this to my appengine-web.xml:
<class-loader-config>
<priority-specifier filename="json-20180130.jar"/>
</class-loader-config>
You'll also need a matching dependency in build.gradle if you don't already have one:
compile 'org.json:json:20180130'

According to gradle dependencies documentation, the order of dependencies defines the order in the classpath. So, we can simply put the libraries in the correct order in "dependencies".
But beware! here are two rules with higher priorities:
For a dynamic version, a 'higher' static version is preferred over a 'lower' version.
Modules declared by a module descriptor file (Ivy or POM file) are preferred over modules that have an artifact file only.

NoSuchMethodError after cleaning the project

I'm currently getting this error:
java.lang.NoSuchMethodError: org.json.JSONObject.keySet()Ljava/util/Set;
at ee.ut.cs.Parser.accessLint(Parser.java:39)
I have tried cleaning the project to no awail.
I suspect I have an error in the src/plugin/parse-htmlraw/build.xml while creating the jar file but I'm not certain. I understand that this error is because the function does not exist at runtime, but the object is created which means that the class is there, just not that function. I decompiled the .class file in created jar and it has the necessary functions.
Code is available at https://github.com/jaansusi/WCAGgrader
Q: What is wrong with the build that produces this error?
The problem is that even if I put the necessary class files in the jar I create, they are not linked correctly and the class that's called in the jar can't locate functions inside the other classes. The class object JSONObject is created but the functions inside the JSONObject class can't be found.

If you do not find the problematic version, there is a possibility you get it (especially if you are using Spring) from the following dependency -
<artifactId>android-json</artifactId>
<groupId>com.vaadin.external.google</groupId>
excluding it worked for me,
An easy way of analyzing dependencies is the maven-helper plugin in Intellij, see here

Check for the version you have used.
There might be a case where 2 different versions are being used which in turn causes this error.

To their own maven local repository com\Google\code\gson\gson, see if there are two or more version about json, will have to do is to delete the old, and remember to look at any other place in the project is introduced into the old version of the dependence, if any, change the old version of the dependence to the new version is perfectly solved this problem

Find duplicated classes in classpath

I have a Java application built with Maven with a lot of dependencies. When performing my test cases they sometimes pass fine, sometimes they fail because of some incompatible class combinations. So it seems to that there must be some classes twice in classpath which are taken randomly. The one is fine the other not.
How can I find out which classes / jars are incompatible in my classpath?
What is the right approach using Maven not to fall in that compatibility-traps?

I think a better solution would be to use the maven-duplicate-finder-plugin.
Note: The new version is the duplicate-finder-maven-plugin.

You can try using this tool Tattletale.

You can detect duplicate classfile definitions in the classpath or module path using ClassGraph (disclaimer, I am the author of ClassGraph):
for (Entry<String, ResourceList> dup :
new ClassGraph().scan().getAllResources().classFilesOnly().findDuplicatePaths()) {
System.out.println(dup.getKey()); // Classfile path
for (Resource res : dup.getValue()) {
System.out.println(" -> " + res.getURI()); // Resource URI, showing classpath element
}
}

There is a plugin in eclipse to check for duplicate classes in the build path (ClasspathChecker http://classpathchecker.free.fr/)

This problem is basically an application of the more general problem to "somehow scan the classpath (CP) and collect all class files and other resources", and then find duplicates in that...
There are a number of existing libraries for CP scanning (and it's not trivial to do this right in all environments, especially since the application class loader in Java 9 is no longer an URLClassLoader), notably Classgraph, using which it's relatively trivial to do this.
PS: For Java versions <9, JHades (jhades.github.io) is nice (but NOK on Java 9/10/11).

This is a another simple Open Source Duplicate Classpath Finder tool - Classpath Inspector
which gives pretty decent report of duplicate classes in the classpath.

You can use the maven dependency:tree to see the maven hierarchy of your project and
maven exclusion to exclude the jars you don't want