Implementation Class: Importing of operations might fail

[Matthias Schoettle]

Importing of operations might cause a NoClassDefFoundException, which causes TouchCORE to crash.

To reproduce:

• Import Selenium JAR: client-combined-3.0.1-nodeps.jar
• Import interface class org.openqa.selenium.WebDriver.
• Select Add operation for this interface

Result:

[...]
Caused by: java.lang.NoClassDefFoundError: org/openqa/selenium/By
    at java.lang.Class.getDeclaredMethods0(Native Method)
    at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
    at java.lang.Class.privateGetPublicMethods(Class.java:2902)
    at java.lang.Class.getMethods(Class.java:1615)
    at ca.mcgill.sel.ram.ui.views.structural.handler.impl.ImplementationClassViewHandler.getAllSelectableMethods(ImplementationClassViewHandler.java:239)
    at ca.mcgill.sel.ram.ui.views.structural.handler.impl.ImplementationClassViewHandler.createOperation(ImplementationClassViewHandler.java:71)
    [...]
Caused by: java.lang.ClassNotFoundException: org.openqa.selenium.By
    at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    ... 53 more

It looks like this is caused, because when RamClassLoader.findClass(String) is done looking for the class using the URLClassLoader, it closes it (otherwise there's a warning of a potential resource leak). However, on that Class, getMethods() is called and there is no class loader for any of the referenced classes within the methods.

I am not sure, however, why it works for other libraries, such as Minueto.

I see two options:

• close the URLClassLoader later (on exit or something), however, if new JARs are added it needs to be re-initialized for all of them
• delegate retrieval of methods to the RamClassLoader, which allows to initialize a URLClassLoader before calling getMethods() and it can be closed right after (like it is done for retrieval of classes)

Tagged as Introduction as it could be used for more advanced issues after doing some smaller issues beforehand.

[Matthias Schoettle]

Option #2 is the way this should be resolved.

[Matthias Schoettle]

References #467: Improves exception handling when the class loader fails to load a class.

Instead of exposing internal exceptions to the caller, only MissingJarException is thrown now which needs to be handled by the caller only. The exception contains the class name and is now used within the error message that is going to be displayed to the user.

→ <<cset 1f4d9c939c72>>

[Matthias Schoettle]

References #467: Moves retrieval of methods and constructors to the class loader.

The class loader now is responsible for retrieving all elements. Therefore, the used URLClassLoader can be automatically closed. The JARs will be used for retrieval of methods and constructors as well.

Another potential improvement could be to move the wrappers into the class loader project instead of the handlers having to do this specifically.

→ <<cset 46d94924dd59>>