XRender
Old Java2D had to do a lot of rendering in software. This was fixed, but with OpenGL and poor Linux drivers, it can still be a problem. Thus, an X11 renderer should be created. Java2D is used by Cairo, GTK+, QT4 and KDE4.
Deployment features
Enable better access to installed JREs for applets, webstart and javafx applications. Also seamless JRE installation, and single line javascript deployment.
Swing updates
Translucent and shaped windows, heavyweight/lightweight mixing, and the improved AWT security warning.
JXLayer (glass pane overlay, control everything) component decorator, JXDatePicker, and possibly CSS-based styling.
DROPPED: Swing Application Framework to make it easier to write applications. May provide co-existence with JavaFX.
Nimbus look and feel. JGI.
Web changes
Upgrade the JAXP, JAXB, and JAX-WS APIs to the most recent stable versions.
torsdag 17. desember 2009
onsdag 16. desember 2009
Java 7 chapter 3: core
Modularization
JSR 277: JAM module system eller OSGi. Applying JSR 294 to the rt.jar, creating virtual machine “profiles”. The core has been reduced from 15 MB to 5 MB. There might be profiles for headless, rich apps, realtime ..
ClassLoader architecture
Modifications to avoid deadlocks in non-hierarchical (cyclic) topologies.
Close URLClassLoader
Often in use by application servers. When a new URLClassLoader is constructed, the old one can be garbage collected when there are no references to this object. Only then can files and directories under this CL be unlocked. Because of the nature of GC, it is unpredictable when this will happend. A close method will make this behavious more predictable.
Unicode 5.1
Standard for representing various characters, now supporting even more characters.
Concurrency/collection updates
166 is a package of different concurrency stuff. 166y is defining a fork/join-framework (Parallel Array). Operation on a collection of elements, like incrementing a number across an array.
New I/O APIs
A file system interface that supports bulk access to file attributes, change notification, tunnel to FS-specific APIs, service-provider interface for pluggable FS implementations.
Asynch I/O operation on both sockets and files. Socket level UDP stuff.
EEC
Approac to public-key cryptography. Now supported with a native java library.
JSR 277: JAM module system eller OSGi. Applying JSR 294 to the rt.jar, creating virtual machine “profiles”. The core has been reduced from 15 MB to 5 MB. There might be profiles for headless, rich apps, realtime ..
ClassLoader architecture
Modifications to avoid deadlocks in non-hierarchical (cyclic) topologies.
Close URLClassLoader
Often in use by application servers. When a new URLClassLoader is constructed, the old one can be garbage collected when there are no references to this object. Only then can files and directories under this CL be unlocked. Because of the nature of GC, it is unpredictable when this will happend. A close method will make this behavious more predictable.
Unicode 5.1
Standard for representing various characters, now supporting even more characters.
Concurrency/collection updates
166 is a package of different concurrency stuff. 166y is defining a fork/join-framework (Parallel Array). Operation on a collection of elements, like incrementing a number across an array.
New I/O APIs
A file system interface that supports bulk access to file attributes, change notification, tunnel to FS-specific APIs, service-provider interface for pluggable FS implementations.
Asynch I/O operation on both sockets and files. Socket level UDP stuff.
EEC
Approac to public-key cryptography. Now supported with a native java library.
tirsdag 15. desember 2009
Java 7 chapter 2: Language changes
Annotations
Annotations is limited to declarations in java 6 (method parameters and the declarations of packages, classes, methods, fields, and local variables). This jsr extends the annotation system to use on any type. It is limited to defining the syntax of the extended annotations, leaving the semantics out.
Modularization
Will promote testability and maintainability. Much like OO and interfaces, but at larger scale. A JAR is like a module but does not define dependencies. All classes are put on classpath, which enables interface type checking at compile time. However, the classpath can be different in runtime, i.e. different or multiple library versions. ClassLoaders can be used to segment the classpath, but they are hard to use. OSGi is a module system. It uses metadata in the manifest-file to determine inter-jar dependencies, and provides one ClassLoader per library. OSGi is a specification with several implementations. Project Jigsaw is the effort of modularizing the jdk itself. It will introduce a “module” keyword which combined with maven/ant-style dependencies can be used to create runtime module dependencies.
Coin
Project Coin defines a set of small language changes should be added to JDK 7. Seven features have been selected:
- Strings in switch
- Language support for collections
- Automatic Resource Management
- Improved Type Inference for Generic Instance Creation
- Better integer literals
- Simplified Varargs Method Invocation
- Language support for JSR 292
See i.e. http://blogs.sun.com/darcy/entry/project_coin_final_five
fredag 4. desember 2009
Java 7 chapter 1: The Virtual Machine
To prepare for the arrival of the Dolphin, I will indulge in some research entitled "What's new in Java 7". The story will consist of 5 chapters: the vm, the language, the core, the client and the Web. First came the change to the virtual machine.
CompressedOops
OOP is an “ordinary object pointer”, and it’s length is usually similar to the length of the native operating system pointer. Increasing the length from 32 to 64 bits will cause the heap in a 32-based program (running on a 64-bit system) to expand by 50%. Memory is cheap, but bandwidth and cache is expensive, and it is should not be very costly to port applications a new platform. Using a 64 bit vm and the UseCompressedOops flag will keep addressing overhead similar to that of 32 bit systems at the cost of cpu cycles.
Garbage First GC (“G1”)
Replacement for Concurrent-Mark-Sweep GC, but still “generational”. CMS divides memory into young generation (eden, survivor) and and old generation. Move live object into a more “persistent” generation. Stops the world to do complete collections. G1 divides memory into small “regions”, and these are labeled “young” or “old”. During a GC, those objects who are “live” in a region, will be compacted with other “live” objects in another region, depending on their age. Each region has a “remembered set”, which contains all external references to this region. This reduces the need to pause the world to mark.
G1 is a server-style garbage collector, targeted for multiprocessor- and large memory systems. It aims at being more predictable than CMS. It’s also available in 6u14.
JSR 292: The Da Vinci Machine Project
The JVM should be extended with general support of languages other than Java, and in particular dynamically typed languages. Such language implementers have observed a range of painful aspects of the byte code language, and this projects aims to remove those in a general manner. The noteworthy suggestions is: dynamic invocation, continuations, tail-calls and interface injection. The JSR specifically targets dynamic invocation and hot class modification. Today dynamic languages produces a lot of different options for signatures that all have to be stored in permgen space. This is very inefficient, and one should be able to narrow down these options at runtime.
CompressedOops
OOP is an “ordinary object pointer”, and it’s length is usually similar to the length of the native operating system pointer. Increasing the length from 32 to 64 bits will cause the heap in a 32-based program (running on a 64-bit system) to expand by 50%. Memory is cheap, but bandwidth and cache is expensive, and it is should not be very costly to port applications a new platform. Using a 64 bit vm and the UseCompressedOops flag will keep addressing overhead similar to that of 32 bit systems at the cost of cpu cycles.
Garbage First GC (“G1”)
Replacement for Concurrent-Mark-Sweep GC, but still “generational”. CMS divides memory into young generation (eden, survivor) and and old generation. Move live object into a more “persistent” generation. Stops the world to do complete collections. G1 divides memory into small “regions”, and these are labeled “young” or “old”. During a GC, those objects who are “live” in a region, will be compacted with other “live” objects in another region, depending on their age. Each region has a “remembered set”, which contains all external references to this region. This reduces the need to pause the world to mark.
G1 is a server-style garbage collector, targeted for multiprocessor- and large memory systems. It aims at being more predictable than CMS. It’s also available in 6u14.
JSR 292: The Da Vinci Machine Project
The JVM should be extended with general support of languages other than Java, and in particular dynamically typed languages. Such language implementers have observed a range of painful aspects of the byte code language, and this projects aims to remove those in a general manner. The noteworthy suggestions is: dynamic invocation, continuations, tail-calls and interface injection. The JSR specifically targets dynamic invocation and hot class modification. Today dynamic languages produces a lot of different options for signatures that all have to be stored in permgen space. This is very inefficient, and one should be able to narrow down these options at runtime.
Abonner på:
Innlegg (Atom)