Domain: ikvm.net
Stories and comments across the archive that link to ikvm.net.
Comments · 42
-
Re:A real Java compiler?
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. -
Re:Oracle's open license is viral
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. -
Re:Android
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. -
Re:Hadoop is written in Java
Since it's written in Java, they can just run it on the
.NET virtual machine using IKVM. -
Re:Minecraft
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.
-
Re:Speed
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. -
Re:What language for business logic?
I tried searching for jvm on top of clr and the first ten results didn't look relevant.
-
Here 'tis...
-
Re:monoYou may wish to check out 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.
-
Re:The point of Mono?
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/).
-
Re:can you run java in the x86?
YES. This shows a DOS inside JPC inside IKVM (Java) inside
.NET. :-D -
Re:Don't get yer hopes up
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?
I know it's too late for anyone to read anyway - Managed C++ in the Microsoft world does something very similar. However, there're certain limitations that come into the picture when targeting byte-code. It works reasonably well, and is a choice for people migrating into the managed code world with a large C++ codebase. For converting C# code to Java and vice versa, checkout IKVM. It's an impressive piece of tech; folks have even converted Eclipse to run on Mono. -
Re:Don't get yer hopes up
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?
I know it's too late for anyone to read anyway - Managed C++ in the Microsoft world does something very similar. However, there're certain limitations that come into the picture when targeting byte-code. It works reasonably well, and is a choice for people migrating into the managed code world with a large C++ codebase. For converting C# code to Java and vice versa, checkout IKVM. It's an impressive piece of tech; folks have even converted Eclipse to run on Mono. -
Java is already fragmented
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! -
Re:But what about Windows?
Don't worry, there will be
.NET instead.
So Java apps will run in IKVM? -
Mono and Java integrate nicely
IKVM http://www.ikvm.net/ is all you need
help this girl... http://oneluckyboy.com/ -
Re:windows application interoperability
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. -
Re:Standard emulation/abstraction platform?
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.
Yes, C# and the CLI are standardized. However, it's false that Microsoft can't change the language without running it past ECMA or specifying their changes publicly. Microsoft can do whatever they want to their version of C# and CLI, but if they do, they might invalidate some of the benefits of having an ECMA standard. It would be stupid for Microsoft to extend C#/CLI in ways that violate the standard because it'd give Sun free ammo to use against them.MS can never attack Mono legally (and have promised not to try).
Not true. Mono's XSP (ASP.Net compatible)features may or may not be covered by a patent that Microsoft holds. Microsoft has whispered about this patent but never really come out with any real details about what it entails. Mono's developers have said that if Microsoft makes a fuss about it, they're prepared to rip out XSP provided there's no way to work around the patent. C#/CLI/Gtk#/etc are all unencumbered, or properly licensed, so there's very little Microsoft could do about their inclusion in Mono.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.
heh. Even Java bytecode. To be fair, there are a lot of Java VM languages (virtually all of them are just "research projects", aka toys), but no one uses anything other than Java for any real work in it. I doubt people use much other than VB.Net and C# (and maybe a few holdouts that still use Delphi) to work with .Net, too.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).
-
Re:let me get this straight ...
see here. If Java runs within
.NET, and Java doesn't run .NET, which do you think would be more useful? -
Re:Except...
I have an idea: I'm going to write a new .Net VM.... in Java!
Already been done... sort of. See Visual MainWin for J2EE. It's based off of Mono's implementation of the .Net libraries.
Oh, and don't forget Java on .Net!, either. -
A lot of historical info.
-
A lot of historical info.
-
Re:Wrong wrong wrong wrong
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. -
Re:CLR performance and Java
> 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. -
Re:All in it together
IKVM is a Java VM built for Mono and MS.NET. Not exactly what you said, but it's a good start.
-
Re:Why
If developed for Java, you could easily use it from C# with IKVM.
-
Re:Miguel has told you why
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 will NEVER open-source Java
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... -
Re:hoist by their own petard
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). -
Re:Too little, too late.
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. -
Re:What applications are there
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 -
Java on .NET is an open source reality.
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. -
Re:I see: Java bytecode to MS CLR cross assembler
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. :-) -
IKVM Aswers
McNealy's wrong. Open source Java is knocking at the door. And worse yet, it will run on Mono not a JVM!
-
Re:We dont need your stinkin javaWait till you see what happens if you are truely Free to mix and match all that goodness! Sun and Microsoft would never allow something like combining Java and C#. But that is precisely what thos GNU-heads have been doing!
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.
-
Re:We dont need your stinkin javaWait till you see what happens if you are truely Free to mix and match all that goodness! Sun and Microsoft would never allow something like combining Java and C#. But that is precisely what thos GNU-heads have been doing!
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.
-
Re:C# vs Java
-
Re:Very good news for Eclipse
-
Re:Very good news for Eclipse
-
Re:Native Java
It would also mean you could run Swing on
.NET through IKVM. -
Re:not an IDE
-
Re:Just out of curiosity...I have no idea
:)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.. :)