Comparing enterprise systems can seem daunting at first, and the software world seems to be teetering back and forth between the twin giants, Sun and Microsoft. Security being the latest hot topic theses days, eventually every manager will need to take a look at what these platforms have to offer in this department.
In many ways, these systems aren't comparable. First, .NET is early in life, and J2EE is a widely used enterprise solution. Second, Java started out with security as part of its conception, with pioneers such as Li Gong behind the architecture of a platform that would descend from a non-secure Internet to the consumer's desktop. Microsoft, although not altogether unconcerned with security, has only recently touted "Trustworthy Computing" as a focus for their product line, which is likely one of the major reasons .NET is just a newborn.
Due to the nature of security, there may never be a winner of a .NET-J2EE battle. There are already several playing fields the war is being waged upon. There is Microsoft's SDK versus Sun's API, there are .ASP pages versus .JSP ones, and then there is XML and other middle and back-end integration to consider. But for now, I will examine the differences in one aspect of these platforms' security solution, their primary core languages.
Despite touting an open framework and cross-platform compatibility, the breath behind each of these platforms is a primary programming language, C# on one hand and Java on the other. Both of these languages were created with security in mind, and both have similar ways of enforcing their security, including automatic garbage collection and namespaces.
There are some significant differences, though. Java bytecode is run through a virtual machine or just-in-time compiler, while C# is tied into the IL (intermediate language) common language runtime (CLR). This IL versus the Java VM will be one place where the giants battle it out, and already sides are forming, mostly based on what other platforms and protocols each will support.
C# always runs natively on a machine. It is either compiled to native code initially or into the IL to be interpreted into native code at execution. Java normally runs as interpreted from bytecode or through a JIT compiler. Both modes, of course, have their liabilities and strengths. The most significant here is that Java still relies on a sandbox security model to keep Java code from going rogue. Microsoft, however, has moved away from the sandbox to a code-signing paradigm, where security is enforced through an "evidence-based" system that determines whether the code is safe based on where it comes from and not on runtime security checks.
Another important factor to consider from a security standpoint is that Java has been running the Internet gauntlet for nearly a decade and has the benefit of years of testing and bug fixing behind it. C# is still a fledging language.
A final key difference is that Sun has always been a proponent of open source, and the Java VM specifications are online or can be read at leisure in a published book form. Although there has been pressure on Microsoft to open up the core components of the IL runtime environment, their architecture has only been reviewed by the third-party Foundstone. This is, of course, a core premise for these two companies, the "security through obscurity" versus "open source security" model.
Have a security-related question you want answered in a future Tacit Records column? E-mail the author at email@example.com.
- Foundstone's whitepaper on security and the .NET framework
- Microsoft's .NET security page
- The J2EE Blueprints
- The Java Virtual Machine Specification
- The .NET Security Overview
- EarthWeb's own David Fox's went to JavaOne and has some interesting things to say about .NET
[Editor's Note: Recently, Microsoft released the CLI as "shared-source" code. Thomas Nowers updates: "The shared source CLI (Common Language Infrastructure) is actually a really huge step for Microsoft. It is basically an open beta
implementation of .NET on XP or FreeBSD for non-commercial purposes.
Although it is not a complete release of the .NET architecture, it is an
excellent resource for looking into the inner workings of .NET and
evidence that Microsoft is starting to open up more to the development community."]