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

.NET

[staticdragon]

I still don't after all this time understand exactly what is the point, or rather the benefit of .NET. I've even had the on-campus M$ rep try to explain it to me, all to no avail. As to M$ sucking something else into one of their own products, what's new with that? Isn't that what they do best?

Re:.NET

[AssFace]

this is fucking ridiculous - this guy gets a mod score of 2 b/c he says "linux good, grrr, ms bad, grr".
whereas the people that point out that he is *wrong* get modded to zero.
fucking idiots.

anyway, the parent to this dudes post raises some good points - but I'm curious if .NET, since it is a VM on top of the OS, which is what Java is as well - does it run as slowly? or slower b/c it has more languages to work with?

all I know is that I spend all day programming business apps as that guy said, and java sucks balls, but I'm not certain that .NET is the answer to it.

oh and, linux linux linux - I run it, I also run all the MS OS's - so let's see how I get modded.
fuckers.

Re:.NET

[Fraize]

I'll give you some figures I compiled yesterday.

I'm writing an application that will bring our e-commerce site for my company into .NET-land. One of our concerns was bringing COM objects through .NET's interop layer (a translation layer between .NET and COM). We ran some code in ASP that manipulated a large XML dom 1000 times, and execution time took a pathetic 21 seconds (21348 ms).

We, then took that code and re-wrote it in .NET. The exact same operation took 1.5 seconds (1511 ms).

Just to see if it was the JIT compilation that gave us our performance jump, we compiled the same logic into a COM object, and ran it through ASP and .NET. The same operation took just under 1.5 seconds (1487 ms).

The advantage here is clear - You get the same level of maintainability with .NET ASPX files as you do with ASP files, but you get the performance equivelant to compiled binaries.

Re:.NET

[dwarfking]

Coming from the perspective of years of designing and implementing enterprise application, I'm afraid I must disagree with "you really need to use OO". However, I do agree with the remainder concerning coming up with a model, if the model in question is modeling the communications layer between systems.

We have systems written in totally non-OO languages (MVS COBOL, Informix 4GL, RPC, etc) that we leverage quite nicely. Instead of forcing an object model on this, we use a system that either performs HTTP POST requests or passes XML documents around via the HTTP procotol and have adapters invoke the existing code.

For example, we have (don't laugh) COBOL code that generates XML documents. The COBOL code is invoked by an HTTP server listening on the MVS CICS system for POST's.

Currently it isn't necessary to have the COBOL code parse XML as it works quite well with key/value pairs from a POST.

The point was to utilize the existing available services in our 20+ year old enterprise without whole-scale re-writing. All we are doing is writing adapter's.

HTTP as a protocol works very well. Most of the activity with table maintenance in a large enterprise is OLTP, thus psuedo-conversational. HTTP works well in that environment as no real state needs maintaining on the service's side.

O-O is fine, CORBA is a nice idea as well. .NET will have it's benefits. However, considering that there are many large enterprises that have never used O-O that are fully functionaly, high speed and stable, if all .NET provides is an O-O method of performing functions in the enterprise, then I won't need it.

Re:.NET

[Anonymous Coward]

I just want to point out that I've coded both your examples:

+ Web pages/COM hosted in Outlook with offline ASP and MSDE syncing

+ Oracle/Notes integration with offline Notes syncing.

And I'd take the Oracle/Notes solution is a heartbeat over the Microsoft solution. It could be coded in AT LEAST 50% of the time of the MS solution and it's a hellavalot more reliable (Notes syncs code and data, for example, you also have complete control and security over what gets synced).

I'm not saying that MS doesn't have some great technology, particularly on the webserver and middle-tier level, and NET just extends that and opens all sorts of possibilites that weren't available with crappy old non-OO VB.

But once you get beyond that, is where the brainwashing begins. Outlook is really a crappy platform, for example. What you called "Unified Messaging" can be achived by any Unix graybeard with a SMTP gateway and a shell script. There's no reason to put in the solution you described other than to be a MS Drone and lock yourself into more of their products.

So, Microsoft has some good solutions that you should go for. But you have to be a little circumspect. If you aren't, your screwed. (I know people that did lots of Exchange coding via CDO, for example, and we know that that's just going away now, and was a very crappy API to begin with. They're now porting to MSSQL, and kicking themselves for listening to MS to begin with.)

Furthermore, the 'same coder' stuff is a bunch of bull. I've seen those $65K VB guys -- they might be a wiz with your VBX Grid widgets, but they generally can't do n-tier worth crap. If you really think you can go hire a MS Guy that can wander the minefield successfully, you're going to have to hire a real programmer and not just a code monkey. .NET really drives this point home.

Well

[MxTxL]

There is always the fact that Java is being natively excluded from Win XP. The conspiracy theorists among us would probably argue that this move is to have the J# initiative and thus the .NET initiative to be more successful and quash everyone else.

This is good news...

[Jotham]

The CLR (Common Language Runtime) is a great idea and is in my opinion the next generation of programming tools. ie. it doesn't matter what language you prefer or what language library X is written in if they go through the CLR you can use it.

The ability to write in your favorite language C#, C++, VB, JScript, etc and now Java is a huge improvement over locking a project into one language only and missing out on all the other shared libraries because your project is in Java or Objective-C or Python etc.

Unfortunately in removing one lock, microsoft has added another (to their OS). What I'd love to see is a Common Runtime for Linux... unfortunately all I see is people dismissing it or complaining because its Microsoft.

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:This is good news...

[Domini]

I don't think People will use J#, not because it is MS, but because I think people will rather move to C#. (Just my opinion there...)

.NET is so far as I can tell something good... Microsoft has done something right. Don't mock it, it does happen sometimes! I just can't stop feeling nervous...

I'm a Python advocate, and I like the .NET initiative. It may not be all unique ideas, but finally someone if driving it and formalising the processes to get it to a standard.

MS is not oficially giving up on COM, but .NET will certainly downplay it a lot. (Which is also a good thing.)

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.

Control

[Anonymous Coward]

Another attempt by M$ to lure developers they lost to Java, back into their game. The intent here being to (re)invited developers to the .NET party through Java, making every effort on the way to convince them to move their codebase to c#, given the limitations of the JVM they're offering.

Re:Initial reactions

[Anonymous Coward]

So they're STILL installing the ancient MS Java 1.1 VM ? It would be much more useful if they automatically installed an up-to-date Sun 1.3.1 VM...

Also...

[Otis_INF]

(sorry for the separate message, but if I put this text in the other message I replied, Slash will time out. Please fix this)

Also, you don't have to register your components anymore. With COM/COM+ components, you have to register them in the registry. This is not a problem, but updating registered components is. In n-tier webapps, where the webserver has loaded the components in its core process (or separate process, if you've tuned it that way), you can't overwrite the dll and re-register the new components, because the dll is locked (which makes sense). Witb the CLR, just dump the dll in the dir and off you go. Updated the dll? overwrite it. The CLR will automatically see that the file is updated, and reload the components into memory.

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.

Re:Stupid Question from a Non-Programmer

[m_pll]

COM(+) runtime layer is very thin. When you make a COM call, you essentially call raw native code. Which means there is no easy way to implement integrated services like cross-language exception handling, garbage collection, reflection, sandbox security etc.

CLR provides all that and much more.

Re:More importantly :how to pronounce J# ?

[joel.neely]

According to The Elements of Typographic Style by Robert Bringhurst (a standard and
highly-respected reference in the field), the
character "#" is named "octothorp". The origin
of this name? "In cartography, it is also a
symbolfor a village: eight fields around a
central square... Octothorp means eight fields."

(Insert appropriate wisecrack here...)

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.

The Education Market, The Real Target

[CFN]

Almost all of the introductory CS text books use the Java language, and therefore, most intro CS courses teach Java.

This means that thousands of individual students, computer labs, departements, need to use Java compilers or IDEs. With MS no longer able to provide a Java implementation (more or less, I don't know the exact details), they faced the prospect that new programmers (at least untill the curriculum was switched to C#) would learn to program using non MS tools - MS looses the income from selling these tools, and faces the prospect that students 'comfortable' with products from another company might be harder to 'capture' as MS devotees.

By providing a J# compiler, those students can use (read, buy) a MS tool to do their assignments (especially considering that the intro assignments don't use the advanced features of the Java API, which are un-supported on J#) and start along the path of becomming happy MS developers.