J#

fuze writes: "It's basically a way for Java developers to migrate their Java apps to .NET.... even provide a 'convenient' migration tool... check it out on MSDN." News.com has a story describing Microsoft's plans to suck Java into .Net, and some commentary saying basically, "No one will use it".

Comments

Re:Of course "no one" will use it

[jilles]

Even as a migration tool its use is limited to projects using the partial jdk1.1.4 API MS supports. Basically any serious Java project nowadays is written using the Java 2 (i.e. 1.2 and upwards) API. And if they are written to the 1.1 API they likely use jdk1.1.8 rather than 1.1.4.

So basically it is a migration tool for J++ applications. Considering that is a MS product, it makes you wonder if this is the best MS can pull of after all the sole reason migration is needed is because MS decided to drop Java support (so they already screwed you once).

And even for J++ it is limited since it only allows you to compile source code, you lose information stored in e.g. forms, project files and so on. In addition, Java objects tend to be closesely tied to the Java API and reusing them basically means you are using the Java. So you might as well go for the real thing (including richer API, better performance and so on) and use the com bridge to communicate with the objects.

In any case, if this is just a migration tool, MS is going through a hell of a lot of trouble to present it as a Java alternative.

Some advise to people considering to use it:
- After 'migration' it is still Java code you are using. It won't be much faster and you will still have to maintain it.
- MS is not very Java friendly, they might drop support for the migration tool at their convenience. The long term strategy is C# (if it ever takes of), not J#.
- Migration to real Java is probably much easier unless you heavily rely on MS specific APIs
- There are ways of letting Java objects talk to COM objects (and consequently also .Net objects) that don't require recompilation.

Re:This is good news...

[Osty]

Is it a good idea? I can see that it would be - if it weren't for the small point that it only runs on Windows. If you're only going single platform then surely you'd be better off going native code and just using the same compiler back-end for all languages (as Borland do for Delphi and C++ Builder - which both run like sh*t off a shiny shovel).

For now, yes, the .NET framework is only available for Windows. However, Microsoft has committed to providing a reference implementation for the *BSDs (FreeBSD, I believe), and other projects like Mono have sprung up to bring an implementation to Linux and other unix-like operating systems. Since Microsoft has submitted both the CLR and C# to ECMA for standardization (say what you will about ECMA, but at least it's a standards body), anybody can write their own implementation. Sun's backed out several times on submitting Java to ECMA.

Of course, if they didn't have this CLR, then they couldn't make the claim that they were going multi-platform so it looks like they just found a way to slow down your Windows code for no good reason.

That would be true, if it were the case that CLR bytecode only ran under the VM. However, that's not the case at all. The CLR has the ability to compile its bytecode down to native code for whatever machine you're on. Most likely the way this will happen is that CLR bytecode will be "shipped" (in a box, or as a download), and as part of the installation that bytecode will get compiled to your platform. What that means is that, taking a Windows-only view for a moment, when you buy Office.NET (just as an example -- I don't know whether Office.NET will be targetting the CLR or not), it won't matter whether you're running on a 32-bit x86-based system, or on a 64-bit iTanium (or whatever AMD's 64-bit chip is called), the same version will run on both. And with native speed, because after installation, you'll be running native code. Obviously, it's developer choice whether or not to compile down to native code, but that's the point -- the choice exists. And given full CLR implementations on other platforms, I don't see any reason why pure CLR bytecode wouldn't be perfectly cross platform, even to the point of compiling down to native code and running as a native app on your chosen system. Perhaps this is how we'll eventually see IE, Office, etc on Linux? (Through the efforts of Mono)

Re:Initial reactions

[GreyPoopon]

How can it be evil for MS to INCLUDE a browser / media player / etc in XP, viciously anticompetitive and so forth, ...

and...

simultaneously evil for MS to EXCLUDE a JVM in XP?

Actually, there's a pretty simple answer to this. Both of these actions kill competition.

Microsoft owns the browser, media player, etc that it bundles with XP, so they can eliminate competition by including them and making them impossible or extremely difficult to remove. The problem is that most people will not know enough or be motivated enough to switch to a competing product. So, since Microsoft owns the OS, they can be reasonably certain that people will use their integrated browser, media player, etc. By doing this, they can also be reasonably certain that companies who develop content for these products will be inclined to purchase Microsoft products to aid in the development of that content.

Java is a slightly different story. Microsoft does not own the Java technology. They have to play ball with Sun in order to use it. They have to follow Sun's rules. But more importantly, there is quite a bit of competition for Java development environments. Supplying a JDK or JVM with their OS does not in any way motivate developers to use their development environment, unless they can add proprietary extensions or other changes to the language to make their development products attractive. They attempted this with J++ and have been told they can't. So, since they can't make any money from J++, they decide to develop their own environments and languages, and bundle THOSE with their OS instead of Java. That effectively kills competition by sending a message to developers: "Do you want your application to run without hassle on 95% of desktop systems? Use .NET."

Try and remember that these tactics are only questionable because Microsoft has a MONOPOLY. That is the defining factor. Otherwise, they'd be considered good business practices. If Microsoft had only 30% of the desktop market, bundling the browser, media player, .NET technology and other things with XP would only help them to be certain that most of that 30% would be using their technology and their tools. They would be forced to make their tools operate on other desktop environments in order to increase market share. This would put them on an even playing field with their competitors. However, since they currently dominate the desktop market, the game is way too easy for them. Tricks like inclusion / exclusion just help cement their monopoly in other areas of the market. It is illegal to use a monopoly in one market segment to stifle competition and increase market share in other segments. Both of these tricks accomplish this. You really have to look at the end results.

Competition never hurts. I welcome J# completely.

[javabandit]

First, a disclaimer, I am not a Microsoft advocate. Those guys can stick it up their ass. That being said, I will do what it takes to do my job and get paid.

The issue here is that *many* Java developers have been trying to code quality front-end applications on Windows using Java -- and have failed (or fallen very short). *I* am one of those people who have done so. I know many other Java developers who have failed to meet their expectations reasonably when coding on Windows.

If I know that my target platform is only going to be Windows, but I can't use any of the Windows libraries... what good is Java? Its not. So I have to go back to C++. But C++ is a horror in its own ways.

Too many in the Java community are zealots about what Java should and shouldn't be used for. The idea that if it isn't WORA (Write Once Run Anywhere) then it shouldn't be written in Java is completely ludicrous, IMHO.

Some Java developers want the elegance of Java with an easy way to utlitize Windows native libraries without having to write convoluted JNI interfaces all over the place.

The answer is J#. However, I was perfectly happy with the idea of C#. C# has some compilation advantages and syntax advantages over Java that I really love.

I have extensive experience with Swing (Java GUI libraries), and they just simply don't cut it for serious front-end application development. The more complex controls such as JTable and JTree are full of bugs, they are difficult to use, and complicated. If you want less complicated controls, you have to buy a proprietary vendor's API and use those, instead. The Windows 'look and feel' does NOT look and feel like Windows. Because of the MVC design, you have to import practically every single class in Swing into your programs.

AWT was much more compact and easy to use. It also was pretty snappy; however, it suffered from lack of GUI controls.

I don't see anything wrong with J#. If it works for you and serves your purpose, use it. If it doesn't, then don't.

But a little competition in the Java marketplace (or any marketplace) never hurts. Maybe it will light a fire under Sun's ass and get them to contribute more to the front-end side of Java -- which has been ignored for far too long.

Better yet, maybe they will open-source Java, instead. Even better.