Hello everybody!
I am a J2EE fun and I try to convince a confrere of mine the differences between the Java world and the Microsoft.
The guy is very limited and my arguments are not good enough for him...
He tells me Microsoft's .Net it's a J2EE implementation in C++!!! (it's not a joke : the guy is a technical architect in his enterprise...)
Do you have some arguments for him?
Thanks a lot,
Dan Militaru

Dan,
From what I can tell the M$ .Net effort is M$ master-stroke, atleast if your M$ and buy into it because of the hype and don't get a chance to see the details. First, .Net is NOT J2EE implemented in C++. So how is this? The core concept of Java(J2S, J2EE) is as aways:

Develop in Java -->Compile into ByteCode -->Run Anywhere (provided the JVM exists)

.Net is the complete OPPOSITE from Java:

Develop in any language -->Convert into C# --> Run Only on Windows

Not Bad if you like to be tied into only ONE platform, WINDOWS. Again, from a business aspect I think that this is Bills best idea yet at trying to keep code & people on the Windows Platform(his bread n butter)but from a technical aspect I think its short minded and just plain old bad. Make NO mistake @ the root of .Net is C# not C++. M$ will use XML/SOAP as the front line to hide it all from view but the core logic will be C#(remember above)if you code for .Net, tricky isn't it. My 2 cents worth is this, will it win in the long run NO. J2EE, even with it's faults is much more robust then anything M$ centric. One has a focus to better coding and business processes while the other is always focused on trying to keep you dependent on a single platfom, think about it.

LeeC

I originally was more familiar with the M$ DNA strategy and now prefer the J2EE platform. But....

I find almost all comparisons between J2EE and .NET quite amusing. Everyone has an opinion, and most opinions are rooted with false information. The message above about .NET being a C++ implementation of J2EE is laughable. Knowing both environments pretty well, I can usually spot out mis-information is almost any comparison.

But I can tell you one thing, I have known Java since it was called Oak, and with J2EE this is the first time Java has EVER posed a threat to the Microsoft distributed object platform. Let's face, if you actually purchased a commercial component or object in 1999, 19 out of 20 times that object was one that was built on the M$ platform. Sorry folks, that is a fact. M$ owned the distributable component commercial environment. EJB didn't even exist, and CORBA components just have not made a commercial impact.

So why is Java finally going to pose a threat? BECAUSE J2EE IS A JAVA IMPLEMENTATION OF M$ DNA!

Got you attention now, don't I!

Consider the similarities.

ASP -> JSP
COM -> Beans
DCOM -> EJB
MTS -> JTA/JTS
JMS -> MSMQ
JNDI -> ADS
ODBC -> JDBC

And the list goes on. In fact many of the things in the M$ DNA architecture that java bigots said was just too complicated, like three interfaces on an object (a home, a remote, and the bean) made its way in to the J2EE spec. And lets face it, some things in the M$ architecture were just not well designed, like MTS - MTS is the transaction service, it the API, and it is the object container. J2EE nicely separates each of these out logically, but the architecture is the same! So if you have ever done distributed programming in both the M$ DNA platform and the J2EE platform, you know what I mean. The architectural similarities are frightening. And yes, M$ had it first. So who copied who?

The good news is, who cares? J2EE has had the benefit of also witnessing the M$ mix-ups, goofs and failures, and J2EE does not have Legacy stuff to support that M$ has. This should lead to far cleaner implementations than the M$ platform. Furthermore, it is now easier than ever to take a M$ programmer (and usually bigot) and teach them the J2EE architecture - the concepts are the same, just the syntax is different.

This is why I (along with others) believe that J2EE platforms will erode the M$ dominance this year.

Chase

P.S. Another interesting thing about a note such as the one above is that as most people were reading it, they were trying to decide if I was a M$ bigot, or a Java bigot - weren't you?

In think your comparison is not accurate:

QUOTE
Consider the similarities.

ASP -> JSP
COM -> Beans
DCOM -> EJB
MTS -> JTA/JTS
JMS -> MSMQ
JNDI -> ADS
ODBC -> JDBC
UNQUOTE

First, the MS column represent implementations, the java column represents Sun specs with implementations avaiable form many vendors.

Second I think the table must be:

ASP -> JSP
ActiveX -> Beans
DCOM -> RMI
MTS/COM+ -> EJB
DTC -> JTA/JTS
JMS/MQSeries -> MSMQ
JNDI -> ADSI
ADO -> JDBC

to be more accurate.

Ok, maybe I was trying to make it sound to simple, but my point is still the same. Frank, to answer your questions;

Q1: Where did u get this knowlegde?

A1: M$ web site on .NET implementation.

Q2: I'd like to know where u did learn that any language will be converted to c#.

A2: To answer this question I guess I must first ask you a question. Once you have that question in your head I can then expand on my point to hopefully

answer your question.

So, the question is this: At what point does C# stop and .NET start? The quick answer is that it doesn't matter! c# is not a complete self sustained

language, like Java and C++. It's useless without the .NET code base and the .NET JIT native-code compiler/Runtime. This is very important, on the M$ web

site it tells you this:

"Microsoft is planning to create four language compilers that target the common language runtime: C++ with managed extensions, C#, Visual Basic, and JScript.

By default, the Microsoft Visual C++® compiler builds an executable or DLL that does not target the common language runtime; specifying a new command-line

switch will make the Visual C++ compiler target it. The term "managed code" describes code that requires the common language runtime. Unmanaged code

describes code that does not require the common language runtime engine.

Of the four Microsoft compilers mentioned, Visual C++ is the only one capable of producing unmanaged code. Since the other compilers (C#, Visual Basic, and

JScript) can only produce managed code, the code written in these languages absolutely requires the common language runtime engine in order to execute."


Above quote located here : http://msdn.microsoft.com/msdnmag/issues/0900/Framework/Framework.asp

I take it that they mean VB.NET above when they say "Visual Basic". As a quick read through the vb forums will indicate, the VB deverloper communty will be

the first to tell you that VB.NET and VB are not the same thing and that a major re-write is required, many pissed off people there. VB only produces

native"unmanaged" code while VB.NET produces ONLY "managed" code, as stated by M$ above...

Also this:

"C# is provided as part of Microsoft Visual Studio 7.0. In addition to C#, Visual Studio supports Visual Basic, Visual C++, and the scripting languages

VBScript and JScript. All of these languages provide access to the Microsoft .NET platform, which includes a common execution engine and a rich class

library. The Microsoft .NET platform defines a “Common Language Subset” (CLS), a sort of lingua franca that ensures seamless interoperability between

CLS-compliant languages and class libraries. For C# developers, this means that even though C# is a new language, it has complete access to the same rich

class libraries that are used by seasoned tools such as Visual Basic and Visual C++. C# itself does not include a class library."

Above quote located here : http://msdn.microsoft.com/library/dotnet/csspec/vclrfcsharpspec_1.htm


Look at the last sentance "C# itself does not include a class library". Look, here is how it works, your code is written (Any Lanuage), you compile it(With a

language compiler that targets the .NET runtime spec, and the compiler translates it to M$ intermediate language (M$IL). M$IL, now thats a name that

instills a feeling of openness. ;-). Ok, Visual C++ needs a new command-line switch to be able to generate M$IL, VB.NET and C# don't! Why? because VB was

re-writen by M$ to this new .NET Framework which has, at its base, sitting on top of the JIT the .NET Common Code Base CLass Libraries, thus VB is now

VB.NET. Now C# is the pure impletmentation of M$'s new way of coding that has ONE GOAL --> to produce M$IL! So the key is M$IL. C# produces clean M$IL --

VB was re-written to produce clean M$IL.

Again, C# -->Common Language Compiler = M$IL -->.NET JIT = x86 native machine code (requires Win32)

VB.NET -->Common Language Compiler = M$IL -->.NET JIT = x86 native machine code (requires Win32)

Your choice Language -->Common Language Compiler = M$IL -->.NET JIT = x86 native machine code (requires Win32)

Now I don't know this for sure but if I had to bet, I would guess the following would be seen in a reverse engineering effort:

M$IL --> Common Language Compiler(in reverse mode) = C#, even if you started without c#.

I guess you can argue that instead of saying this:


Develop in any language -->Convert into C# --> Run Only on Windows

That I should of said:

Develop in any language -->Convert into M$IL --> Run Only on Windows


But to me its the same point(even though I know that one is a coding methodology(C#) while the other(M$IL) is the result of running .NET code through the M$

Common Language Compiler, as I stated above and M$'s own comments reinforced C# comes with no code base, it's been moved to the Framework.

Bottom line your stuck on Windows... Don't get me wrong I use and work with and like the Windows Platform(who doesn't). But that said, I also know it's

limitations and know when it's time to scale up.. at a co$t or course, unless we are talking Linux -- But thats another subject.

One last thing Frank, I'm sorry but I have to agree with Chase on the M$-to-Java comparisons for the most part. As a fact I know that Chase's comparison of:

ODBC -> JDBC is correct,think about it, in M$ world do you code to ODBC? NO your interface to ODBC is via the ADO API - you code to it, I think that

this URL on JDO (Java version of ADO) might help

http://java.sun.com/products/jdbc/related.html

However, I think your right on this one:

JNDI -> ADSI

But it really doesn't matter because we all sound like very intelligent people.

LeeC

Lee,

QUOTE
Bottom line your stuck on Windows...
UNQUOTE

I do not disagree at all with this statement! But I was suprised to read that you considered C# more or less the same as MSIL. But your extensive reply made your way of reasoning clear to me and altough not disagreeing with your conclusion on some detail points I think your reasoning is still open for debate... but this would turn out in a very theoretical discussion and being a pragmatic person I don't think it is wise to spend much time on this (as long as we agree on the conclusion it is fine we me...)

QUOTE
One last thing Frank, I'm sorry but I have to agree with Chase on the M$-to-Java comparisons for the most part. As a fact I know that Chase's comparison of:
UNQOUTE

QUOTE
DCOM -> EJB
MTS -> JTA/JTS
UNQOUTE

You can not seriously mean that these things are more or less the same! DCOM is in the MS world the way to make COM components communicate over the network and I think that in the Java world more or less the same goes for RMI. EJB on the other hand gives us in the Java world an enviroment in which Java components can run and can use services for:

- transaction management (without bothering about the harsh details of the transactional API and with offering the possiblity of decoupling the commit/rollback from the component code) (declarative transaction management versus programmatic transaction management)
- object pooling and resource sharing
- thread management
- role based security and declarative security
- ...

In the MS world this is technology is provided by MTS/COM+ and not DCOM (no declartive transactions in DCOM, no role based and declarative security in DCOM, no resource pooling in DCOM, harsh thread management in DCOM.....).

In the Java World JTA/JTS provides the API for transaction management just as DTC does in the MS world.

therefore I still think that

DCOM -> EJB
MTS -> JTA/JTS

must be

MTS/COM+ -> EJB
DTC -> JTA/JTS


QUOTE
JMS -> MSMQ
UNQOUTE

One can argue about this one: JMS is a specification whereas MSMQ is a complete implementation for message queing. U cannot do any message queing with JMS without having a product like MQSeries and this is not true for MSMQ.

so I think in stead of writing

JMS -> MSMQ

it is more correct to write

JMS/MQSeries -> MSMQ

(perhaps from a programmers only prespective JMS can be compared with MSMQ)

QUOTE
ODBC -> JDBC is correct,think about it, in M$ world do you code to ODBC? NO your interface to ODBC is via the ADO API - you code to it, I think that
UNQOUTE

Altough open for debate and dependent on the perpective you are judiging from I personally think that there are more simularities between ADO and JDBC than there are between JDBC and ODBC.... (to name an important one: ADO and JDBC are accessed as components/objects whereas programming in ODBC still means using old fashioned API programming...)

QUOTE
But it really doesn't matter because we all sound like very intelligent people.
UNQUOTE

For the most part I agree but this discussion started with this statement:

QUOTE
He tells me Microsoft's .Net it's a J2EE implementation in C++!!!
UNQUOTE

So, do all of us sound like very intelligent people? I think that we all agree the above statement does not make any sense.

Frank, I have to agree with your reply on the comparisons. I didn't spell out exactly what I meant by that last section of my reply. I touched on JDBC/ADO and also agreeded with Chase on JSP/ASP(didn't mention this) but that is what I meant to say instead of 'for the most part'. As you can see after reading my reply it was sort of an after thought.

Your reply to the last one had me laughing! Your right, that comment about .NET being J2EE but in C++ could not of come from an intelligent people, as in, intelligent with respect to the technologies being discussed. It clearly shows a total lack of understanding for both technology stacks...

LeeC

LeeC wrote:

> So, the question is this: At what point does C# stop
> and .NET start? The quick answer is that it doesn't
> matter! c# is not a complete self sustained language,
> like Java and C++. It's useless without the .NET code
> base and the .NET JIT native-code compiler/Runtime.

Hmmm. Couldn't the same be said for Java? Java is not just a language, it's a platform. It has a core class library, optional class libraries, etc. In .NET, you have the Base Class Library (BCL) which all .NET languages use. This is how .NET allows you to write in any of the .NET languages, complile to MSIL, and run within the CLR (Common Language Runtime) environment. The huge class library in Java is what makes it so appealing (the language is actually a bit goofy, compared to Smalltalk ;-) BTW, didn't IBM have a Universal VM a few years back that allowed this same sort of language-agnostic capability?

What's interesting to me is that after reading a bit about C# and the .NET Framework, the two worlds (Java and MS) seem to be converging towards a similar thoughts on environment. MS is going totally to a "managed code" environment; everything runs though the CLR. What is a bit cloudy in my mind is the ability to load IL from other sources (aka custom ClassLoader objects in Java). I personally feel that one of Java's huge strengths is its ClassLoader and Security architecture; the classloader architecture allows you to do some amazing things (i.e. hot deployable EJBs, Servlets, mobile agents). It remains to be seen how this all works in the .NET world. Everything seems to get packaged as EXEs or DLLs. Anyone have thoughts on this that have looked at .NET seriously?

I personally feel that the .NET Framework and C# further legitimatize the Java platform. Obviously MS feels the object engine/VM architecture is a good road to go down because it's betting the farm on .NET. Too bad the CLR isn't being pushed to other OS architectures like the JVM. I'm all in favor of giving Sun and Java some heated competition on non-Windows platforms.

Nuff said.


-- chris bartling --

   In response to Chase and his similarity list. Most of the comparisons aren't fair. Only JSP was a direct answer for ASP. COM-Beans is not a comparison at all. Active-X and Beans is the correct comparison. DCOM in no way comapres to EJB. Let's try DCOM-RMI, RMI has bin around a little longer than EJB. DCOM is only a remote Object, just like RMI and CORBA for that matter. EJB is a serverside component framework on top of CORBA and RMI. The closest comparison to EJB is MTS. They both give you a framework to run components inside a controled environment. Comparing MTS to an interface like JTS/JTA is just silly. JTS is java interface to CORBA OTS implemented differently by many vendors. That comparison is ridiculous. MSMQ to JMS. Again JMS is an interface. IBM's JMS interface is implemented by MQ-Series which by far more mature and robust than MSMQ will ever be. JNDI and JDBC are again API's. JDBC can sit on top of ODBC or it can stand directly over the DB native drivers. JNDI can sits on top of many different naming directories. What about Servlets? no comparison there, huh?
    If DNA was so robust, why is Microsoft coming out with .Net. Net is not a repackaging of these DNA components, its a whole new ballgame. C#, VB.NET, ASP.NET. Why are they creating a language like C# that looks like Java and compiles into a byte code language if they thought there products are so much better than Java. In DNA, the best language to develop COM objects were in Java. Why is VB 7 all of a sudden OO when they preached that you don't need Objects to build components.
    Most all products today look at there competition and try to mimic some piece that the public likes. COM was not the first. RPC/ONC, RPC/DCE, CORBA, Tuxedo are all very mature products COM copied off of.

Thats an interesting analogy :)

Are people missing MS's point?

.NET is a move to taking control of the Web Services space and leaving J2EE in the dust.

.NET as of beta2 will support the specifications of its services in WSDL, with access to those services via SOAP - hence opening up communications to a market space its has had no access too in the past. IBM MQ now supports SOAP, for example.

The .NET services will be able to be registered in UDDI regsistries making it an ideal platform for B2B and P2P service development.

The real battle ground is .NET vs Sun ONE - not J2EE.

Sun ONE is just hype at the moment and will probably be so until JavaOne. So it is Sun who is playing catchup.

Comments?

Where did u get this knowlegde?

QUOTE
Develop in Java -->Compile into ByteCode -->Run Anywhere (provided the JVM exists)

.Net is the complete OPPOSITE from Java:

Develop in any language -->Convert into C# --> Run Only on Windows
UNQOUTE

In my understanding .Net is

Develop in any language -->Compile into ByteCode--> Run Only in a VM which (currently and perhaps always) only runs on Windows.

I'd like to know where u did learn that any language will be converted to c#.

 

I have tried to compile some of my thoughts from my experience in implementing .Net and Java solutions. Please read the same here.

Krishna