Dont want to use Proxy Class

Hi,

We are trying convert our Java app into GraalVM native image. We are able to convert if we use simple persistable Java data types.

But if our entity contains  a collection that is stored as an instance of java.util.ArrayList, we are getting UserException that states "Failed to generate dynamic type objectdb.java.util.ArrayList...". From Objectdb developer's guide, this kind of persistable proxy classes may affect the app behaviour. 

I have been trying to understand root cause but I could not find anything so far. After native build operation, I am getting exception at defineClass call in d method ACL class which is triggerd by i method of STL class. I think the byte array for the extended ArrayList class could not be properly created. 

I have not tried newer versions yet but I think the result shall be the same as I stated above.

My first question is about disabling proxy behaviour and just use java.util.ArrayList instead of objectdb.java.util.ArrayList. Is it possible to do that.

The second one is about using another persistaable class which cannot trigger to use proxy usage.

Thanks a lot in advance

Best Regards

Serhat

After digging a little bit more, the main reason I think is about missing class definition of objectdb.java.util.ArrayList during the image build to load from bytecode at runtime. By using Feature api of SubstrateVM, I could see the paramString and size of paramArrayOfByte is not empty. This kind of runtime error appears when we use a class that contains some attributes  of type ArrayList, tried with vector ana the same result happened as well.

Thank you for this report. Apparently when you use GraalVM native images the expectation is that all the necessary classes will be available at build time. Therefore, using defineClass dynamically by ObjectDB, although it is a standard Java feature, is not supported.

The use of proxy classes such as objectdb.java.util.ArrayList cannot be disabled, as it is an essential feature that enables lazy partial load of the object graph. Without these classes the entire database may have to be loaded to memory.

We will check an option to generate these classes at build-time and include them in the objectdb.jar file to eliminate the need of dynamic class generation.