ZDnet disappoints me every time I read one of their articles Thursday, May 08 2008
Got me a link from Paul today:
Keep Your Beans Out of .NET
In Paul's words:
"This guy's an idiot" (Godfrey Baker, Builder.com)
Let's take this guy's article and examine it!
Prelude
If you have an EJB implementation of your application, is it worth it to migrate it to .NET?
Um, no. I think that is pretty obvious. First off, with such disparate technologies like .NET and Java, you don't just "migrate" things from one to the other. You completely rewrite or integrate the two technologies. There is definitely no possibility of migration. I think that's pretty obvious... Who migrated their Perl applications to ASP/VBScript when ASP1.0 came out?
Reason 1
CLR does not support Java
Really? Oh my god! Anyway, this one's a no-brainer and pretty much goes back to my previous point on migration. Microsoft didn't build their own custom JVM here Godfrey, they built a completely separate (technologically speaking) framework to run .NET code, not Java. Hence, it doesn't run Java natively.
Reason 2
IIS Does not support JSP
Again, back to the "you don't migrate, you rewrite" idea. I would really be disappointed in myself if I were the technology manager (who barely knows how to use his or her computer) and was really taken aback at the shock of what this guy is pointing out to me.
Reason 3
Server controls require redesigns
Again, YOU DON'T MIGRATE EJB CODE TO .NET CODE, IT'S JUST NOT FEASIBLE.
Reason 4
No support for Container Managed Persistence
Everything goes back to my first point. If I have a truck, and tomorrow I decide that I want to replace it with a car, I should probably realize that in three days I need to move a piano and that requires a truck. Different technologies (car is to truck as java is to .net) require different code, structure, etc.
Reason 5
Different session handling implementation
Okay, Godfrey is trying to say that since the EJB standard doesn't explicitly say how session is supposed to work, the different application server vendors vary drastically. So in .NET there is a "standard" way of handling session that can be distributed to support multiple web servers. Granted, there is one part he got wrong (this doesn't require SQL Server so people who use Oracle really can use centralized session storage), however this point makes perfect sense, yet it doesn't really seem to tell me why I shouldn't "migrate my application from Java to .NET".
So all in all, this article was a complete waste of time. Anyone who really needs to read it to figure out if they should just up and change their fundamental technologies within their applications has a serious problem and should probably not be making these types of decisions.
Keep Your Beans Out of .NET
In Paul's words:
"This guy's an idiot" (Godfrey Baker, Builder.com)
Let's take this guy's article and examine it!
Prelude
If you have an EJB implementation of your application, is it worth it to migrate it to .NET?
Um, no. I think that is pretty obvious. First off, with such disparate technologies like .NET and Java, you don't just "migrate" things from one to the other. You completely rewrite or integrate the two technologies. There is definitely no possibility of migration. I think that's pretty obvious... Who migrated their Perl applications to ASP/VBScript when ASP1.0 came out?
Reason 1
CLR does not support Java
Really? Oh my god! Anyway, this one's a no-brainer and pretty much goes back to my previous point on migration. Microsoft didn't build their own custom JVM here Godfrey, they built a completely separate (technologically speaking) framework to run .NET code, not Java. Hence, it doesn't run Java natively.
Reason 2
IIS Does not support JSP
Again, back to the "you don't migrate, you rewrite" idea. I would really be disappointed in myself if I were the technology manager (who barely knows how to use his or her computer) and was really taken aback at the shock of what this guy is pointing out to me.
Reason 3
Server controls require redesigns
Again, YOU DON'T MIGRATE EJB CODE TO .NET CODE, IT'S JUST NOT FEASIBLE.
Reason 4
No support for Container Managed Persistence
Everything goes back to my first point. If I have a truck, and tomorrow I decide that I want to replace it with a car, I should probably realize that in three days I need to move a piano and that requires a truck. Different technologies (car is to truck as java is to .net) require different code, structure, etc.
Reason 5
Different session handling implementation
Okay, Godfrey is trying to say that since the EJB standard doesn't explicitly say how session is supposed to work, the different application server vendors vary drastically. So in .NET there is a "standard" way of handling session that can be distributed to support multiple web servers. Granted, there is one part he got wrong (this doesn't require SQL Server so people who use Oracle really can use centralized session storage), however this point makes perfect sense, yet it doesn't really seem to tell me why I shouldn't "migrate my application from Java to .NET".
So all in all, this article was a complete waste of time. Anyone who really needs to read it to figure out if they should just up and change their fundamental technologies within their applications has a serious problem and should probably not be making these types of decisions.
