[testing] add dynamic class loader generation for tests

[glelouet]

I use a dynamic class loader that take a defined JCodeModel

It allows me to directly generate code and use it as java code. With reflection I can test if the result of the JCodeModel matched my goals.

simple example :

DynamicClassLoader dcl = DynamicClassLoader.generate(codemodel);
Class<?> cl = dcl.loadClass("my.package.CreatedClass");
cl.getFields();

The classes are here https://github.com/glelouet/tools/tree/master/Compilation/src/main/java/fr/lelouet/tools/compilation/inmemory
I don't use the loggers because they don't get used IIRC in the maven pre-compile phase (in which I actually personally use those classes)

My code is very ugly, because it just works when I need it (and that's it). Part are taken from other sites, much is made by myself.

[glelouet]

using this code I can use it to test eg #71 in that code :
https://github.com/glelouet/tools/blob/master/Compilation/src/test/java/fr/lelouet/tools/compilation/inmemory/TestEqualsObject.java

which results in
java.lang.AssertionError: expected [class java.lang.Object] but found [class my.pckg.Object]

Therefore demonstrating the issue.

[glelouet]

IMO the best way to do that, would be to make the base JCodeModel a pom module, with the current code in JCodeModel-core child, and another child JCodeModel-dynamic that depends on JCodeModel-core, and contains the code for dynamic classpath compilation. This is because the license of the dependencies I use may not be compatible with the JCodemodel license.

So to use the dynamic, one would need to add the JCodeModel-dynamic dependency in his maven.
I would had said to just use the dependency of my project but I don't intend to maintain it.

[phax]

Okay, so the base class are from https://github.com/trung/InMemoryJavaCompiler and your code is basically https://github.com/glelouet/tools/tree/master/Compilation - correct? Both are Apache 2 licensed?

[phax]

What about simply using Eclipse JDT?

[glelouet]

The goal is to provide the classes with a getClass() in order to make dynamic introspection tests

So

1. make your jcodemodel
2. convert it into a classloader
3. use this classloader's getClass to get the class
4. use reflect to work on the class definition post-compilation.

This also allows to dynamically make adapter for eg a webservice, assuming the bridge from the webservice definition uses correct interfaces and annotations.

The first time I used this, was to make a parser on a code that had both structural definitions and data in the same File.

eg the file was in yaml format, containing

1. definitions
2. data

I partially loaded the file(ignoring the data part), used the definitions to create the correct classes in a dynamic class loader, then parsed the yaml again with the classloader that contained the correct definitions. I then applied dynamic modifications on the parsed data, and used the class loader to export the modification.

The definitions contained not only structural data but also constraints to check. Thus I was not only creating the structures dynamically, but also the list of contraints to check for each of those structures, represented by a class that was called before the actual yaml export.

A part of the definitions were actually static along with their constraints, thus I had another maven project that was responsible of exporting the global definition to java classes, which were then extended as need by the converter, and could be used as basis for classes manipulation without reflection. eg if the common classes contained the definition of a "Firm", I could manipulate the firm of the code even though they had specific constraints, attributes, etc. because the dynamic classloader knew they were extending the Firm class.

It was like 4 years ago, I don't remember very well. All I know is, besides testing, there is a real case usage of dynamic compiling.

[glelouet]

I don't know what JDT are, and how they could do this. As I wrote, the goal is to designs tests in memory, not over files (because that could lead to errors in the test phase), so we NEED an in-memory class loader whose classes are built upon the JCodeModel.

I don't know about the licenses.In my case it's just bunch of code added together, so no licensing this specific small lines of codes (that would make no sense)

[phax]

Thanks @glelouet - I simply had no time yet to deal with that approach...

[glelouet]

I had guessed so. Just wanted to give the maximum things you may need in case you had a sudden surge of free time.

[guiguilechat]

I partially copied my code, and made it work with resources too. During the compilation phase, if it's a non-".java" file it's skipped form compilation and added directly to the classloader resources.

Still need to make the compiler be able to output data in a folder instad of the classloader.

I think something nice would be, to be able to write somthing like

jcm.write().to.file("src/generated/java/");//returns nothing.
jcm.write().to.jar("generatedSources.jar");//return nothing
jcm.write().with.encoding(UTF-8).to.memory();//returns the map of binaries
jcm.write().to.writer(mywriter);// return nothing
jcm.compile().to.memory();// return a new classloader
jcm.compile().with.sources().to.file("target/");

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[glelouet]

can we convert this issue into a discussion ?