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* =