java 7: quo vadis?
TRANSCRIPT
DSRG template
Michal Malohlava
Java 7 : Quo vadis?
DISTRIBUTED SYSTEMS RESEARCH GROUPhttp://dsrg.mff.cuni.cz/
CHARLES UNIVERSITY IN PRAGUEFaculty of Mathematics and Physics
Java development process
Language extension
Related projects
Java Module System
Conclusion
Outline
JDK
Official Sun's Java
Source code released (GPL v.2)
18months release interval
JDK6 fall 2006 => JDK7 spring 2008 (January 2009:)
Still no official JSR (Java Specification Request)
only many proposals of Java7 features/anti-features
OpenJDK
Free implementation of JDK by Java community
OpenJDK 6 will be based on OpenJDK 7
Now only Modules project - JSR 277, JSR 294
Java development process
About JDK 7 - http://today.java.net/pub/a/today/2007/08/09/looking-ahead-to-java-7.html
No official JSR
Still in discussion
JUG (Java User Group)
Unofficial JSR for JDK7
Published on 7th November
Specify
Closures
Generics, enum, switch enhancements
Chained invocations, extension methods
Exception catching
Language extensions
http://www.bejug.org/newsletter/05/index.html
Generics
Constructors without duplicate declaration
Map anagrams = new HashMap();
instead of
Map anagrams = new HashMap();
Generics are not still covariant!
List li = new ArrayList();
List ln = li; // illegal
ln.add(new Float(3.1415)); // legal
More type safe packages
JDK 5: static Object newInstance(Class componentType, int size)
Because of backward compatibility
JDK 5,7: static T[] newInstance(Class componentType, int size)
More type-safe, can be called Array.newInstance(String.class, 10)
Inference of method arguments
static Set emptySet();
void print(Set men) {...}
Call: print(Collection.emptySet()) // in JDK5,6 is necessary to explicitly specify which method should be called: Collection.emptySet();
Template type information available at runtime
Lang. Ext. - JUG proposal
BeJUG proposalhttp://www.bejug.org/newsletter/05/index.html
Covariant collectionshttp://www.ibm.com/developerworks/java/library/j-jtp01255.html
Generics FAQhttp://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html
Enum
JDK6: Enum implements Comparable, but cannot be used in expressions with , >=, 25]);for (XML a : l) { a.get(age).set(newAge);}}
JDK7
JDK7
XSD = XML schema (like DTD)http://www.w3.org/XML/Schema
Closures
Similar to delegates in C#
Anonymous functions
Function type
Local functions
Main idea: translate closure to interface (similar to creating anonymous classes)
Lang. Ext. - closures
{String, String => String} simpleConcat = {String a, String b => a+b };
String s = DS;String g = RG;
String dsrg = simpleConcat.invoke(s,t);
interface Func { public R invoke(A1, A2);}
Locks.withLock(lock, {=> doSomething()});Collections.map(strings, {Strings s => Integer.decode(s)});
JDK7
Closures proposalhttp://www.javac.info/http://www.javac.info/closures-v05.htmlClosures: Open Issues (v0.5)
* Make it easy to yield a result early from a closure. It should be as easy to yield a result early from a closure as returning from a method. * Should support for currying be directly in the language? Bound method references? * Handle interfaces like Comparator that define more than one method, all but one of which will be implemented by a method inherited from Object. The definition of "interface with a single method" should count only methods that would not be implemented by a method in Object and should count multiple methods as one if implementing one of them would implement them all. Mainly, this requires a more precise specification of what it means for an interface to have only a single abstract method. * Specify mapping from function types to interfaces: names, parameters, etc. We should fully specify the mapping from function types to system-generated interfaces precisely. * Type inference. The rules for type inference need to be augmented to accomodate the inference of exception type parameters. Similarly, the subtype relationships used by the closure conversion should be reflected as well. * VM support for null The verifier already supports null, including in the verifiers, but there is no way to specify null as a method argument or return type. We need a way to specify null in a signature (that is, a new signature letter). * Elided exception type parameters to help retrofit exception transparency. Perhaps make elided exception type parameters mean the bound. This enables retrofitting existing generic interfaces that don't have a type parameter for the exception, such as java.util.concurrent.Callable, by adding a new generic exception parameter. * Document the new unchecked Throwables for nonlocal transfers. * Should javac detect the most common problematic interactions catching nonlocal transfers? The most likely case may be completely local within a single method, when a nonlocal transfer has a try-catch between the transfer and its target. * volatile on locals. We should say it is allowed. * How are class literals for function types formed? Is it {?=>?}.class ? * The system class loader should dynamically generate function type interfaces. The interfaces corresponding to function types should be generated on demand by the bootstrap class loader, so they can be shared among all user code. For the prototype, we may have javac generate these interfaces so prototype-generated code can run on stock (JDK5-6) VMs. * Can or should javac inline some invocations of control abstraction APIs? If so, how will it decide which ones? Does the inlining happen at the bytecode or source level? Will javac handle break/return/continue efficiently when these are inlined? Or is this something should be left for the VM to handle? (Hotspot already seems to handle the most important cases) * Do we need any new reflection support for closures? For function types? For null? Probably not because of the information available in the defining (not bridge) methods. * Should a labelled for control invocation statement interact with labelled break and continue? * Should for be a modifier (before the return type in a method declaration) or appear next to the name? * Would explicit VM support for nonlocal transfers improve performance? * Should we request VM support for proper tail recursion? * Should we support (parametric) polymorphic function types? Probably not.
Additional information
@Licence
Annotations for static analysis of code
@NonNull
@NonEmpty
@ReadOnly
@Existing
@Critical
Lang. Ext. - annotation extension
Operator overloading (BigDecimal)
Arithmetic operators for BigDecimal
Lightweight reflection
64bit index for arrays
XQuery support (JSR 225)
Resource Consumption Management API (JSR 284)
Performance policies (CPU, heap consumption per application/thread, reservations)
Null-safe types
public void method(#K key)
# marks not-null parameter
Checked at compile time (globally, per-method,...)
(#) casting operator
Alternative to @NonNull annotation
Lang. Ext. - proposed enhancements
Null-safe typeshttp://docs.google.com/View?docid=dfn5297z_2kjj2fk&pli=1
Separated projects
Almost work in the current version of Java
Proposed to be part of JDK7
Java Modules
Beans bindings, validation
Swing application API
...
Related projects
Superpackages (JSR 294)
Why? To hide unnecessary packages.
Superpackage is a named collection of packages or superpackages, classes
Accessibility defined by superpackages
Compiled, loaded and checked by JVM at runtime
Define development module for JSR 277 (Java Module System)
Separate compilation ?
Not yet specified
Rel. projects modules
superpackage jdk { member package java.util; member package java.io; member package sun.io; // Impl detail export java.util.*; // Public API export java.io.*;}
JDK7
Superpackage proposalhttp://blogs.sun.com/andreas/resource/superpackage_strawman.htmlhttp://blogs.sun.com/andreas/entry/superpackages_in_jsr_294
Java Modules (JSR 277)
Specifies:
Modules, Versioning, Repository, Runtime support
Development module (=superpackage) => deployment module (JAM Java Module)
Meta-info (generated from devel. module)
Compiled code
Resources
Versioning
Simple major/minor versions
Intervals, expressions e.g 1.3* =