1. java is free so learning it as a student was cheaper (well, legally anyway!)
.Net is free as well. You can go download the SDK, same as with Java, and off you go. True, VS.Net costs, but VS.Net is NOT .Net.
The one point that is absolutely true though is that .Net only runs on Windows, hence you could rightly say that there in fact IS a cost to .Net. I can't argue it from that perspective.
Maybe it's splitting hairs, but .Net *is* free, it's what you need to buy to run it on that's not, which BOTH are free with Java, at least some alternatives are.
2. the amount of free stuff out there for java. There is soooooo much available! Show this to most .NET developers and they're amazed. Though to be truthful, show most .NET developers how much stuff is available for free for .NET and they're amazed!
This is true, and once of my primary reasons for liking Java more than .Net. But to be fair, Java has had a heck of a head start timewise... Let's see how resources for .Net compare to where Java is now in 2-3 more years (obviously Java resources will continue to grow, but to make the comparison fair you need to compare them at approximately the same point in the lifecycles).
3. Windows. if you go with .net, you have to use windows as a server. Firstly there's the whole security/stability issue. I'd agree that in my experience win2k server has been fairly stable. As for secure, that's a joke. How many worms have there been infecting windows servers? How many have infected *nix servers? It also seems madness to me to shell out so much for an operating system when there are better things for free. For example, I installed a linux server with a struts app on it about 6 months ago (uptime 161 days). Hasnt been restarted since. This was in a very large organisation that was 100% windows, and was dubious about my use of linux. Their IT manager i work with says she cant belive how stable it is, compared to all their windows servers.
Yep, tie-in to Windows is I think clearly the one big disadvantage to .Net. If it wasn't for this, I think this debate wouldn't be nearly as simple.
I do argue with the security aspect of Windows though... If we limit the discussion to servers, then it should be true that you have a capable admin handling it. A properly-configured Windows server, on a properly-configured network, both of which are properly-administered is SIGNIFICANTLY more secure than many people like to believe. I would probably give a slight nod still to Unix* in this area, but the gap is seriously not that much any more. 99.999% of the worms you allude to would NOT be an issue in a well-configured environment (and I'm not even talking about all the patches getting installed right away). You can have a horribly insecure Unix box if it's configured poorly too.
As for web services, i too love these. I especially love how easy it is to
make a service using axis and .jws files. But i do have concerns about web
services. Dont get me wrong, web services are great if you want to connect
two systems which cant be connected in a simpler fashion. But i am concerned
with the amount of overhead web services generate (refering to SOAP here as
it is the prevelant standard). In a traditional message passing distributed
system, the overhead (that soap introduces) could be controlled, by
minimising the size of the messages. Instead of sending a couple of
kilobytes of http headers and xml to ask for a record by id, you could just
send the integer id number. Same applies to the response. Might not sound
much but when you start processing thousands/millions of requests per
second, the network bandwidth, processing power and memory usage required to
handle these ineficient messages adds up. I would be interested to see a
comparison of say mysql's native tcp communications, and say a SOAP+XML
equivilent.
Well, now we're getting off into ANOTHER big thread :)
I agree with your concerns. In fact, when XML was just coming to light a few years back, I was very much against it. What's the point of taking 2K worth of data and sending it over the wire wrapped in 20K of "extraneous" information? Hard to make an argument for it in many cases. It's STILL a tough argument in many cases, and I think people are FINALLY starting to realize what I was yelling at the top of my lungs to everyone in the office a couple of years ago: XML is *not* the answer to every question.
Sometimes is makes a lot of sense, but your point about high volumes is a good one, I don't think that's the place for XML, meaning Web Services in most cases. A while ago I did a project where we had a mainframe-based application written in COBOL that we needed to create a web front-end for. XML was new at the time, so I wanted to play :) I wrote an application that would make an XML-based request to a web server running on the mainframe, which could talk to CICS and the Cobol apps, get the mapped memory area the output was in, convert it to XML and send it back to the client, which then used some fancy Javascript to parse it and display it via XSL. Most would recognize it as not a good solution now, but back then it was cool and seemed like a halfway decent idea because everyone wanted XML in any solution, just as a selling-point.
Well, we pretty quickly realized it wasn't going to work performance-wise. I would call that a Web Service-based application, even though SOAP and other typical WS standards weren't in play (just XML transmitted via a form submission going in). A more optimal solution written with today's toys would be better for sure, but still not something I'd use as the foundation for something with a lot of traffic.
The inefficiency of SOAP is also a big problem for mobile devices. Low memory (ram, and flash) prohibits the use of say axis+exerces. There are various solutions being tossed about.
Very true. You know, the funny thing is, XML and Web Services are popular for precisely one reason: everyone decided we needed a standard method of data interchange, and someone thought this was a good idea and everyone else jumped aboard because there weren't too many alternatives.
I used to say that if we all agreed that CSV files was a good idea, we'd have standardized on them and gotten around many of the problems of XML :) Of course there are plenty of problems that XML solves that CSV doesn't, but that's the whole point! XML and WS, for all the warts you and others point out, is so far the best solution to come around and be codified in specs and standards. It seems to me an encoded binary stream would be a better solution in just about every aspect (except for human readability, but I've always felt that was an overblown benefit of XML anyway), but that's not the way the world went.
Frank
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
