Develop Reference

Using a .net library from Java

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.

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.

Java without JVM

Just wondering if there are any Java implementations that work without a JVM. The reason I'm interested is, well, simply because I'm curious, and I was wondering if there were any "lightweight" Java implementations (without all the Sun libs attached).
I'm also interested in embedding Java in C++, but embedding the JVM in C++ seems rather ridiculous to me. I just want to exploit some of the Java language features in my C++ apps, but not exploit all the frivolous Java APIs.
EDIT:
I see from a lot of the answers I've gotten that I need to clarify...
I recently got in to developing node.js applications, which uses JavaScript. JavaScript in istelf is a language spec, it doesn't automatically come with the DOM, window.open, etc., although it did for a while. I'm wondering if there's something similar to Google's v8, except not for JavaScript, but for Java. In the end, I don't care if I can't write Hello World apps with it, I just want to be able to embed Java in a C++ application the way I can embed JavaScript in a C++ application with v8 or SpiderMonkey. If I could do that, then I could implement console output in C/C++ and then make that implementation callable from Java.

Do you want the Java VM alone without the API(STandard Library) ?
The JRE is composed by the JVM (Virtual MAchine) and the Standard Library, I have doubt that you can find a java implementation without the JVM ... You could find a compiler that compile java source code into native code(take a look at GCJ), but not a Java implementation without the VM.
Take a look at this wikipedia page to see some alternative Java implementations .

There's GCJ (GNU Compiler for Java), but the project has been deprecated since OpenJDK was open sourced.

there are light weight java processors designed for use in small devices for example JOP

As others have hinted, the "JVM" is the mechanism that knows how to load classes, interpret "bytecodes", and manage storage. It does not inherently include any of the java.lang... stuff, except that a few classes (String, Class, et al) are needed to represent classes and other basic data structures in the JVM.
As a result, Java without a JVM is just a bunch of meaningless bits.
There are (or were) compiled versions of Java that do/did not need the interpreter (though a reasonably compact interpreter is quite easy to build). A primitive class loader and some sort of storage management are still necessary, but class loading can be kept simple and for short-lived apps (or those that live with special restrictions) the storage manager need not do garbage collection.
As pstanton suggests, there are "lightweight" Java (or "Java-like") implementations that are suited for small devices.

IMHO, You need to re-exampine what it is you really want.
Java runtime consists of two main components
The JVM to run the code
The standard libraries which come with it.
You suggest you want to use Java, but you don't really have anything left without these.
For example, you cannot even write a "hello world" program without the libraries as String is a class in the JDK.

Cross-Platform Programming Language with a decent gui toolkit?

For the program idea I have, it requires that the software be written in one binary that is executeable by all major desktop platforms, meaning it needs an interpreted language or a language within a JVM. Either is fine with me, but the programming language has to balance power & simplicity (e.g. Python)
I know of wxPython but I have read that it's support on Mac OS X is fairly limited
Java sounds good & it looks good but it seems almost too difficult to program in
Any help?

I used Python with wxPython for quite a while and found it very easy to use. I now use Java with both Swing and SWT.
I prefer Java but that's just a personal preference so you shouldn't let that sway you.
I didn't find the transition from Python to Java that difficult. In terms of GUI, they both have the layout manager paradigm - the managers are different but not so different you'll have trouble switching.
Java has an absolute huge class library to the point where you probably don't need to write your own version of anything, just string together the components. I never really got that deep into Python but it may well be similar. One thing I did notice is that all the really good stuff I used in Python (e.g., s[-4:-1]) could still be done quite easily in Java. Both languages were a step up from C where I had to manage strings with my own libraries.
If you think wxPython is limited on MacOS, you should try Java. I run my Java code on Windows, Linux and other UNIXes without compatibility problems. Sadly, not Mac, so I can't really advise you there.
My advice, pick a smallish project - do it in both Python and Java - see how it runs on all the platforms you're interested in.

Python with PyQt or the eventually-to-be-equivalent-but-gratis PySide seems the way to go -- after all, few languages are easier to program in than Java (which you consider "almost too difficult to program in"), Python is one of those few, Qt arguably the best cross-platform GUI toolkit in any language, and PyQt (now, but GPL or for-$$$) or PySide (eventually, gratis even if you want to close-source your own code) are powerful interfaces between Python and Qt.

You can use any of languages targeting JVM, e.g. Jython (Python impl) and JRuby (Ruby impl).
You can try using Qt bindings for Python, Qt seems to support many of Mac OSX specifics.

Consider Tcl/Tk. I'm not sure how you define "one binary that is executeable [sic] by all major desktop platforms" but Tcl probably meets this as well as java, and likely better than any other scripting language.
Using the tcl packaging technology of starkits you can either a) create a single file that can be run on any platform that has an appropriate runtime engine (and they are available for all major and many minor platforms), or you can package that platform-specific runtime engine and and cross-platform starkit into a single file executable for each platform.
The starkit technology is something other languages should aspire to. What you get is a complete, fully functional virtual file system within a single file. This lets you easily package up sound files, dll/.so files (which must be copied to disk for obvious (?) reasons), images, data, etc along with your executable code.
Tk, the graphical library, is very mature and has really good support on all platforms. Some people think it looks dated but those impressions are usually based on information that is at least 5 years old. Modern Tk looks quite good. For some examples see the tkdocs website. I's not clear whether you're more concerned with eye candy or functionality, but if it's functionality you're interested in then Tk is something to seriously consider.
Most agree that Tcl is an aquired taste but those that use it professionally usually swear by it. I've been doing wxPython programming the last several months and would switch back to tcl/tk in a heartbeat if given the opportunity.

You could use Groovy to work around the Java complexities.
Still you'll need good foundations of Swing.
While the learning curve may be steep, the trade of of not having to completely re-write the whole application again for the next platform will be a good reward.
Bear in mind, that even though it is cross platform, you should consider different platforms still have different idioms ( e.g. Copy/Past in Windows is ctrl+v, ctrl+v while in Mac it is cmd+c, cmd+v )

I work on a program that has to run on Windows, Linux and OS X (and OS X is my development platform), and wxPython is what we use.
If I had a chance to start again, I'd probably go with PyQT (based on advice from friends), but wxPython will get the job done.

I think wxPython is pretty good, though I am not sure what you mean by "support on Mac OS X is fairly limited" but I have been porting a wxPython app (www.mockupscreens.com) to Mac and it wasn't that difficult with few tweaks e.g. some UI elements may not come up as you expected, as wxPython uses native UI elements, which can be an advanatage or disadvantage based on your requirements.
Other good option is PyQT which will give you consistent look on all platforms.

Java seems better for what you want.
Well what about the web application in Javascript?

How about SWT
Cross Platform
Native Look and feel
Huge community
Constantly maintained/upgraded ( IBM backed )
Atleast one mega successful cross platform project

I would suggest going the wxPython route, I know that wxWidgets (which is what wxPython is using) can be made to have great looking Mac apps (look at PgAdmin3 from postgresql). While PgAdmin3 is not done in python, it was done with wxWidgets and looks fine on a mac.

I use three cross-platform tools regularly: Realbasic from Realsoftware which is what Visual Basic v6 would have been if allowed to grow; Revolution from Runrev which is what Hypercard would have been if allowed to survive (and its neat using a scripting language whose syntax is basically English); and finally, Delphi Prism with Mono.
All are quite mature and yet expanding at a great rate. For instance, Revolution is just introducing a web-application feature to its language that is really easy to use.

Java runtime vs OS calls

The Java runtime provides a set of standard system libraries for use by programs. To what extent are these libraries similar to the system calls of an operating system, and to what extent are they different???

Half the point of java was to make it platform independent, so what it tries to do is provide an api that remains the same regardless of the OS underneath it.
If the OS is underpowered, Java will add library code to compensate for it.
If the OS has an implementation that doesn't map, Java will do it's best to map it.
If a new function becomes popular and Java users need to provide access to it, a new library can be created through which you can access the new functionality. If this library is popular, it will be restructured and added into the Java SDK at some point
For instance, an implementation of some concurrency libraries became popular, and soon they were voted upon and added to the standard libraries. This happens all the time.

That obviously depends on the OS you're running on, since the system calls are generally different for every OS :-).
That said, I believe Java was mostly inspired by Unix conventions (not surprinsingly, as Sun is a Unix vendor), so some Java system libraries are similar to Unix sytem calls.
E.g. java.nio.MappedByteBuffer was probably inspired by Unix's mmap() call. But ultimately most concepts are present on most OSes, so you cannot really say what inspired what.

Some of Java's "low-level" functions are basically "wrappers" around some OS
system calls.
I don't see an objective way (and reason) to "compare" both.
If you are interested in this topic, you can search the Java source code
for the native keyword, which indicates some "hidden"
(mostly OS-dependend) functionality.

Java's standard library often has a similar feature set compared to the native library but there are several important differences.
Java is Object Oriented, whether you like it or not. The advantage of this is that certain concepts are easier to manage. For example, most file related operations are found directly in the File object. Compare this to Posix, where a FILE is a handle which is really just a number; an index into your process's open file list. The Posix approach is very close to how the OS actually implements stuff. But in Java you don't see that or know it or care.
Java has certain lowest-common-denominator behaviours in certain cases. There are many AWT APIs that are the way they are because AWT needed to be identical on a number of separate platforms. That turned out to be madness, and Sun quasi-deprecated most of AWT, because supporting platform equally meant supporting every platform crappily. The newer library, Swing, implements almost everything in pure Java, and thus is far better at cross-platform stuff, and thus has a richer API. And that API is very different from the native windowing library. Also, Swing doesn't integrate too well because it uses so little of the native OS.
Java has certain limitations that the native libraries don't have. For example, you don't have function pointers. Thus you have Listeners and Runnable and other Java patterns for doing things that in C++ would involve function pointers. So any API that needs one of these features will be significantly different in Java than in the native OS.
So in conclusion, Java often has libraries that offer similar behaviour to the native OS, and sometimes offer completely different behaviour, but it's best to think of Java as a platform in its own right. Sometimes you need advanced performance, such as OpenGL or super-fast data transfer, in which case you'll want a specific Java API (Jogl, nio), but most of the time you should evaluate Java as its own thing.

Accessing .NET/dll libraries/components from Java?

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!

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).

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...)

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.

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.

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.

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 methods you have to wrap), have a look at SWIG . I think it generates wrappers automatically, 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.