Usage of JBoss Marshalling incompatible with native compilation with GraalVM

BatchUtil class currently uses a org.jboss.marshalling.cloner.ObjectCloner. Native compilation yields this (the actual log is much longer and less readable, showing just the most important piece here)

Fatal error: com.oracle.graal.pointsto.util.AnalysisError$ParsingError: Error encountered while parsing org.jboss.marshalling.reflect.SerializableField.setShort(java.lang.Object, short) 
(...)
Caused by: com.oracle.svm.hosted.analysis.flow.SVMMethodTypeFlowBuilder$UnsafeOffsetError: Field AnalysisField<SerializableField.fieldOffset accessed: false reads: true written: true> is used as an offset in an unsafe operation, but no value recomputation found.
 Wrapped field: HotSpotResolvedJavaFieldImpl<org.jboss.marshalling.reflect.SerializableField.fieldOffset long:16>

We might need to get rid of JBoss Marshalling, or hack around it somehow, but I'm not yet sure if it's possible.

• Switching to plain Java serialization won't help, that's not supported in native images
• I think we can't use @RecomputeFieldValue substitution for the SerializableField.fieldOffset field, because the underlying field (of which we store the offset) changes dynamically

Options:

• Find/implement a different cloning mechanism
• Rework the model classes in a way that they become immutable, and therefore cloning will not be needed; and pass the context needed for starting jobs using new additional objects rather than by mutating job definition objects
• any other ideas? @chengfang WDYT?

Hey @stuartwdouglas what would be your suggestion for this please? I suppose we would need to get rid of JBoss Marshalling if we indeed wanted to integrate JBeret into Quarkus?

What exactly is this used for? The correct solution will likely depend on the use case.

@stuartwdouglas see https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/org/jberet/util/BatchUtil.java#L124 It's used as a general mechanism to clone objects (in particular, the Job class that holds a batch job definition)

Here is a proposal to remove JBoss Marshalling: https://github.com/jberet/jsr352/pull/133/commits/6fb5892b93aa92a3ac12ec3ca8903f73592ea158

This is using MapStruct to generate the clone / copy code for the Job model.

MapStruct, if used, will be a new dependency for both JBeret and WildFly. Is it already used in any other of our projects? If so how is the experience?

@gunnarmorling is one of the creators of the project, so he can probably give additional feedback :)

I don't think it is a major problem, since MapStruct is set as provided and is not required at runtime. It is only used to generate the code for map / copy the objects. The annotations are compile only, so in the end you just have a simple interface with the generated implementation.

related to #133