Slashdot Mirror

This is about "ahead of time" compilation, otherwise known as "compilation", which third-party tools [stackoverflow.com] have done forever. Linking to C in Java is its own world, and I don't know how practical C++ is.

The stack overflow you link to has nothing to do with AOT. They all use a standard JVM and JARs, just all packaged into a single exe file. Its still JIT for the ones that include the JRE bits, the others just download and install a JRE for you. Using C and C++ code from Java is non-trivial but easy enough.

It's dead easy to bridge between C++ and C# at runtime using Managed C++ (or whatever they call it these days). The C# marshaller, the built-in way to get C objects from C# code, is slow painful garbage that no one should use, but it's easy to do the conversion in C++ and either object conversion or using objects directly is very fast that way.

Its just as easy in Java, except better hidden, cause you're not supposed to do it, in order to keep the 'cross platform' nature of Java at its core. Microsoft wants you to bind your C# apps to the Windows platform so they encourage the use of P/Invoke to work around unimplemented features of the framework. Its handy, but goes against one of the core tenets of Java.

You can compile C# to a proper EXE or DLLs easily enough and it will happily load C/C++ DLLs. The reverse is a bitch though - I've heard it's possible (the .NET runtime is also just DLLs), but I never got it to work properly.

Technically, what you compile C# (and all .NET) to isn't actually executable either. Its byte code as well, that can be easily and quickly turned into cached binaries that are essentially AOT compiled ... but thats stored in a different director on the machine and isn't the exe you run, mono will do actual full AOT with the right options, but by default doesn't either. Full AOT takes away several features of the .NET framework, just like it would with the JRE. They'd be implemented in an entirely different way. .NET dlls are just OLE components at their hearts, you've probably heard of OLE as one of the other names it goes by: DDE, OLE2, ActiveX, COM, DCOM. These are ALL THE SAME THING in different revisions, with more features in the later ones. .NET being the latest. Loading and running .NET assemblies is only slightly more difficult than loading an ActiveX in C or C++. Its non-trivial, and you won't find a ton of examples, but its not black magic. Its no more difficult than getting an XPCOM or Corba object to load, and Mozilla can even do that properly so lets not act like its rocket science.

You can (awkwardly) run C code from Java, including loading DLLs, but I've never heard it's possible to do the reverse. What can C code do with a JAR?

You would embed the JVM in your application or a plugin for your application and execute the JAR from there, the same way you do with .NET runtime objects. Not really rocket science here either, though again it is non-trivial.

Its the same as loading pretty much any interpreted language from C or C++, just different libraries and function calls. You do realize that the 'java' command is a C application that loads a bunch of Java libraries and execute JAR files right?

Linking all three would be a bragworthy project, but I think Java is just missing the key concept here.

Its been done: https://www.ikvm.net/

Run .NET code in java, run Java code in .net. Its big, its bulky, it works pretty well, but I don't recommend doing it for weekend fun.

For the most part, Microsoft CLR users already don't care. Have you heard of IKVM? They're already yo-ho-ho-ing code like Zookeeper libraries and other stuff at a prodigous rate. And given that the CLR has versioning that lets it update its binary engine without deprecating the entire universe that came before, they're doing it with a language with features at least 5 years ahead of what the Java working groups are even considering.

Given the open sourcing and license of the .NET core libraries, CoreCLR and compiler... Quite frankly the community would be better served if Google used the CLR. Microsoft actually doesn't need a lot of buy-in. They're already leading one of the top 5 most deployed binary platforms in the world. What they want is developers to recognize their platform is actually the technically superior and most open option.

I can be productive with a language so long as I can find a library or tool for my problems - I don't need them to be FOSS. There are plenty of libraries and tools for .NET - probably less than for Java, but I've never run into a situation where I didn't find something that I needed. A lot of them are FOSS, too.

The community is very big. Have you seen StackOverflow? The most popular languages there are .NET ones.

The IDE - by and large there's only VS, but it can certainly stand up against Java IDEs. In some areas (e.g. code editing) it is somewhat worse, which can be rectified by extensions like Resharper. In some areas (e.g. visual designers) it's better. In some it's vastly better - show me a Java IDE that lets you debug both Java and C in a single session, properly handling things like "Step into" on a JNI call, or C code calling back into Java via JNI; VS can do that with P/Invoke.

The tools are out there, too - you'll have to be more specific about what you need.

With respect to other languages, if you start bringing in Groovy, Scala etc into the picture, then for .NET you also have to bring in F#, C++ (not C++/CLI, the full thing - it can still compile to managed code), and, funnily enough, even Java - because CLR as a VM has a strict superset of the capabilities of JVM, you can run the latter on top of the former, but not vice versa.

Since it's written in Java, they can just run it on the .NET virtual machine using IKVM.

The 360 has a JVM? Or are they going to do a half assed port in XNA?

There's no need for half-assed ports - because CIL is, semantically, complete superset of JVM bytecode, it's possible to have a JVM implemented on top of CLR (with automatic translation of bytecode). This already exists - IKVM.NET - and it can do "ahead-of-time" translation (i.e. feed it .class files, get a .NET assembly).

The trick is getting the class libraries. IKVM offers a lot of fundamental Java classes (collections, I/O etc). But it also gives you the ability to call directly into .NET APIs from Java, so it's entirely possible to take an existing Java codebase, rewrite just the renderer, audio and input to work with XNA, and leave the game logic intact.

Alternatively, there is Sharpen, which works on source code level rather than with bytecode - it takes Java and spits out C#. Again, this is possible because C# is a superset of Java feature-wise, and most things have direct, one-to-one mappings.

I don't use COBOL because it doesn't have useful hooks into the libraries I need to use on a day to day basis. Same with Microsoft tech.

Microsoft development tech today is primarily:

1) .NET
2) C++

with heavy investments into both, balance being different depending on the kind of platform you're targeting (desktop/web/mobile). Also, JavaScript/HTML5 is coming as a third distinct platform with IE9, but we're looking at what is here and now.

So, I'm genuinely curious as to what libraries are you missing on either platform, especially keeping in mind the existence of C FFI on .NET (P/Invoke), automated wrappers to generate declarations for it wrapping C and C++ code (SWIG), and various MS and third-party tools facilitating cross-language interop, such as C++/CLI, IKVM for Java, IronPython, IronRuby, Phalanger (PHP on CLR) etc.

I tried searching for jvm on top of clr and the first ten results didn't look relevant.

http://www.ikvm.net/

IKVM.NET

It's a Java Virtual Machine implemented on top of .NET.

The author was using GNU Classpath for the class libraries but has recently been integrating the OpenJDK ones.

Why? To embed Java functionality without a messy JNI layer.

Actually you can do more on Mono then Java. and Mono can run Java as a function fully functioning JVM using IKVM.NET (http://ikvm.net/). In fact that Java based x86 emulator that was posted a few days ago is running on Mono with IVKM. Not so easy to go the other direction (http://grasshopper.mainsoft.com/).

YES. This shows a DOS inside JPC inside IKVM (Java) inside .NET. :-D

Something I have been wondering.... GCC now accepts Java source and emits either native binaries or Java bytecode. Can it take C/C++/etc and emit bytecode? If it is treating bytecode as just another target what if a C# frontend were written? Could gcc take C# on input and emit Java bytecode on the other end? And if a mono backend were added could it compile Java source to it? And if this all came to pass would it be a sure sign the end of times were at hand?

Something I have been wondering.... GCC now accepts Java source and emits either native binaries or Java bytecode. Can it take C/C++/etc and emit bytecode? If it is treating bytecode as just another target what if a C# frontend were written? Could gcc take C# on input and emit Java bytecode on the other end? And if a mono backend were added could it compile Java source to it? And if this all came to pass would it be a sure sign the end of times were at hand?

Java is already fragmented. The result of open sourcing Java will actually be consolidation, i.e. killing of competing VMs. And a huge open source test suite will greatly benefit all surviving JVMs, which is a good thing.

How can you not see this?

Javas problem is not that it might get fragmented, the problem is that it IS fragmented. Do something about it! Let Java free!

Don't worry, there will be .NET instead.

So Java apps will run in IKVM?

IKVM http://www.ikvm.net/ is all you need

help this girl... http://oneluckyboy.com/

more info about java integration

http://tirania.org/blog/archive/2005/May-17.html

Am I the only person who reads Miguel's blog?

http://www.ikvm.net/

He posted about this almost a year ago. I've been using monodevelop on FC and SuSE for quite some time. It's gotten alot more stable. You all can compile java to mono IL through IVKM.

But let's look at C#. It's completely standardized by the ECMA, both the language itself as well as the underlying virtual machine bytecode. MS cannot change C# or the CLI without running it past ECMA and making the changes publicly specified. They can of course write, build, and publish non-standard assemblies like Windows.Forms, but so can anyone else.

MS can never attack Mono legally (and have promised not to try).

And hell, it gets better -- because the CLI is open and publicly specified, there are a ton of languages built on CLI you can use if you don't like C#, including a number of Lisp and ML variants, if that's your thing.

The biggest challenges for Mono aren't technical. Getting people to write programs that target Mono/Gtk# and getting distributors to include it in their distribution are probably even bigger challenges. Simply, these are social problems which can't be fixed with technology (as is often the case).

see here. If Java runs within .NET, and Java doesn't run .NET, which do you think would be more useful?

I have an idea: I'm going to write a new .Net VM.... in Java!

Good interview of Miguel de Icaza about Mono.

Notable reduction in the IKVM's size (thanks to Eclipse Java Compiler [jdtcore.jar]).

More about IKVM's weblog.

Good LiveCD Monoppix-v1.1.8.0!!!

;)

By + + + J.C. Pizarro + + + ATH OK.

Good interview of Miguel de Icaza about Mono.

Notable reduction in the IKVM's size (thanks to Eclipse Java Compiler [jdtcore.jar]).

More about IKVM's weblog.

Good LiveCD Monoppix-v1.1.8.0!!!

;)

By + + + J.C. Pizarro + + + ATH OK.

wtf does Mono have to do with Java?

From the Mono frontpage:

Mono is a platform for running and developing modern applications, based on the ECMA/ISO Standards. Mono can run existing programs targeting the .NET or Java frameworks.

And also, from the Mono Java page:

Execution of Java code in Mono today is done with IKVM (http://www.ikvm.net) the Java virtual machine that runs on top of the Common Language Infrastructure.

Today IKVM is fully supported by Mono and its part of the standard Mono package distribution. As it stands today, it is able to run popular applications like Eclipse and Derby.

> It would be interesting to see how java would perform if a bytcode compiler could be written for it that targeted the Mono CLR.

Like this? Doesn't run AWT or Swing, but oddly it does run Eclipse (or did). Can't say what the speed's like though. Most CLR 1.x bytecode's pretty easy to translate to Java (albeit things like delegates are rough), but the 2.x CLR (Whidbey) is quite a bit different -- generics at the bytecode level, for one.

IKVM is a Java VM built for Mono and MS.NET. Not exactly what you said, but it's a good start.

If developed for Java, you could easily use it from C# with IKVM.

Python, which also bears little resemblance to C#, also appears to run very nicely on .NET and pretty well on Mono. http://ironpython.com/. While they aren't all open source, there are also many other languages with compilers directed at the CLI: http://www.gotdotnet.com/team/lang/.

Finally, there seems to be no reason to suppose that Java is somehow more flexible than .NET because Java can be run on Mono via the IKVM project http://www.ikvm.net/.

I'm not advocating the use of Mono (and I'm certainly not advocating the use of Windows), but arguments against it should be technically correct.

Kluge

Sun are not "testing the waters". Instead they are continuing to follow their extremely successful strategy of the last few years. What Sun really don't want is a viable open source clone of Java, whether it is gcj or IKVM. So, every so often they make noises about open-sourcing things. This means that people think working on the open source Java clones is a waste of time. People also carry on working on open source Java applications, providing Sun with help that Microsoft can only dream of.

Why do you think Mono is now days away from a 1.0 release, while gcj and classpath are still lagging the current Java? Because everyone knew that Microsoft would never open-source .NET. The .NET system is probably better than Java, and we knew that if we wanted a free version we would have to write it ourselves.

This is the reason why Sun's strategy is, ultimately, misguided. .NET and c# are very nice to develop with, there is a high quality open source version, and the platform has Microsoft's marketing clout behind it. Oops...

There are languages that come with their own, specialised runtime with distinct advantages. Highly dynamic languages like Smalltalk or Ruby come to mind

The CLR does a pretty good job with dynamic languages, despite what the poor results from the programmers at ActiveState have said after their halfhearted attempts to get Perl running under it. IronPython (A Python compiler and runtime for .NET) is turning out to be faster than the original C Python implementation.

MSIL is just as suited to running a dynamic language as regular assembly is.

as well as languages like Ada or SPARK, where the compiler does all the checks and correctness proofs, so it's perfectly valid to compile everything down to low-level, unchecked machine code in the end

That's what the Microsoft.NET CLR does. MSIL was intended from the start to be able to JIT as efficiently as possible, so it was designed to be type-checked and provably safe, so the JIT can output optimal native code -- in most cases, it'll emit exactly the same code that a native C compiler would have output for the same routine. Microsoft's implementation never interprets the MSIL bytecode for execution. The Mono implementation only does if you use the debugging "mint" tool, or if you're unfortunate enough to be running on a platform they haven't created a JIT for yet.

This is a striking contrast to Java, whose bytecode was JITted only as an afterthought. The CLR can run Java code, but it can't optimize it that well due to the unavoidable overhead that the Java design enforces.

Using the CLR as the common base for everything would cost an order of magnitude of performance

You seriously owe it to yourself to look into C# if you think it's "an order of magnitude" slower than native code. You'll be very pleasantly surprised by its high performance. You might even have a hard time telling it apart from native code (Windows.Forms notwithstanding).

Mono beta 2 now includes a Java VM. "allows Java and .NET code to run side-by-side. It contains the latest release of IKVM.

Sun's Java Class Libraries are very nice and full featured, if Java was open-sourced, I'd see Mono and Java merging together quite nicely. Write in whichever language is most comfortable, and call whichever API does the job the best.

I see this as a good solution for Sun which is seeing developers leaving for .NET, turn to them and say, you can still use Java.

Well there is a compelete java vm which can run exclipse for mono. ( i know thats pretty hard to get the head around )

ikvm

also all major asp.net applications run

Say hello to IKVM!. It works with Mono and MS's .Net implementation, and has already been demonstrated running full-fledged Java applications like Eclipse, along with translating between aspects of the Java and .NET world. It's a very cool project, and I look forward to seeing it completed.

Yeah, that would be cool, Or, you could use IKVM and get the same effect, today. It can already run Eclipse on .NET or Mono, your choice. :-)

McNealy's wrong. Open source Java is knocking at the door. And worse yet, it will run on Mono not a JVM!

IBM has been much nicer with Eclipse. And You can now combine that, with GNU Classpath and IKVM.NET to bring you Java Eclipse on Mono .NET!. Be free to mix and match the best of two languages. With Free Software you are free to do what some coorporations would never want to happen. Even if it is the best for developers and users!

Amazing! And of course you can just use java as a as a normal language with GCC (gcj). We even have native eclipse! Super fast, no slow bytecode interpreter needed.

Go away Sun with you proprietary closed non-free java! We don't need you anymore.

IBM has been much nicer with Eclipse. And You can now combine that, with GNU Classpath and IKVM.NET to bring you Java Eclipse on Mono .NET!. Be free to mix and match the best of two languages. With Free Software you are free to do what some coorporations would never want to happen. Even if it is the best for developers and users!

Amazing! And of course you can just use java as a as a normal language with GCC (gcj). We even have native eclipse! Super fast, no slow bytecode interpreter needed.

Go away Sun with you proprietary closed non-free java! We don't need you anymore.

Then take your Java library code, compile it with IKVM running on Mono, and write code in C# using it without being locked into any vendor :)

Eclipse is running inside IKVM.NET, a JVM for .NET/Mono. The idea of IKVM is to allow Java bytecodes to run inside a .NET VM. It's pretty cool, check out the FAQ.

Eclipse is running inside IKVM.NET, a JVM for .NET/Mono. The idea of IKVM is to allow Java bytecodes to run inside a .NET VM. It's pretty cool, check out the FAQ.

It would also mean you could run Swing on .NET through IKVM.

There is a c/c++ IDE option if needed, but its convoluted as hell!
from the faq:
"...you can import the glade toolkit bindings into Eclipse running on Mono using the open source IKVM Java virtual machine for .NET by Jeroen Frijters..."

love, peace, hope, dock

miguel

I also don't see why someone would want to write a JVM for the .NET CLR, perhaps someone wiser than I could enlighten us (after looking on the IKVM FAQ none of these questions were answered partically well.. :)