We Keep Coding

Can a native image generated by GraalVM replace IKVM generated DLLs?

I have some Java-app and a customer with some UWP-app implemented in C#, distributed through the Windows Store etc., who wants to use some pieces of my app. Those pieces are pretty OS-independent, only parsing of some special binary file formats, applying some business logic configured using YAML files and stuff. No network, GUI, only some accesses to files etc.
We currently use IKVM to make the code of interest available to C# but ran into different problems already. Some were supporting .NET Core, some had to do with the native toolchain in Release etc. While right now things seem to work after applying some workarounds, I'm looking for alternatives to IKVM already a bit.
The only thing I currently use of IKVM is simply creating a DLL of my code using ikvmc, which can then be referenced in the UWP-project. The compiler is summarized like the following:
The ikvmc tool converts Java bytecode to .NET dll's and exe's.
That's where the support to create native Windows images of GraalVM came into my mind. Others seem to already build native binaries for Windows and according to the docs, GraalVM is able to create shared libs using "--shared". From my understanding, IKVM implements a JVM in .NET and maps things as needed and possible. That sounds pretty much like what "Substrate VM" does in case of a native image, doesn't it?
This executable includes the application, the libraries, the JDK and
does not run on the Java VM, but includes necessary components like
memory management and thread scheduling from a different virtual
machine, called “Substrate VM”. Substrate VM is the name for the
runtime components (like the deoptimizer, garbage collector, thread
scheduling etc.).
https://www.graalvm.org/docs/reference-manual/native-image/
So, is there any chance that a native image in form of a DLL can replace the DLL created by ikvmc currently? Did anyone try that already and has any experiences? Did anyone try already to create a native DLL and consume that in some other native Windows app? From my understanding UWP "only" applies additional restrictions which one might be able to work around again. Or is this approach totally impossible for some reasons?
Thanks all for your input!

I'm not very familiar with the IKVM project, so this answer is mostly about the generic question:
Can you create a native DLL/shared library and consume that in some other native Windows app?
It should be possible. You can compile Java code into a shared library. The entry points are marked with the #CEntrypoint annotation.
You can then use the generated shared library and the header files to consume your library from a native application.
This way for example GraalVM distributions use the GraalVM JIT compiler by default:
The GraalVM JIT is written in Java
Compiled as a shared library with the native-image
Used in Hotspot.
Here's a page describing how to consume those from Java through the JNI: https://www.graalvm.org/reference-manual/native-image/ImplementingNativeMethodsInJavaWithSVM/
which could be very similar to how would you use a shared library from a C# application.

GraalVM native images are not very flexible, unlike IKVM.NET images. Unless you like writing wrappers and playing with P/Invoke, you should stick to IKVM.NET.
NOTE: I am behind an IKVM.NET fork

Python Integration with Java / C

I implemented most of my projects in C++ and python. However, we recently got a new database interface that I could only use Java to retrieve data.
I want to stay with my Python/C++ tools but I am wondering if there is a good solution to integrate Java to my Python application. I heard about Jython, but it is a different python implementation and I am concerned some of my C++ tools will not work well with it. Jpype seems simple but it hasn't been updated since 2011, so a little concerned with the compatiablity with the current python/java.
Is there a good solution to this? all opinions are welcomed.

gcj (gcc compiler for java) supports java 1.5 syntax (1.4 is working better on it) and therefore some Java programs may be compiled to native code. gcjh (or javah) can produce headers for java libraries, so you can write C extensions for python. Of course some libraries could not be compiled with gcj (like Apache Commons Logging) because of using com.sun packages. Did not updated from 2009.
There is another Java to native compiler, commercial Excelsior Jet (it's another JavaVM, it supports Java 1.6 and soon Java 1.7). They said linux-64bit version of their product will be available in 2013-Q4. But I didn't try it well, I don't know, are headers for compiled library can be produced.
There is a lot packages at pypi, like JCC (from PyLucene creator) or Py4J that can use Oracle JavaVM through JNI or sockets.

One way to do this is to write web services. A web service can accept an HTTP request, marshal it into a data request, pass that to a Java class that get the data out, map the quert results into a response of some kind, and send it back.
Any client that can send an HTTP request, accept the response and unmarshal it can interact with that service. They need not know that it's implemented in Java.
You pay the price of an extra network roundtrip to get the benefit of language interoperability.

There are ways of wrapping C/C++ out there, but I can't speak to them.
Integrating with Java, however, is wonderfully simple. There's a distribution of Python called Jython which actually runs on the JVM. Using Java libraries is intuitive and easy:
from java.io.util import *
and for the most part it just works (some caveats apply in terms of threaded/async stuff). I love Jython. We used Jpype for a few projects but even if it were still fully maintained I'd still choose Jython over it any day for this sort of project.

How to create a mobile oriented, multiplatform, shared library in Java?

I have a Java application that runs on BlackBerry (JDE 4.5). I want to port this application to Android, and be able to maintain the 2 applications simultaneously. I may also want to port this application to other Java platforms (J2ME ?).
I understand that a good part of the code will have to be specific to each platform (UI and other stuff). But I also feel that a lot of the code could (should) be shared (domain related classes).
What is the best way to achieve this, and what are the pitfalls to avoid?
I have been able so far to create a JAR with all my shared classes, that I have been able to integrate into my BlackBerry application (using preverify and rapc). But:
The JAR is a J2SE library. How can I make sure that it will run (or even compile) on BlackBerry, Android or J2ME?
I am also using a JSON library targeting J2ME (https://github.com/upictec/org.json.me/). This library seems to make use of some kind of preprocessing directives (CLDC, see https://github.com/upictec/org.json.me/blob/master/src/main/java/org/json/me/JSONObject.java#L392). How can I use (or convert) this library using the right preprocessing definitions?

This is likely to be difficult:
As you have already identified, the UI code will have to be different for each platform.
There are major differences between Java SE / Android and Java ME-based platforms. For example, ME doesn't have the Collections framework, or the java.io or java.nio stacks.
It is hard to predict from the information you've provided, but there's a fair chance that you'll spend more time fighting the platform dependencies than you are saving by sharing the code-base.

These days, the biggest stumbling block to sharing code this way is that the BlackBerry VM and Android VM both support different versions of the Java language. BlackBerry uses a subset of Java 1.3, Android uses a subset of Java 1.5. (As an aside, neither platform implements a Java VM, both use their own VMs. Java is used as the programming language. Java bytecodes must be transformed to the appropriate native VM format before they can run on the platform.)
The biggest difference you will find as a library implementor is that the BlackBerry lacks the things that were introduced in 1.5, very important things like generics and enums. Even worse, the Collections classes are missing from the BlackBerry. It is unfortunate, but that is the way it has been for a long time now.
This means that to be truly portable you have to write to the lowest-common denominator, which means using (very) old-style classes like Hashtable and Vector, not having generics, rolling your own enums (as in the 1st edition of Effective Java) and so on.
Or you build two libraries, a modern version for Android and a stripped-down version (with just the bare stuff you need) for the BlackBerry.
Hard to say what`s right for you.

Rather than prepackage your shared library, I would consider sharing the library project and having it as a dependency in your mobile applications' build process. That would allow you to share the code base, but have it built by the appropriate builders for your target devices. With a bit of IDE magic and some attention to detail, you should be able to pick up errors before anything is shipped out.
Alternatively, set up your library project to use two separate builders to pick up errors. That would allow cleaner distribution, but you may run into problems trying to convince your IDE to treat the project as being device specific in order to identify problem areas.
It would be likely that you would end up supporting the lowest common denominator device (cough Blackberry), and forgoing the additional facilities of the more extensive Java implementation on Android.
Unfortunately the answer will be one of experimentation. Try it and see what happens.

The article Porting Android code to BlackBerry has some good detail on how to work with code shared between the two platforms.

it will be very difficult to create shared library for blackberry and android.
if you want simple method, create your application as web app.
using
phonegap with jQtouch

Advantages of using Rhino (mozilla's rhino)

I've been reading about Rhino as a useful way to implement JavaScript inside my Java code.
After reading for a while, searching in google and here, I couldn't find a real reason for which I would use JavaScript inside Java.
Could you point some real world advantages you find on using Rhino for a regular Java application?

Note that since Java 6, the scripting API is in the standard Java library - see the documentation of the package javax.script. The API in javax.script is an adapted version of Rhino. The scripting API supports not only JavaScript, but many other scripting languages.
See Java Scripting Programmer's Guide
The front page there mentions some reasons you might want to use scripting:
Application extension/customization: You can "externalize" parts of your application - like configuration scripts, business logic/rules and math expressions for financial applications.
"Command line" shells for applications -for debugging, runtime/deploy time configuration etc. Most applications have a web-based GUI configuaration tool these days. But sysadmins/deployers frequently prefer command line tools. Instead of inventing ad-hoc scripting language for that purpose, a "standard" scripting language can be used.
An example: You can script Oracle Weblogic using Python scripts, for example to configure your application server domain, to start or stop the server and to do other administration tasks.

Processing XML with Rhino and E4X is a joy compared to most of the Java XML APIs
You have existing JavaScript that "just works" and you don't want to re-write it. This can happen if you have some calculation or processing happening on the client side and move it to the server.
All kinds of neat caching and code loading tricks.
Your problem is better solved by a more dynamic language then Java.
List comprehensions ;)

The benefit of embedding a script language like javascript into your software is that you can offer others a way to write plugins for your software without giving the source code away.
A reason to write the whole app in another language is that you are able to write an app for a company which deploys it in their Java EE environment without having to learn Java.

We use JS (via Rhino) for a DSL in one of our products. It isn't a great DSL, but that is a fault of how we use JS, rather than Rhino.

If you considering to .Net also, I suggests to get along with Rhino.
Besides Java enviroments, rhino is one of the best performance interpreter on .NET environment (using IKVM). On the other hands, nashorn is very slow on .net.
Porting your own Rhino project to .NET is not so difficult.

Anyone here have any experience using gcj's CNI for java external libraries?

I've been interested in doing some work on a desktop application for while now and my most proficient language is Java. Due to wanting to be able to compile down to a native executable, does anyone have any experience they would like to share about using gcj to compile, and CNI for libraries? I was hoping to use of of the native toolkits, not just Swing/SWT.

As Eclipse has been sucessfully compiled natively (see http://www.linuxjournal.com/article/7413) I would say it's possible.
I used GCJ to embed Java code into an C++ application, but I would not use it for a UI application. I would go pure Java there (probably Eclipse RCP based) as that is where I have experience.
Have fun experimenting!

I haven't used gcj for compiling to a native executable but for interfacing to native libraries I've found JNA to be a very nice way to do it as you don't have to write any native code at all to make native calls. Note that doing it this way does result in a performance penalty so it probably wouldn't be an option if you're calling into native code in a tight loop where performance is likely to be an issue.