From MSDN: “Welcome to Beta 2 of Microsoft Visual J# .NET, a development tool for Java-language developers who want to build applications and services on the .NET Framework. The tool integrates the Java-language syntax into the Microsoft Visual Studio .NET IDE, and supports the functionality found in Visual J++ 6.0, including Microsoft extensions such as JavaCOM and JDirect. Microsoft Visual J# .NET is not a tool for developing applications intended to run on a Java virtual machine. Applications and services built with Visual J# .NET will run only in the .NET Framework; they will not run on any Java virtual machine. Visual J# .NET has been independently developed by Microsoft. It is not endorsed or approved by Sun Microsystems, Inc.” The installation file is 12 MB.
Microsoft Visual J# .NET Beta 2 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
When are these idiots going to figure this out? You think they would have learned by now that they just can’t do whatever the hell they feel like doing.
It’s getting tougher everyday to be a Microsoft supporter……
M$ is always BETA however beta 2 is someting new;-) (New language??)
“When are these idiots going to figure this out? You think they would have learned by now that they just can’t do whatever the hell they feel like doing.”
Oh, yeah? Well, the DotGNU Portable.NET folks are creating a C# compiler that creates .NET CLI binaries or JVM binaries. So Microsoft can compile Java to .NET CLI and GNU can compile C# to JVM. Is there a difference?
No, there is not and both organizations are free to do what they like in this regard. Sun could not win a lawsuit on this issue. They would have to sue GNU over the GCC based Java compiler as well. They would also insure that C# would never run on a JVM because Microsoft would have to sue GNU over the Portable.NET compiler. Add to that the fact that every suit would lose and you have a recipe for things just staying the same as they are now
The purpose of this is to allow developers who know how to program in Java to build native Windows apps. This isn’t them “doing whatever the hell they feel like doing”
If you hava a problem with this, then you must also have a problem with things like Waba and SuperWaba that let programmers use familiar Java-style programming to create PalmOS/PocketPC apps.
This doesn’t supplant Java, as the only usage is to create windows apps. If you have no need to create Win apps, then don’t bother with it. If you would like to create native Windows applications, but don’t know VB, C#, or C++ (but do know Java) then this is a good tool for you.
As though anybody doubted for a second that Microsoft would do this. Seriously, people. =)
This is really more of a *migration* tool, so that people with existing Java based solutions can re-compile them, and see how much faster they are in the CLR environment.
C# is enough like Java that Java developers would have no problem switching to this as their main language.
Yes, but since it only supports the abilities (and Windows-only extensions, ugh) found in Visual J++ 6, then it does not support the newest parts of Java from JDK 1.2 and up. The Microsoft Virtual machine (for Java) stopped at implementing Java 1.1.6. This is the annoying part.
The sole motivation behind this release is to support the people who actually USED the Windows only Java extensions and yank them onto MSdotNET before the Sun guerilla forces get them to migrate to the newest Java platforms. I highly doubt MS really wants lots of pure Java apps on MSdotNET, as they would run much faster using Sun’s virtual machine, which means one is no longer dependent on Windows.
-JM
” highly doubt MS really wants lots of pure Java apps on MSdotNET, as they would run much faster using Sun’s virtual machine, which means one is no longer dependent on Windows.”
Why would anyone want to code pure Windows apps for Suns JVM anyway? Doesn’t that sort of defeat the purpose?
On one hand, if it’s pure Windows (meaning Windows only), it defeats the main advantage of coding in Java. And on the other hand, using JVM insures that your apps are going to run slower than snot on a doorknob.
… the land of 10,000 languages 🙂
java is not slow, just miss-placed.
Does C#.NET have:
1) Layout managers ?
2) Html doc like java’s (The existing filtering system is not enough, as it does not work in the index and search.)
3) Freedom to code in whatever editor you like or is Visual Studio . NET extremely necessary ?
4) Drivers to the open source databases: PostgreSQL, MySQL, SAP, FireBird, etc ?
5) Runtime Environment smaller than Java’s ?
6) Comunnity larger than Java’s ?
I don’t know much about C# except that I do know it is not necessary to use the Visual Studio editor (though honestly, I don’t know why you wouldn’t if you have access to it).
You can use whatever editor you want and compile from the command line.
As for all the other stuff you mentioned, I have no idea. But the question I have to ask you is, since we were talking about coding pure Windows applications, since most Windows apps have GUIs, if you code a fully-functional GUI app to run in Windows, how fast is it going to run? Will it be usable, or will it be something like HotJava? What is the speed comparable to C# or any language on the .NET platform for that matter?
I realize this isn’t a relavent topic when you’re talking about cross-platform development, but even then, when it comes to coding GUI user/desktop apps and not web services or some embedded application, I would think a C++ solution using QT, wxWindows, or some other toolkit would make more sense to use than Java.
7) Threading like Java’s?
8) Good coding conventions? (none of that AllCapitalMethodTitle() stuff)
9) Open Source IDEs and _multiplatform native toolkit_ like SWT?
10) Source availability?
>Does C#.NET have:
A conversation I had some days ago with a java-experienced developer who had recently checked out C#, said that C# is way more advanced than Java in many ways and with killer language features…
can you give us more insight?
What when (not if) MS pulls the rug from under your feet?
MS did not submit all the specs to ECMA, what do you think why? Because it’s still the old Microsoft. Because they want to control the APIs and have their hands on your balls.
“The purpose of this is to allow developers who know how to program in Java to build native Windows apps. This isn’t them ‘doing whatever the hell they feel like doing'”
No, J# will not allow you to write native Windows apps. It will only let you write .NET apps.
J# sucks as bad as J++ did. Do yourself a favor and stick with pure Java. You’ll be a lot happier.
“C# is enough like Java that Java developers would have no problem switching to this as their main language.”
Comparing C# to Java is like comparing a clown with a red hat to a clown with a red hat.
with java’s new preferences api, nio and swt from ibm, i’m the happiest person in the world
“And on the other hand, using JVM insures that your apps are going to run slower than snot on a doorknob.”
When will the majority of the readers on OSNews actually try using a Java application so we can once and for all get past the 5 year old speed issues in Java which don’t exist anymore?
Look at Jakarta. That is a Java project and it runs fast enough to be able to be used as a web server and a Java container for sites with quite a bit of traffic.
I use Java all the time and it even runs faster than compiled C programs in certain arenas.
for the last year I have been developing multithreaded (30+ threads) programs in java. I used a lot of serialization, synchronization and I/O. using java.nio proved to be the best choice. it is FAST, really fast, and compatible with java.io
I have used C# at work for a while. One thing that I do like about it is its way of handling threads. It also is more responsive in some areas than I expected it to be (slower in other areas though).
My opinion of C# and its VS IDE is it is 95% Java and 5% Delphi (which is a good thing).
Overall I don’t think much of C# though. Not because it’s not a good language, but because there is nothing new here. It’s all been done before. It’s just another MS “technology” that their marketing department is going to ram down the worlds throat (or serve it up enema style, whichever way works). There is not a single compelling reason that I have found for me to drop my investment in Java and other languages and switch to C#. None at all.
Also, C# is not crossplatform (unless you use Microsoft’s definition of the term, which is Crossplatform: The ability to run on Windows 9x/NT/2000/XP). There are parts of it that will be crossplatform if and when GNU.NET or whatever it is called is done, but the Windows Forms are just like the WFC from J++ 6.0. Windows only. I’m not an expert yet, but the window forms seem to be the only way to make a GUI. If so, I doubt C# will ever be useful for anything on non-Windows platforms.
That’s one thing I like about Sun. If there is a JVM available for your platform, Java apps are going to work for you. It’s not like Sun created a JVM for Solaris that was really cool and then released JVMs for all the other operating systems that only let you write Hello World programs.
Overall, in my opinion, C# and the whole .NET thing are just like every other Microsoft product ever released. More marketing than substance.
I is/was a huge Java fan simply because of it’s productivity being atleast 2x better than C++. Do I use it now on current projects?, no, absolutely not. I wish I could but I dare not due to run time speed. Last time I tried to build a cad app using (Visual Cafe) off screen, double buffering techniques, the app was written quickly, but it was & still a memory & cpu hog. In C++ I can manage the big memory buffers without them being recreated all the time, & more importantly I am allowed to write special purpose drawing libs that can be 10x faster than std Mac/Win APIs & can use asm for inner loops. As long as Sun keeps religous views about language purity they lost me.
As for JNI, enough to turn me right off mixing C++/Java. At one time I used Supercede compiler, it was a native compiler with 2 front ends, shared backend. it usually produced native Java about same speed as C++. It allowed C++/Java classes to be mixed, but it was buggy & out of date & they went down.
Now C# looks like it could have Java productivity & reliability with C++ speed & flexibility if & when I need to go lowlevel. If it shows up on more platforms I’ll buy into it. Now I wonder if the GTK Mona project could be picked up by the OBOS team later on, would be great to see future apps having Win/Lin/Mac & OBOS homes.
“Look at Jakarta. That is a Java project and it runs fast enough to be able to be used as a web server and a Java container for sites with quite a bit of traffic.”
That may be true, but a web server isn’t exactly a full blown desktop/GUI application .. it’s a server.
Show me something like a full-featured email client or word processor (GUI, not console) that runs at a decent speed, and I’ll take back what I said about GUI/desktop apps coded in Java being slow.
Until then, you can go on all day about how great the Java language is, but I need something I can use to create apps for the end user that won’t have them waiting for 3 hours just to load up the program.
It’s Ironic that now MS wants to go to a virtual machine language after so many years of shooting it down. Can’t someone dig up some old press from MS about how Java was such a bad idea and distributed apps would never work.
Frankly that’s why .net is getting such bad karma–people were told that virtual languages were bad for so long that they can’t now under stand that it is good.
Actually, everything on the .NET platform compiles directly to machine code, there is no VM. The code exists as MSIL (Microsoft Intermediate Language) at first but the first time it is called, it is JIT compiled to low level machine code and then stays that way (unless recompiled for changes, etc.). That is why .NET is much faster than Java. Also, the .NET compiler is smart enough to optimize the code it compiles specifically to take advantage of the configuration of the machine machine (CPU extensions, etc.) that it is running on.
C# and the ‘managed’ C++ extensions do provide automatic memory management, but there is no VM layer involved. The Common Language Runtime (CLR) is just a library, more or less, exactly like the old VB runtime DLL. Not a true VM at all.
Also, FYI, VB.NET is no longer an interpreted language like VB ‘classic’ was. You can no longer make code changes on the fly as you are stepping through code in the debugger. Now, you must always compile before you can debug. All of the .NET languages are like this.
> When will the majority of the readers on OSNews actually
> try using a Java application so we can once and for all
> get past the 5 year old speed issues in Java which don’t
> exist anymore?
When will the majority of the Java evangelists everywhere finally accept the fact that not every anybody is writing uncritical stuff like mail clients where Java is viable?
I’m writing enterprise level software for a living. Our team knows Java. Our team is developing Java. And there are certain (and not small, mind you) parts of our application that are written in C++, BECAUSE JAVA DOES NOT CUT IT.
Java is sure much quicker than it was at the beginning. Which makes it useable in certain areas, instead of being pure crap. But it isn’t suited for any everything.
>Actually, everything on the .NET platform compiles directly to >machine code, there is no VM. The code exists as MSIL >(Microsoft Intermediate Language) at first but the first time >it is called, it is JIT compiled to low level machine code and >then stays that way (unless recompiled for changes, etc.). >That is why .NET is much faster than Java. Also, the .NET >compiler is smart enough to optimize the code it compiles >specifically to take advantage of the configuration of the >machine machine (CPU extensions, etc.) that it is running on.
So does Hotspot – so the speed between C# and Java would be the same (if we’re talking JIT only)
However Hotspot does NOT save the jitted code since jittet code is optimized for the codepath being run. So imagine a program that uses codepath A highly. Then restart that program and use codepath B a lot – on a M$ VM it would be dog slow – however on Hotspot it would be just as speedy as codepath A (although startuptime would be slower).
“…So imagine a program that uses codepath A highly. Then restart that program and use codepath B a lot – on a M$ VM it would be dog slow – however on Hotspot it would be just as speedy as codepath A (although startuptime would be slower).”
Actually, no. .NET code is saved to what are known as assemblies. These are basically like DLLs (they even have the same filename .dll extension as ‘real’ DLLs do) but they start out in a state of uncompiled MSIL.
After it has been JIT compiled for the first time, an assembly functions exactly like any regular DLL written in C++. The entire assembly is compiled and saved, once. There is no optimization done for any specific codepaths, like the HotSpot compiler does, so it is always as fast as C++ no matter how it gets used or is called.
What’s this thing I keep hearing about .NET?”
🙂
“Java is sure much quicker than it was at the beginning. Which makes it useable in certain areas, instead of being pure crap. But it isn’t suited for any everything.”
Good point. No language is the perfect match for every application. I use many different languages to do many different things and each one has it good and bad points. However, I use Java all the time and it is excellent at what I use it for (which is also enterprise level and web applications).
I agree with you on a lot that you say about Java, and while speed is not as big an issue as it used to be, some aspects of the UI (mostly due to programmer error) can be slow.
the SWT toolkit removes those issues because it uses native widgets
“After it has been JIT compiled for the first time, an assembly functions exactly like any regular DLL written in C++. The entire assembly is compiled and saved, once. There is no optimization done for any specific codepaths, like the HotSpot compiler does, so it is always as fast as C++ no matter how it gets used or is called.”
Which is the problem… The Hotspot compilet can optimize A LOT. Fast Fourier Transformations for instance, can perform much better when hotspot compiled, since it can do profiling and runtime optimizations. Something statically compilling cannot do (which is what M$ is doing…).
Example: http://www.aceshardware.com/Spades/read.php?article_id=154
Camel
I use Java all the time and it even runs faster than compiled C programs in certain arenas.
I find this *VERY* hard to believe. With consideration of CPU instructions alone, Java executes many times more instructions than C code does. First of all, object orientation is very, very expensive from a computer resources standpoint (I’m not saying it is a bad idea). What is one of the primary tenets of OO? You build classes with methods for just about everything you want to do. When was the last time you saw a C funciton that executed one line of code? Do you know *why* you don’t see that? Because it is very expensive to make a funciton call! You have to do a whole bunch of work to get all your params on the stack, and then you have to do the dreaded jump. What happens if the code you’re trying to jump to isn’t in cache on the CPU? You have to go to main memory to get it! We’re talking like 100 cpu cycles here! What if it isn’t even in main memory, and you have to go to virtual memory? 1000’s of cycles! All this, when you could just have loaded up the registers and made a couple asm calls to get the work done.
Now, that said, I should make it clear that I think OO is a good thing. OO allows for a much easier time with regard to maintnance, as well as providing a good way to clearly divide work (along class boundaries) among individuals working on a project.
Now, consider the fact that Java is not *just* OO, but also contains garbage collection. This is even more overhead! Now, you’re maintaining some table behind the scenes that keeps track of the locations in memory of allocations made by your process. Every time an alloc occurs, you have to go muck around, incrementing reference counts, keeping track of sizes of things, etc… All of this work takes 1) CPU Cycles, and 2) Memory! For this reason, languages like Java and C# will never be as fast as vanilla C. The logistics are just not possible. The simple fact is that you *must* execute *more* instructions to get the *same* results under an OO Garbage Collecting environment.
To continue… JVM/JIT. This is the most horribly slow of all. In this one arena, C# and the CLR win hands down. JVM = execute every instruction *at a minimum* of 2 times. 1 time in JavaByteCode [CAFEBABE] and one time in the native language of your machine. I think everyone agrees on this point. The big problem with the Java JIT is that it gives up the compiled bits, after it has JIT’d them. The CLR keeps the native bits around, and only recompiles when it detects a change in the CLR object’s byte code. This single factor accounts for an enormous speed increase. After the initial JIT compile (first run), Microsoft’s CLR is faster than JVM/Java JIT ‘.’ If anyone can prove me wrong, I’ll gladly make a public retraction (at this venue of course
) of my last statement.
Now does anyone out there still really believe that C is slower than Java under *any* circumstances? The only way I can think to make C slower than Java is to build a compiler which executes 3 arbitrary instructions between each line of usefull code.
why don’t we all code in asm to be l337 h4x0r cod3rs?
Heres the deal – It has nothing to do with the language. It’s all about using a runtime profiler/optimizer like Hotspot.
I can create a program that will run loops around a statically linked C program. It doesn’t matter whether or not method calls and so forth is used – it’s all optimized and inlined when Hotspot gets going.
HOWEVER! – if you create a C program that is runtime profiled and optimized, that C program would be faster.
“The big problem with the Java JIT is that it gives up the compiled bits, after it has JIT’d them. The CLR keeps the native bits around, and only recompiles when it detects a change in the CLR object’s byte code. This single factor accounts for an enormous speed increase. After the initial JIT compile (first run), Microsoft’s CLR is faster than JVM/Java JIT ‘.’ If anyone can prove me wrong, I’ll gladly make a public retraction (at this venue of course
) of my last statement. ”
Heh – As I have stated earlier, the problem with storing jit’ed code is that a codepath may change. (HIGHLY simplified) Take a 3d application (not using HW) – at run #1 the user moves around a room with no particle effects and as such the jit compiler will optimize in regards to no particles in the vicinity. This is all fine – on the second run (still no particles) a program using hotspot will start of slower than CLR since hotspot will start over. However
when the user on the 3rd run suddenly enters the ‘Great hall of particle effects’ he is screwed! – CLR *will* perform waay slower than hotspot. Thus CLR would have to dump it’s last run, and we’re back to using hotspot…
This has been discussed on A LOT of other sites, particularly javagaming.org (ie. this thread: http://www.javagaming.org/discus/messages/27/743.html)
Oh – and your GC statement, the GC’er is only active when references are being lost, or allocations occur. In *most* games, you preallocate everything before running – so GC’ing isn’t really a problem, nor is it costly (since it isn’t running).
a game built in Java is already here and it’s kicking ass: IL2 Sturmovik
I’ve looked at some of Brian’s linked articles and found some more on my own that support the conclusion that, in raw terms, Java can actually be just as fast as C.
However, there is still one big, big factor in comparing distributed apps written in J2EE versus ones written in .NET – the COM+ runtime environment. In a large distributed application with a database behind it and many concurrent users, .NET will have the advantage of optimized object-pooling, connection-pooling and thread-pooling that, as far as I know, J2EE/CORBA just does not provide.
This means that even though Hotspot may provide some advantage with it’s optimized JIT compiling, .NET should probably still be faster (in large applications) because the COM+ runtime environment is a bigger leveraging factor, IMO.
I think it is impossible to say for sure until we see some good comparitive benchmarks by a disinterested third party, which just do not exist right now (Microsoft, Oracle and Sun are all basically lying at this time). This will be interesting.
“I’ve looked at some of Brian’s linked articles and found some more on my own that support the conclusion that, in raw terms, Java can actually be just as fast as C. ”
Glad to hear that you have been enlightened
“…bla bla .NET faster than J2EE…”
I haven’t got much experience in distributed applications, but from what I know, J2EE aint all that fast!
So the statement that .NET will be faster that J2EE, is probably correct, however I only think this is true on the Windows platform. I don’t think that a .NET application will run just as speedy on other platforms (and they will probably be more prone to platform differences than Java is).
But no one can know for certain – let’s see in about ½-1 year from now