Hi, I have a quite large library written in Java that I’d like to port to both Cocoa and .NET. The idea is to generate a lib that can be called from native apps, whenever they are called from Swift/Objc or C#. I’d like to maintain a single java based source code for all the platforms.
The library has almost no external jar dependencies so I can start from the source files.
Question: is Elements the right tool to accomplish this goal? If so, do you have some examples of such a library exposing classes that can be used from multiple environments?
I think so.
RTL2 is a good example.
It has a project file for every environment, each of those consume a shared project.
Ok thanks - I’ll give it a shot
Philippe,
yes, Elements is definitely the right tool for this!
Our Iodine/Java front-end is relatively new, so I’d appreciate if you let use know if you run into any problems; a lot of users already have thrown their existing code bases at it, so we’re pretty confident in the language compatibility — but Java has a lot of quirks, so one never knows, you might run into one or two. If you do, don’t give up, let us know and we’ll address them asap.
I suggest to start by moving your source files into an Iodine project for Java, as the first step, to make sure we handle everything right. That’s the art that should function completely seamless and “just work” — barring any cormnercase bugs as per above.
When that succeeds, as a next step you can try compiling the same code against Cocoa and/or .NET. That’s when you will expectedly of course hit stuff that won’t just work, but will need abstraction (some with #if’s, others maybe by just rewriting the code a bit. I suggest giving https://blogs.remobjects.com/2017/08/16/strategies-for-cross-platform-code-sharing-with-elements/ a good read for ideas there.
hth,
marc
Thank you for your lengthy reply Marc. I’m going to follow your advise and give a try for the base library.
That being said, how much of the JRE libs do you emulate? For example, if I’d like to use JRE classes in my library, are they emulated on other platforms, or is your cross platform strategy achieved through your own RTL layer? Have you tried, at least on iOS and Mac, to integrate with the J2OBJ jre_emul library?
None 
Right now, the strategy is that we give you the same language everywhere, but you’ll use the native APIs, and optionally Elements RTL (see Elements RTL), which provides a a lot of good classes to write sharable code, but is not exactly modeled after the JRE classes. For the type of project you are describing, I would definitely recommend going for Elements RTL. It will mean some initial conversion (e.g. java.x.HashMap becomes Dictionary<T,U>, etc, but it’s not as hard as it sounds.
Our Mac IDE, Fire, was pure Cocoa, a year go. within a month or so, as a side project, I had it full converted to use Elements RTL, and all non-visual code compiled and worked for Windows. (of course the UI is more work, especially as we’re redesigning that from scratch, but even there a lot of sharing is possible — the blog post I mentioned before talks about that a bit).
I must admit I have not, no. have not been heard about it — but I’ll have a look!
—marc
All right, thanks for your quick reply again.
As we are developing a Java library that gets integrated into other projects, we have to keep with the JRE classes. So we need a true emulation layer, we have to use Map and not Dictionary :-). The J2OBJC one contains almost all what we need. I was hoping to get something similar from Iodine, as the whole environment looks very nice!
Note that you may still be able to do that. Most of Elements RTL desont‘ reimplement core classes (such as Dictionary), but maps them to new cross-platform-consistent types. Under the hood, on Java, they are still the native Java types.
Another option ofcourse might be to create (maybe as an Open Source project that others could use and contribute to as well) a separate compatibility library similar to Elements RTL that would essnetially map to standard Java types, but provide native implementations/ma;ppongs for them for the other platforms…
The second solution is the only one that would fit our needs. As you said, it is about replacing Elements RTL by a JRE emulation library. I need to investigate this more, but this will certainly take time as I don’t know any of the internal of Elements.
You could start by taking a copy of Elements RTL (source is on github) and essentially just adjjusting it‘s outward-facing APIs to look like the Java ones. (of course that makes it sound simpler than it will be in reality, but that‘d be thegeneral idea… 