tags:

views:

429

answers:

6

Are there inexpensive or free gateways from .NET to Java? I'm looking at some data acquisition hardware which has drivers for C/C++ and .NET -- I really don't want to do any programming in .NET.

Update: I haven't done what I originally wanted to do, but I've done something similar, using JNA to encapsulate some functions from a DLL, in order to control a USB hardware device from Java. (the DLL comes from the device manufacturer) It works really nicely. Thanks!

+3  A: 

Well, there's JNBridge and EZ JCom, just from a Google search.

You could also use IKVM which is a slightly different approach.

(Any reason for not wanting to learn .NET, out of interest? It's a nice platform, and C# is a lovely language...)

Jon Skeet
Indeed it is, I spent my last week learning C# (following my earlier questions) and managed to rewrite a 15000 line program from Java in that time. Not well-written, but a decent start.
Elie
why not .NET: I've suffered too much from having to do Microsoft programming in the last 17 years. I'm kinda tired of spending excess neurons learning their strange quirks.
Jason S
I hope you enjoy Java's built-in date/time API then, and wide-spread use of strings for character encodings... :) (Seriously, in most respects .NET has benefited significantly from coming second. Give me C# over Java any day. Having said that, I use Java 4 days a week...)
Jon Skeet
Points all well-taken. I'll be getting a Macintosh at home shortly, and in the past year or so have been slowly migrating towards cross-platform technologies like XUL/Javascript/Java -- too many instances of coming across year-old ATL/Win32 code that I can no longer maintain cause I can't remember.
Jason S
A driver for a piece of hardware doesn't seem like a good reason to switch development languages. Depending on the time, and amount of experience in the language, I would rather switch the hardware :)
Steve K
I concur! but I can't find any java-friendly data acquisition hardware :(
Jason S
+2  A: 

If they have C++ versions of the drivers then you could write a wrapper around it using JNI and then load that in Java. JNI can be a bit of a pain, but it would let you use the C++ version of their drivers and not have to deal with .Net at all if you don't want.

Herms
That's true... it just seems like a royal pain. I don't know why the hardware manufacturers don't support Java. :(
Jason S
PLUS I'd have to do this over and over again for each different data acquisition system I have to use :bleah: 8p
Jason S
Yea, it would be pretty annoying. But you asked for a way to avoid .Net. :)
Herms
true that's why I gave you +1 for thinking outside the box. :)
Jason S
+4  A: 

You could also try to use JNA for accessing the native library. JNA provides Java programs easy access to native shared libraries (DLLs on Windows) without writing anything but Java code—no JNI or native code is required. If their API is fairly straight foward, this might be the path of least resistance.

See their getting started guide where they call some native code (printf and GetSystemTime).

Hope this helps!

Steve K
Interesting! That might be a good possibility.
Jason S
A: 

If you have a Java application, the JNI mentioned by the others will be the way to go. You write some wrapper classes, and that's it.

If writing the wrappes is a too big task (depending on the number of mehtods you have to wrap), have a look at SWIG . I think it generates wrappers automativally, but I never actually used it.

If you want to code in the Java language, but you don't care if your program will run on the JRE/JVM, then you might as well use Microsoft J#. Basically, it's writing Java-Code wich is compiled to .NET-Bytecode and can use the .NET classes of the driver as well as your existing Java classes. With J# you will run into problems if your existing Java-code is newer than Java 1.4, look at this question on how to solve them.

From that point on, you could later add code in J#, C# or any other .NET language. However, you won't get back to the JRE/JVM easily.

Brian Schimmel
+1  A: 

I am partial to the recommendation to jump in the deep end with C# since it is so similar to Java. I did this and used IKVM to compile my favorite Java libs. to .NET assemblies and you get [nearly] all the core java runtime classes to boot, so if you tire of trying to find just the right C# collection type, you can always go back to java.util. (No generic collections though. Not sure why.)

Depending on what platform you're on, you have several choices for free IDEs too. For windows you can get Visual Studio Express for free but I also use SharpDevelop. You can also get the Mono IDE on Linux (and a few flavours of Unix, I think ?).

The C# learning curve is shallow if you already know Java. I only blew off 1.5 limbs on landmines that came out of nowhere for reasons I still don't understand, but workarounds were easy to come by. The worst thing about it was the darn developer docs which are AWFUL on account of being so slow. I really miss the snappiness of JavaDoc. Not only are the online docs incredibly slow, the problem is compounded by someones's iffy decision to put class summaries, constructors and methods/properties all on seperate pages so it just takes forever. Someone said to get the docs installer and install docs locally for a slightly improved experience. Not a bad idea I suppose.

Nicholas
+1 for the landmines comment. :) "Not only are the online docs incredibly slow, the problem is compounded by someones's iffy decision to put class summaries, constructors and methods/properties all on seperate pages so it just takes forever." yep, that's Microsoft. :(
Jason S
A: 

I am author of jni4net, open source interprocess bridge between JVM and CLR. It's build on top of JNI and PInvoke. No C/C++ code needed. I hope it will help you.

Pavel Savara