ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Herr Christian Wolfgang Hujer <Christian.Hu...@itcqis.com>
Subject Re: Recommendations for moving from java to .NET
Date Wed, 05 Feb 2003 20:49:39 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,


Am Mittwoch, 5. Februar 2003 20:54 schrieb Steve Loughran:
> >
> > You can plug-and-play different XML parsers and XSL transformers in .NET?
>
> They ship with XML parsers that work *out the box*. And good pull model
> ones too, if that is what you want.
Yeah, I know that XML parser, it's even not possible to validate XHTML 1.1 or 
XHTML Basic with it because it still (as far as I know - is it already 
fixed?) has a well known bug regarding resolving URLs of entities, they are 
resolved form the referencing document instead of the declaring document. And 
we all know MS's "good support" of XSLT, haha. First they put on their 
gloriole by implementing a draft in IE, but the devil showed his face when 
the recommendation was published. Where was MS when XSLT became a standard?

Yeah, we all know what "good support" and "out of the box" mean in MS context, 
especially regarding XML. That was one of the reasons for me to migrate even 
the last of my work systems from Windows to some UNIX and Java. For me, 
Windows is only good for computer games, and even there Linux is slowly 
catching up.

Am Mittwoch, 5. Februar 2003 18:39 schrieb Nau, Michael:
> We are looking into shifting our component-based development environment
> from java & j2ee to c# & .NET.
Am Mittwoch, 5. Februar 2003 19:14 schrieb Armenio Pinto:
> Outch! It burns!
Ack.

Okay, seriously, I can't see a single argument for moving a serious business 
application from J2EE to .NET.

Here's why:
1. It's easily possible to redeploy J2EE components during runtime, even in 
most of the simpliest (pseudo) appservers like the J2EE reference 
implementation. It's not so easy to do so with .NET.

2. J2EE application servers can easily be clustered. Especially, no 
recompilation of the components is neccessary. In .NET, the number of CPUs / 
Servers is a compilation flag.

3. In good J2EE servers, even session data is stored on persistent storage, 
just in case one of the servers handling sessions fails, then another server 
can take the load without the loss of the session data.

4. J2EE in general clusters very well. As soon as your machine gets too slow, 
you get a second one or a faster one, *without* limit. In .NET the limit is 
set by the very low level of maximum hardware available for Windows. Of 
course there are also Windows NT clusters. But try comparing a Windows NT 
cluster with an IBM or SUN mainframe... And again, .NET needs 
recompilation...

5. J2EE has a very good component design. Using Remote instead of Local 
interfaces enables easy clustering. Correct usage session and entity beans is 
an easy maintainable design that comes quite close to what's required. In 
.NET, Microsoft recommend that you neither use Remote nor seperate the 
presentation from the process from the data layer because it impacts 
performance. As soon as you try to achieve the same design goals you'd do 
with J2EE, performance of .NET is worse than that of J2EE, especially when 
using Remote for clustering. Microsoft recommends especially not to use that.

6. 365/7/24. Consider all arguments above: It's impossible to realize 95% or 
more availability with .NET. But it's quite usual to achieve this with J2EE.

7. Performance. It's always told .NET would be faster than J2EE. Okay, try 
.NET in a distributed environment with objects representing business data, 
objects representing business projects and objects responsible for the 
visualization. Seperate these layers and make a .NET cluster with that. 
*Then* compare the performance, and see the results. But don't compare a flat 
.NET design with an even internally multi-tier J2EE app server. If it's just 
some ASP's, it's unfair to compare that with J2EE EJB design, a comparision 
with JSP is appropriate. The so called "performance statistics", like that of 
IDC, are usually comparing apples and oranges.

Of course, if all this doesn't count, then .NET might be a choice.

Am Mittwoch, 5. Februar 2003 19:04 schrieb MNewcomb@tacintel.com:
> HAHAHAHA
Am Mittwoch, 5. Februar 2003 19:16 schrieb David McTavish:
> Maybe such immature comments are better left untyped, or at best, posted to
> a different newsgroup.
By the way, I don't agree with Michael's laughter. I find it quite 
thought-provoking that someone drops J2EE in favour of .NET. And I find it 
quite provoking that such a person even requests help and tipps from the Ant 
User mailing list. Considering Microsoft's intolerance (especially about 
Java) that really strains my personal tolerance. I don't think Michael's 
laughter is immature. So I admire he's able to laugh so loud about that.

Am Mittwoch, 5. Februar 2003 19:16 schrieb David McTavish:
> You should, at the least, acknowledge the fact that
> they are still contemplating the use of ant, which, in my mind, is a HUGE
> compliment to the tool.
Do you all really think Ant will become the favourite build tool for .NET? As 
soon as Ant will be somewhat successful for .NET, Microsoft will clone it and 
release a rival, and what do you think the .Netters will use? But don't dream 
of MS support for Ant. They're gonna forget Ant quite soon and be very happy 
to live with a tool that doesn't require a modern JVM.


My 2 cents

Bye
- --
ITCQIS GmbH
Christian Wolfgang Hujer
Geschäftsführender Gesellschafter
Telefon: +49  (0)89  27 37 04 37
Telefax: +49  (0)89  27 37 04 39
E-Mail: Christian.Hujer@itcqis.com
WWW: http://www.itcqis.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+QXjjzu6h7O/MKZkRAklWAJsF5Jz/GWTzvvbejKOqqMXT6yzGAwCgzaZy
zuJnRvHJj1n9G/ExNedoLWg=
=by7J
-----END PGP SIGNATURE-----


Mime
View raw message