fillcover red in initializer dependencies - Quarkus native - native

I try to build a native container with Quarkus (with -Pnative flag), I use -H:+PrintClassInitialization to generate the class initializer reports. I see a initilizer_dependencies_yyyymmdd_hhmmss.dot file is generated; in this file, I see some classes marked with [fillcover=red], could you tell me what this means? and what action is needed?
Thanks

it seems to me those classes are the ones that will be called but not in reflection configuration. I add them in reflection or initialize to solve it.

Related

Is there a way to intercept java.io.File class in java agent

all
For some reason, we want to intercept java.io.File class to add some log and do some check.
I tried to create a java agent with Byte Buddy to use Advice to do such things for some other class.
But it never work for class which is already loaded before agent premain. I am on byte-byddy 1.10.5
I also did some try use redefinition, or transform, but it's not work as well, not sure if I did something wrong.
Is there a way to achieve this?
You need to enable a retransformation of existing classes. Also, you need to define a custom ignore matcher as boot classes are not instrumented by default.
agentBuilder
.with(RedefinitionStrategy.RETRANSFORMATION)
.disableClassFormatChanges()
.ignore(...)

Java method not available in Kotlin?

I am using the ejml-library (written in Java) in a Kotlin project. I imported the library (everything seems to work fine) in IntelliJ. However, some methods which should be available (e.g. the inherited getDDRM() method of the class SimpleMatrix) are not recognized and I can't use them. Whats very weird is that the very same procedure used with Scala (also using IntelliJ) works. That is, in Scala I can access the method - with Kotlin I can't.
It would be great if someone could shed some light on this.
update:
the getDDRM() method is part of the abstract class "Class SimpleBase<T extends SimpleBase>" and has the following signature: "public DMatrixRMaj getDDRM()". In my code I call this method on an instance of class SimpleMatrix which is a concrete class inheriting the SimpleBaseClass –
I should also note that I rebuild it with gradle and the issue still persists.
IMPORTANT: I should add that I can access other methods defined in the very same class. For instance I can access the method getMatrix() which is just another method of the very same (abstract) class. In fact, IntelliJ's method completion shows me a whole list of methods - but the getDDRM() is missing. I really don't get the cause of this problem.
Update 2:
If it is of any help: When I do not use gradle but instead open a Kotlinproject in IntelliJ and add the libary jars manually then everything works fine. Can anyone explain this?
Thanks in advance!

Warnings while using a plugin and static library in a cocoa project

I have a scenario where I need to use a plugin as well as a static library into my xcode project. The plugin will be dynamically loaded into the system. Now, the static library is also getting used in creation of the plugin.
While executing my project I am getting a warning saying :
Class A is getting referenced from /staticLibraryPath and plugin. One of them will be used.
Please let me know, how to resolve the warning or a better way of implementing the scenario.
The issue is a name class of the two ClassA types found in both plugin and library
I assume you have control over the source of either plugin / library.
.. rename Class A in one instance to make the names not clash -- I don't think there is another way to get rid of the warning/error

How to instantiate AbstractSourceLookupDirector?

I'm writing a plugin for Eclipse Juno, I want to make use of class AbstractSourceLookupDirector. When I look at the API it says it has a constructor, but when I use following statement in my code, it says "cannot instantiate type AbstractSourceLookupDirector"
AbstractSourceLookupDirector srclookupDir = new AbstractSourceLookupDirector();
Could you please let me know how to make use of AbstractSourceLookupDirector.
Ref: http://help.eclipse.org/indigo/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/debug/core/sourcelookup/AbstractSourceLookupDirector.html
Many thanks in advance!
It is an Abstract class, you can't instantiate abstract classes in Java.
What you need to do is configure an extension point org.eclipse.debug.core.sourceLocators
and have your class extend AbstractSourceLookupDirector
An example is given in the juno docs
http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fextension-points%2Forg_eclipse_debug_core_sourceLocators.html

Save and Load instances of objects created earlier via the Eclipse registry

I am currently experiencing a problem in my RCP application and wanted to ask, if someone stumbled over the same problem and can give me some valuable hints:
My RCP application allows plugins to provide implementations of a specific abstract class of my model (singleton) to extend my model during runtime via the update manager. I instantiate these classes via
extensionPointImplementation.createExecutableExtension(..)
after parsing the Eclipse registry. I can serialize the created instances using the default Java serialization API.
Now to the problem: The plugin trying to deserialize the objects cannot find the class implementations of the model extensions due to the fact, that there is no plugin dependency between the plugins. Nevertheless, it is not possible for me to create such a dependency which would make the idea of extending the model during runtime obsolete.
Is it possible to solve this problem by using the default Java serialization API or do I have to implement my own serialization (which parses the Eclipse registry and creates the instances via the line shown above if all necessary plugins are available, otherwise throw an exception) which might be based on the default Java serialization API (if possible I do not want to create the serialization completely by myself)?
Thanks.
You need to define a so called buddy policy.
In the bundle trying to instantiate the class add
Eclipse-BuddyPolicy: registered
to the manifest.mf.
In the bundle providing the class add
Eclipse-RegisterBuddy: <symbolic name of the bundle instantiating the class>
to the manifest.mf.