Sometimes it's more convenient or performant to emit an event from Java even though the event carries metadata defined in metadata.xml in native. For example, a Java event could contain a stack trace, method, bytecode instruction or a thread state.
One way fix this is to extend the native types to Java, similar to what exists today for the Class and Thread type, but it would involve a lot of boilerplate code.
A more generic way is to mimic the mirror mechanism that exists for events in java.base. In this case, Java events would get their metadata from metadata.xml. Field names are verified so they match and the mechanism would only be allowed for event classes loaded by the bootstrap class loader.
The technique could potentially be used to lower the startup time, as it could reduce the need to inspect JDK events reflectively, but it may not be worth the maintenance burden of updating metadata.xml with every new JDK event.
When using native artefacts in Java, great care must be taken to ensure they get tagged properly or that they are static in nature and emitted with every chunk
One way fix this is to extend the native types to Java, similar to what exists today for the Class and Thread type, but it would involve a lot of boilerplate code.
A more generic way is to mimic the mirror mechanism that exists for events in java.base. In this case, Java events would get their metadata from metadata.xml. Field names are verified so they match and the mechanism would only be allowed for event classes loaded by the bootstrap class loader.
The technique could potentially be used to lower the startup time, as it could reduce the need to inspect JDK events reflectively, but it may not be worth the maintenance burden of updating metadata.xml with every new JDK event.
When using native artefacts in Java, great care must be taken to ensure they get tagged properly or that they are static in nature and emitted with every chunk