Add ClassLoader to CompileOptions in order to allow for overriding the ClassLoader

[vksiva]

Expected behavior and actual behavior:

Using the example as presented in the README,

Supplier<String> supplier = Reflect.compile(
    "com.example.HelloWorld",
    "package com.example;\n" +
    "class HelloWorld implements java.util.function.Supplier<String> {\n" +
    "    public String get() {\n" +
    "        return \"Hello World!\";\n" +
    "    }\n" +
    "}\n").create().get();

// Prints "Hello World!"
System.out.println(supplier.get());

If the text has to be changed to "Hi World!" and the class is recompiled, the below code still prints "Hello World!"

 supplier = Reflect.compile(
    "com.example.HelloWorld",
    "package com.example;\n" +
    "class HelloWorld implements java.util.function.Supplier<String> {\n" +
    "    public String get() {\n" +
    "        return \"Hi World!\";\n" +
    "    }\n" +
    "}\n").create().get();

// Still prints "Hello World!"
System.out.println(supplier.get());

One way to ensure the class gets recompiled is by using different classloaders during compile. Can we use a custom classloader for the Reflect.compile() method. It was raised in #64.

Steps to reproduce the problem:

Mentioned above.

Versions:

• jOOR: 0.9.9
• Java: 1.8

[lukaseder]

Thanks for reporting this. Indeed, we've solved this in the next release through #67

[lukaseder]

In fact, no. CompileOptions does not allow for overriding the ClassLoader yet. Will look into this soon. There are tons of open questions when doing that, of course. The current approach allows for some additional visibility to be implemented, from the very location of where the class is being compiled. With arbitrary class loaders, this will no longer be true.

Further investigation needed.

[lukaseder]

The custom class loader feature has been implemented. But I will also implement a breaking change that avoids re-loading a previously compiled class by default. I don't think that's what anyone really wants. See #76

[lukaseder]

Hmm, no in fact #76 cannot be implemented. The current implementation prevents LinkageError in some cases.

[lukaseder]

I will revert this change. Unfortunately, providing a custom ClassLoader doesn't really help solve any problems in JDK 9+

[lukaseder]

This appears to be useful for jOOQ's code generator as well, including for:

• Support ad-hoc compilation of programmatic GeneratorStrategy objects in the code generator jOOQ#15209
• Support ad-hoc compilation of programmatic Generator or Database objects in the code generator jOOQ#15213

A quick attempt at re-implementing this seems to work for jOOQ (whose code generation plugin creates its own URLClassLoader). Perhaps I just made a mistake when implementing the tests at the time?

I'll try this again.

[lukaseder]

Hmm, no in fact #76 cannot be implemented. The current implementation prevents LinkageError in some cases.

I'm no longer running into these errors from:
#72 (comment)

Perhaps that was a JDK bug, at the time?

[lukaseder]

Fixed for jOOR 0.9.15

[lukaseder]

Time for a release, too.