This is the base class you inherit from in D classes that represent Java classes. You can then mark your methods @Import if they are implemented in Java and you want to call them from D, or @Export if they are implemented in D and want to be called as a native method from Java.
Creates a JVM for use when main is in D. Keep the returned struct around until you are done with it. While this struct is live, you can use imported Java classes and methods almost as if they were written in D.
translator.
translator
translator.
Java's String class implements its CharSequence interface. D's string is not a class at all, so it cannot directly do that. Instead, this translation of the interface has static methods to return a dummy class wrapping D's string.
This is really used by the JavaClass class below to give a base for all Java classes. You can use it for that too, but you really shouldn't try to implement it yourself (it doesn't do much anyway and the other code in here assumes the presence of IJavaObject on an object also means various internal static members of JavaClass are present too).
Indicates that your interface represents an interface in Java.
I may not keep this. But for now if you need a dummy class in D to represent some object that implements this interface in Java, you can use this. The dummy class assumes all interface methods are @Imported.
hack used by the translator for default constructors not really being a default constructor
Can be used as a UDA for methods or classes where the D name and the Java name don't match (for example, if it happens to be a D keyword).
For the translator
Provides easy interoperability with Java code through JNI.
Given this Java:
And this D:
We can:
Please note: on Windows, use -m32mscoff or -m64 when compiling with dmd.
Exact details subject to change, especially of how I pass the exceptions over.
It is also possible to call Java methods and create Java objects from D with the @Import uda.
While you can write pretty ordinary looking D code, there's some things to keep in mind for safety and efficiency.
You may be able to get the D compiler to help you with this with the scope attribute, but regardless, don't do it.
It is YOUR responsibility to make sure parameter and return types match between D and Java. The library will static assert given unrepresentable types, but it cannot see what Java actually expects. Getting this wrong can lead to memory corruption and crashes.
All JavaClass sub-objects should be marked final on the D side. Java may subclass them, but D can't (at least not now).
Do not use default arguments on the exported methods. No promise the wrapper will do what you want when called from Java.
You may choose to only import JavaClass from here to minimize the namespace pollution.
Constructing Java objects works and it will pin it. Just remember that this inside a method is still subject to escaping restrictions!