1

I have a compiler for a domain specific language that outputs a .net dll (that can then be used to do whatever the DSL said it should). It works well under .net but now I need to make the compiled dll functionality accessible from Java. The interface changes depending on the DSL, much like it would if I was implementing an F# type provider.

Ideally, I would like something along the lines of Reflection.Emit except that it would generate Java bytecode. It is important that the end-user can debug their Java code that uses my generated library from a Java GUI, so I don't think I can just use IKVM to instead include the Java code in .net. I also cannot use a commercial product such as JNBridge because all the users would need to install it, and call it every time their DSL code changes.

Is there a better solution than generating a .java file in text format and compiling it with a Java compiler? The .java file would just be a light-weight interface talking to the .net dll over some IPC mechanism (perhaps a named pipe), and its purpose would be to provide a typesafe interface similar to what would be seen from a .net application (except with indexers, getters, setters, overloads, etc replaced with some sort of horribly verbose syntax). Many thanks.

Joe Huha
  • 548
  • 3
  • 16

1 Answers1

1

Java native interface is a way to call native code from Java (That dll isn't running on the JVM, thats for sure). Throw your dreams of "Write once run anywhere" in the bin now.

If you want to use dlls then you have to use JNI (or something similar or based on JNI like jni4net). It's not as pleasant as say, using c++ from c#, but it's pretty doable and far and away the best way to use dlls from java (I think the second best is re-writing the native code).

Alternatively you could run a windows process alongside your java app and soap/json/namedpipes/etc between the two, is that what you suggest in the last paragraph? This would be odd for a small solution, but for a larger modular project it's not so crazy. I would recommend using sockets to communicate between the two, because I think sockets are easiest. It says client/server in the example, but it could be two processes (java and f#). ... This causes problems for performance, synchronisation, firewalls etc.. ahhh, just use JNI.

Community
  • 1
  • 1
Nathan Cooper
  • 6,262
  • 4
  • 36
  • 75
  • I don't see that JNI code is any easier to generate than Java? I *cannot* write the interface by hand, it has to be generated in .net because it depends on the DSL it is compiled from. – Joe Huha Aug 13 '14 at 16:40
  • I'm not quite sure of your requirements. You're calling auto-gen f# code you know nothing about? – Nathan Cooper Aug 13 '14 at 22:01
  • The exact opposite. I know everything about the dll because it is generated at the same time as its Java wrapper. That is why an equivalent of Reflection.Emit that produces Java code would help, and why generating Java in text format then compiling it with javac would work. Doing that feels like living in the early 90s again though :-) – Joe Huha Aug 14 '14 at 17:03
  • @JoeHuha, maybe there's a dirty regex code gen solution (something you could write using Reflection.Emit as a guide)... Since your do have those clues from the java maybe it wouldn't be the worst thing in the world. I imagine there may be solutions for [c# -> java](http://stackoverflow.com/questions/78811/is-there-an-effective-tool-to-convert-c-sharp-code-to-java-code), and I may be wrong, but can't you just decompile f# into (probably unreadable) c#? Watch out though, code translation is a bit tricky and none of the tools are any good. – Nathan Cooper Aug 14 '14 at 22:12
  • I can decompile the dll, though I already know what the code is going to be since I am generating it myself. I don't think it's possible to translate any recent version of C# to Java since it has lots of features that Java doesn't. Even the basics such as generics can only sensibly go the other way. Sounds like a textfile followed by javac it is :-( Many thanks for your time. – Joe Huha Aug 14 '14 at 23:00