Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

What about the future of j2ee  RSS feed

 
Sam Wang
Ranch Hand
Posts: 95
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If .net also can run on unix,then is the biggest
advantage of j2ee lost?
If c# also is as safe as java,then is the biggest
advantage of java lost?
What about the choice between .net and j2ee in US,Europe or Japan now,the end of year,next year...?
 
Tim Holloway
Bartender
Posts: 18702
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The BIGGEST advantage of Java over .Net is that it is not in Sun's interest to slip in OS-dependent components after everyone's committed their software assets to the platform, thus locking them in (or out) of their chosen OS.
I saw this effect with a vengeance yesterday when I thought I'd put a Real Audio client on a Linux system and discovered that they hadn't bothered to update the thing for about 3 releases (and you can FORGET about Windows Media under Linux!).
Microsoft has already attempted to hijack the Internet twice - once with J++ and once with ActiveX. Both offer programmer convenience, but ultimately both lead to a Windows-only world.
So far as availability goes, you can now buy Visual Studio .Net as easily as Java. However, early results have been that .Net is not yet as "safe" as Java. Java's had the better part of a decade to get it right, and security was designed in from the bottom there. .Net is based on a platform infamous for putting features ahead of security and liable.
Finally, there's more than one kind of "safety". Microsoft has repeatedly shown that they are not as sensitive to the incredible longevity of crusty old apps as Sun and IBM are. With Microsoft tools, there is no Java-like deprecation mechanism - you simply wake up one day and things no longer compile. Perhaps the most extreme example of this is what they tried to do in going from Visual Basic to VB.Net, but the same thing goes on in miniature all the time.
 
Sam Wang
Ranch Hand
Posts: 95
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
First thank u for your reply.
I see someone said next year or later there would be a version of .net that run on unix.Is that possible?
And ms has put c# and .net(or part of it) to ECMA(is that right?)If it is true,then thing that vb becomes vb.net can't happen.(is this right?)
 
Thomas Paul
mister krabs
Ranch Hand
Posts: 13974
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Michael Wang:
And ms has put c# and .net(or part of it) to ECMA(is that right?)If it is true,then thing that vb becomes vb.net can't happen.(is this right?)
Microsoft has given C# and parts of .Net to ECMA. The second part about VB.Net I didn't quite understand.
 
Sam Wang
Ranch Hand
Posts: 95
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In my opinion,because vb is not given to some orgs like ECMA,ms can freely make a new version vb(vb.net).If something has been given to some orgs like ECMA,any changes must been made by this org not by ms like the relation between java and jcp.
 
Tim Holloway
Bartender
Posts: 18702
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One of the supposed advantages of .NET is that many compilers will all be able to compile for their equivalent of the JVM, so you can program in "BASIC", "C++", "Java" and so forth (Note the sarcastic use of quotes - the .NET versions of each of these languages has Microsoft-peculiar properties.
However, they got off to a poor start. Rather than a universal VM, they attempted to redefine VB in terms of the VM - redefining the array subscripts to start at 0 instead of 1, redefining what meant "true" and what meant "false", redefining the logical operators, and so forth. In other words, redefining critical elements of the language to act like C#, instead of remaining compatible with VB. Needless to say, VB developers howled - the amount of labor required to port VB code to VB.NET was significant.
This is a wonderful example of what happens when a single vendor controls the definition of a programming language - you get shoved into THEIR agenda instead of them accomodating YOU. What makes .NET especially perilous, is that the vendor controls not only the language, but owns an OS it wants to lock you into, and modifying the language and/or runtimes (as they did in J++) to further that process is - as they have demonstrated - fair game.
Now the great irony of all this is that Sun ALSO owns a language (Java) and an OS (Solaris). However no one I know of is worried about Sun tying Java to Solaris for their own nefarious purposes - Sun has been scrupulous about its "write-once/run-anywhere" philosophy in Java, and besides, Solaris just doesn't have the clout that Windows does.
There is, in fact, more than one project to make .NET runtimes run under Unix-architecture OS's. However, in this day and age, it takes more than just a compiler (and, if needed, a language VM) to make a language. To REALLY run, you need the support packages as well. In the case of .NET, some of these packages blur into the OS (Windows), making it questionable as to how deeply any non-Windows .NET implementation can really be implemented.
This is true on both the client and server sides. ActiveX controls were never intended to be portable the way .NET claims, but as an example, if you weren't running IE, you had to install a rather rude plug-in (for Netscape), or not even be able to use the web page (third-tier browsers). Even under IE, if you were running on a Macintosh, chances were VERY high that the control wouldn't work, since almost nobody bothered to cross-compile a Mac version.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!