|
 |
[an error occurred while processing this directive] | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is one of the documents recently unsealed in the legal case between Sun Microsystems Inc. and Microsoft Corp. over whether Microsoft behaved in an anti-competitive fashion in its handling of Java.
From: Anders Hejlsberg
Related to some of the Java runtime mails that have been going around, I thought I'd throw in the current thinking on Java language extensions. Peter Kukol and I have been working on a set of Java language extensions that I would characterize as "A careful marriage of Java and C." The thinking here is that while we could (and likely should) extend C++ with a Java-like object model, what a lot of programmers want is a "cleaned up: version of C++ which gives them the productivity benefits of Java coupled with the lower level features of C. With these language extensions we're aiming to address several issues:
* Relax Java's all-or-nothing approach to garbage collection by teaching the language about non-GC'd entities.
The extensions would essentially divide Java's structured types into two categories: GC'd and non-GC'd. Pointers would only be allowed to point to non-GC'd structures, and there would be no provisions for taking the address of a GC'd object. GC'd types are Java classes and dynamic arrays as they exist today. Instances of these types would continue to live in a garbage collected heap, and would be allowed to contain direct references to both GC'd objects (as is the case today) and non-GC'd structures (through pointers). Non GC'd types are static arrays, structs, and unions.. Instances of these types would be allocatable on the stack or through a traditional memory allocator. Instances would be allowed to contain pointers to other non-GC'd structures, but would not be allowed to contain direct references to GC'd objects. For a non-GC'd structure to contain a reference to GC'd object, the programmer would have to allocate an object handle (which is simply typed as an int) ant store the handle in the structure. The handle would create a "fake root" in GC space that keeps the GC'd object alive until the handle is later freed. When access to an object is needed through a handle, a system function would be available that returns the object associated with the handle. The upshot of this is that from a non-GC point of view references to GC'd objects would have to allocated and freed. But this doesn't really differ from normal non-GC programming. Given these semantics, the GC wouldn't need any special knowledge about pointers. Since a pointer could only point to a structure that contains no direct (i.e., managed) references to GC'd objects, there would be no need for the GC to chase into point-to structures nor would there be any need for the GC to have metadata describing the layout of a struct or union. Indeed, from a GC perspective, pointers could be treated just as ints. Any extensions that we deem "unsafe" such as pointers, would only be accessible in methods that are compiled with a "trusted" directive, and would be subject to the same security restrictions as native code. In other words, unless the user permits it an apple wouldn't be allowed to use pointers. But it would be allowed to call other methods that use pointers internally (e.g., system API wrappers) provided these methods have in turn been trusted. We would implement the extensions by extending the byte-code instruction set, not by generating native code. This allows the code to be transported to different CPU architectures but once the JIT passes over the byte-codes they would be just as efficient (or very close to) as native code. Indeed, one way to think of the extensions is as "a better way to write native code." Since the extensions would bring Java on par with C with respect to language features, there would be much less need to write native code, which would simplify development and debugging. From a syntax point of view there would really be no big surprises. We're debating minor issues such as whether enums should be strongly typed (a la Pascal) or simply just another way to write int constants ?a?? CC++ and whether structs and unions can be top-level types or only be declared within classes, but in general it would look and feel a whole lot like C allowing users to immediately leverage their skill set. The extensions would allow any Windows API (indeed, any DLL) to be directly callable from Java with no more overhead than from C/C++. This gives us a great vehicle for implementing a modern Windows framework in Java without sacrificing performance and features and it gives users the ability to call their own DLLs as well as an "escape hatch" to access esoteric Windows API functions not encapsulated by the framework. Finally, the extensions would allow users to choose an implementation strategy where parts of an allocation's data structures are GC's and others aren't. This would obviously open the door for pointer tracing bugs and such. But in cases where performance really matters, Java would at least no longer be an all-or-nothing proposition. The contentious issue with these extensions is obviously that they pollute the language and we have to be careful as to how we frame them. The current thinking is that J++ sources files must have a "jpp" extension (not "java"), that there will be a separate J++ command line computer and that a J++ switch must manually be turned or for a project in the IDE. Furthermore, classes and methods that use unsafe extensions must be compiled with a trusted directive that we could highlight in red or some such in the editor. Let me finally point out that the VM team has already made some great progress with respect to COM interop and most recently with respect to directly calling native DLLs. These extensions greatly alleviate Java's inability to call native APIs but still have restrictions and performance penalties associated with them that in my view can only be overcome through language extensions. Anders Return to 'Follow the e-mail trail in the Sun-Microsoft case'
|
|
[an error occurred while processing this directive]
|
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
