When Reflect.compile(...), if code executed has same ClassName as a previous execution, .class file is never overwritten

[ANLevant]

Expected behavior and actual behavior:

EXPECTED

//FIRST CALL!!!!
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());

//SECOND CALL!
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 \"ByeBye World!\";\n" +
    "    }\n" +
    "}\n").create().get();

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

ACTUAL

//FIRST CALL!!!!
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());

//SECOND CALL!
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 \"ByeBye World!\";\n" +
    "    }\n" +
    "}\n").create().get();

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

Steps to reproduce the problem:

1. Make a Reflect.compile(...) call
2. Make another Reflect.compile(...) call with changes on the class code BUT THE SAME CLASS NAME

Versions:

• jOOR:0.9.12
• Java: 1.8.0_261

[lukaseder]

Thanks for your request. This is a duplicate of https://github.com/jOOQ/jOOR/issues/72.

I agree we should offer a way to override the default behaviour of using the caller class loader in order to be able to re-define classes compiled with this API.