Java 7 * New Features - Svetlin Nakov

Java 7 – New Features
Mihail Stoynov, Svetlin Nakov
Bulgarian Association of Software Developers
Spring Conference of the Bulgarian Oracle
User Group (BGOUG), Plovdiv, 24 April 2010
Table of Contents
• Introduction and Chronology
• Compressed 64-bit Object Pointers
• Garbage-First GC (G1)
• Dynamic Languages in JVM
• Java Modularity – Project Jigsaw
• Language Enhancements (Project Coin)
Strings in Switch
Automatic Resource Management (ARM)
Improved Type Inference for Generic
Instance Creation
Table of Contents (2)
Improved Type Inference for Generic
Instance Creation
Simplified Varargs Method Invocation
Collection Literals
Indexing Access Syntax for Lists and Maps
Language Support for JSR 292
Underscores in Numbers
Binary Literals
• Closures for Java
• First-class Functions
Table of Contents (3)
• Function Types
• Lambda Expressions
• Project Lambda
• Extension Methods
Upgrade Class-Loader Architecture
Method to close a URLClassLoader
Unicode 5.1
JSR 203: NIO.2
SCTP (Stream Control Transmission Protocol)
SDP (Sockets Direct Protocol)
Introduction and
• JDK7 is the second JDK done via the
OpenJDK effort
• OpenJDK is free, open-source and GPL
• A lot of the improvements of JDK7 are
separate projects on OpenJDK
• Some say that projects go under the cap of
OpenJDK to avoid the cumbersome and slow
JCP process
• Began in August 2006
• First supposed to be 7 milestones
• Mark Reinhold extended them to 10
• Current status: M7 finished, presentation
made with build89
• M10 expected to finish 09.09.2010
“The last scheduled milestone cycle will be
followed by a test and stabilization period of
indeterminate length, after which the final
release will be declared”
There’s No JSR Yet
• A JSR is supposed to be formed
• Java SE 6 was under the 'Umbrella' JSR 270
• JDK7 is in Eclipse’s low priority list because a
lack of container JSR
• JDK7 cannot be finalized without a JSR
• There are some functionalities that also lack
• While doing this presentation we used the
term JSR TBD in lieu of the missing JSR
Source Control System
• Official SCM is SVN, still
>svn co
• Note: it takes a 'while'
• Unofficial Mercurial forest repositories
available since November 2007
>hg fclone
• Note: this also takes a 'while'
Currently Supported IDEs
• Eclipse
• Both Eclipse 3.6M6 and E4 do not support
JDK7’s syntax
• …or the presenters couldn’t figure it out 
• Strangely enough the option is there:
• Source compatibility: 1.7
• NetBeans
• 6.9 Beta supports JDK7
• All the demos are done with it
• Eclipse was used to create the presentation 
Compressed 64-bit
Object Pointers
What is an oop?
• An "oop", or "ordinary object pointer" in
HotSpot parlance is a managed pointer to an
• it is normally the same size as a native
machine pointer
• which means 64 bits on an LP64 system
• (LP64 = Long and Pointer are 64bit long)
• On an ILP32 system, there is a maximum heap
size of somewhat less than 4GB
• which is not enough for many applications
The Problem – 50% Larger Heap
• On an LP64 system the heap for any given
run may have to be around 1.5 times as large
as for the corresponding IPL32 system
• assuming the run fits both modes
• This is due to the expanded size of managed
• Memory is pretty cheap, but these days
bandwidth and cache is in short supply
• so significantly increasing the size of the
heap just to get over the 4GB limit is painful
Compressed oops
• Compressed oops = managed pointers
• 32-bit values, must be scaled by a factor of 8
and added to a 64-bit base address to find the
object they refer to
<base> + (<narrow-oop> << 3) + <offset>
• in many but not all places in the JVM
• This allows applications to address up to
four billion objects (not bytes)
• or a heap size of up to about 32Gb
• At the same time, data structure
compactness is competitive with ILP32 mode
Encoding / Decoding
• The term decode expresses the operation by
which a 32-bit compressed oop is converted
into a 64-bit native address into the heap
• The inverse operation is encoding
• All oops are the native machine word size in
• An ILP32-mode JVM
• In LP64 mode, when the UseCompressedOops
flag is turned off
• The Hotspot VM's data structures to manage
Java classes are not compressed
Null Processing
• A 32-bit zero value decodes into a 64-bit
native null value
• An awkward special path is required in the
decoding logic
• It is profitable to statically note which
compressed oops are guaranteed never to be
null and use a simpler version of the full
decode or encode operation
• Implicit null checks are crucial to JVM speed
• Trick: if compressed null is ever decoded,
there’s a signal – the first page or so of the
virtual addresses used by heap is not mapped
Zero Based Compressed oops
<oop-base> + (<narrow-oop> << 3) + <field-offset>
• Narrow oop base = java heap base minus one
protected page (for implicit null checks)
• If the narrow oop base can be made to be zero:
(<narrow-oop> << 3) + <field-offset>
• Also if Java heap size < 4Gb and it can be
moved into low virtual address space (below
4Gb) then compressed oops can be used
without encoding/decoding
<wide_oop> = <narrow-oop>
Garbage-First GC
Java GC – Introduction
• Java GC divides heap into young and old
generations of objects
• Takes advantage of the observation that the
vast majority of objects die young glorious
• Very small number of objects live for a very
long time (effectively the life of the app)
• Few references from the old generation to the
young generation
• Focus collection attention on the young gen
Concurrent Mark Sweep GC
• Garbage collector up to and including Java 6
is called Concurrent Mark Sweep (CMS)
• CMS has minor and major cycles (for
different gen spaces – young, tenured, perm)
• Young gen GC is concurrent
• Old gen GC does stop-the-world pauses to
mark and finish up
• Fallback to full stop-the-world for old gen
G1 Garbage Collector
• G1 divides the all memory (except perm gen)
into 1 MB “regions”
• Regions are either old or young
• In G1, the old generation GC there is one
stop-the-world pause to mark
• G1 uses “remembered sets” to manage
references into a region
• Every region has a small data structure (<5%
of total heap)
• The remembered sets contain all external
references into that region
G1 Additional Facts
• Garbage-first is a server-style garbage
• Targeted for multi-processors with large
• meets a soft real-time goal with high
• while achieving high throughput
• Added in Milestone1 (02.01.2009)
• Released in Java 6 update 6u14
• Support contract controversy
Languages in JVM
Dynamic Languages in JVM
• Da Vinci Machine Project
• A.k.a. Multi Language Virtual Machine –
• Aimed to allow non-Java languages to run
efficiently in the JVM
• JSR 292: Supporting Dynamically Typed
Languages on the Java Platform
• The standard behind Da Vinci Machine
• Natural continuation of JSR 223: Scripting for
the Java Platform implemented in JDK 6
Dynamic Languages in JVM (2)
• New JVM instruction invokedynamic
• Allows extremely fast dynamic method
invocation through method handles
• Will enable JRuby, Jython, Groovy and other
dynamic and scripting languages to call
dynamic methods natively at bytecode level
• Method handles
• Lightweight references to a method –
• Anonymous classes in the JVM
Dynamic Languages in JVM (3)
• Autonomous methods
• Methods that can be dynamically attached to
an existing class at runtime
• Interface injection
• Acquiring base interfaces and method
implementations at runtime
• Continuations and stack introspection
• Suspend / resume thread's execution stack
• Tail calls and tail recursion
Dynamic Languages in JVM (4)
• Runtime support for closures
• Closure is a lambda-expression bound
(closed) to its environment
• Multimethods
• Dispatch a method overload depending on the
actual arguments at runtime
• Faster reflection and faster interface
invocation based on dynamic invocation
• Symbolic freedom for identifier names
Dynamic Invoke – Example
static void greeter(String x) {
System.out.println("Hello, " + x);
static MethodHandle greeterMethodHandle =
DynamicInvocation.class, "greeter", MethodType.
methodType(void.class, String.class));
static {
Dynamic Invoke – Example (2)
private static CallSite bootstrapDynamic(
Class caller, String name, MethodType type) {
if (type.parameterCount() == 1 && name == "hail") {
MethodHandle target = MethodHandles.
convertArguments(greeterMethodHandle, type);
CallSite site = new CallSite(caller, name, type);
System.out.println("Set the CallSite target to " +
return site;
public static void main(String... args) {
InvokeDynamic.hail("dynamic invocation");
Java Modularity
Project Jigsaw
• The JDK and the JRE, have always been
delivered as massive, indivisible artifacts
• The growth of the platform has thus
inevitably led to the growth of the basic JRE
• which now stands at well over 14MB
• despite heroic engineering efforts such as
the Pack200 class file compression format
• Java Kernel and Quickstarter features do
improve download time and startup time, at
least for Windows users
The Real Solution
• The most promising way to improve the key
metrics of
• Download time
• Startup time
• And memory footprint
• Is to attack the root problem head-on:
• Divide the JDK into a set of well specified and
separate, yet interdependent, modules
• A side effect is that JAR format has to
Alan Bateman: It’s Difficult
• Suppose you are using the Logging API
• Logging requires NIO (for file locking)
• And JMX (as loggers are managed)
• JMX requires JavaBeans, JNDI, RMI and
CORBA (JMX remote API mandates that the
RMI connector support both JRMP and IIOP)
• JNDI requires java.applet.Applet (huh?) and
JavaBeans has dependencies on AWT, Swing
• Not satisfied with this, JavaBeans has
persistent delegates that create dependencies
on JDBC and more
How to Do It?
• Modularizing the JDK requires a module
system capable of supporting such an effort
• It requires, in particular, a module system
whose core can be implemented directly
within the Java virtual machine
• Modularizing is best done with a module
system that’s tightly integrated with the Java
• Otherwise the compile-time module
environment can differ dramatically from the
run-time module environment
Which Module System?
• JSR 277 proposes the JAM module system
• Some of its rich, non-declarative features
would be impossible to implement its core
functionality directly within the JVM
• Therefore Sun halted the development
• JSR 294 is chartered to extend the language
and JVM to support modular programming
• Well received for its simplicity and its utility to
existing module systems such as OSGi
Which Module System? (2)
• OSGi
• May 2007: OSGi 4.1 standardized as JSR-291
• Reasonably mature, stable, and robust
• Implemented within Apache Harmony JVM
• Not at all integrated with the Java language
• Jigsaw created to modularize JDK7
• Will not be an official part of the Java SE 7
Platform Specification and might not be
supported by other SE 7 implementations
Status and Examples
• Probably JSR 294 will be chosen
• There are issues, JSR 294 is inactive (paused)
• Not implemented yet (b89), java.lang.module
• Example (may, and probably will, change)
module [email protected] provides [email protected], [email protected] {
requires [email protected], [email protected];
permits M6; // only M6 can depend on M1
module M;
package P;
public class Foo {...}
JSR 308:
Annotations on
Java Types
JSR 308 – Introduction
• Java SE 6 permits annotations only on
• JSR 308 extends Java’s annotation system
so that annotations may appear on nearly
any use of a type
• JSR 308 is backward-compatible and
continues to permit those annotations
• Two new types of annotations (target wise):
• ElementType.TYPE_USE
Source Locations for
Annotations on Types
• A type annotation appears before the type
@Nonnull String s = "";
• The annotation on a given array level
prefixes the brackets that introduce that level
public static void main(String @NonEmpty ... args) {
@English String s @NonEmpty [] = new String[]{""};
• The varargs syntax ... is treated analogously
to array brackets and may also be prefixed by
an annotation
Source Locations for
Annotations on Types (2)
• An annotation on the type of a method
receiver (this) appears just after the
parameter list and before any throws clause
• Each non-static method has an implicit
parameter, this, which is called the receiver
public String toString() @Readonly { ... }
• An annotation on a type parameter
declaration appears before the declared
name or wildcard
Map<@NonNull String,
@NonEmpty List<@Readonly Document>> f;
JSR 308: More Examples
public static void main() {
//for generic type arguments in a generic method
JSR308Example2.<@NonNull String>method("...");
//for type parameters and type parameter bounds:
Collection<@Long ? super @Existing File> c = null;
//for class inheritance:
class UnmodifiableList<T> implements
@Readonly List<@Readonly T> { }
//for throws clauses:
void monitorTemperature() throws @Critical Exception {}
//for method receivers:
public String toString() @Readonly { return null; }
// helper only
public static <T> T method(String s) {return null;}
• Type Annotations are available in b89
• Introduced in M4
• Unfortunately the specification says:
• “To do: Complete this design.”
• So Reflection API is not ready yet
• Anyway reflection gives no access to method
Usage of Type Annotations
• One example use is to create custom type
qualifiers for Java
• such as @NonNull, @ReadOnly, @Interned
• A declaration that uses a qualified type
provides extra information
• A designer can define new type qualifiers
using Java annotations, and can provide
compiler plug-ins to check their semantics
• For instance, by issuing lint-like warnings
during compilation
• Example Plug-in: The Checker Framework
An Example That Makes Sense
class DAG {
Set<Edge> edges;
// ...
List<Vertex> getNeighbors(
@Interned @Readonly Vertex v) @Readonly {
List<Vertex> neighbors = new LinkedList<Vertex>();
for (Edge e : edges)
if (e.from() == v)
return neighbors;
Small Language
(Project Coin)
Project Coin – Introduction
• Project Coin unites all language changes to
the Java Lang Specification (JLS) to be
added to JDK 7
• Open call for proposals
• From February 27, 2009
• Through March 30, 2009
• 70 proposal forms
• 9 were chosen
• No Milestone selected yet (so not all features
are available)
The Chosen Ones
• Strings in Switch
• By Joseph D. Darcy
• Automatic Resource Management
• By Joshua Bloch
• Improved Type Inference for Generic
Instance Creation
• By Jeremy Manson
• Simplified Varargs Method Invocation
• By Bob Lee
The Chosen Ones (2)
• Collection Literals
• By Joshua Bloch
• Indexing access syntax for Lists and Maps
• By Shams Mahmood
• Language support for JSR 292
• By John Rose
• Binary Literals
• Underscores in numbers
• By Derek Foster
1. Strings in Switch
Strings in Switch
• Syntactic sugar
// Finally! - strings in switch
String s = "";
switch (s) {
case "Edno":
case "Dve":
out.println("Unknown BG number.");
2. Automatic Resource
ARM – The Problem
• A resource is as an object that must be
closed manually
• InputStream, Reader, Writer, Formatter
• Manual resource termination has proven ugly
and error prone
• Even good programmers get it wrong
• Resource leaks or even outright failures,
which may be silent
• If an exception is thrown in the try block, and in
the finally block, the second supplants the first
ARM – The Problem (2)
• Where’s the problem with this code?
BufferedWriter br =
new BufferedWriter(new FileWriter(path));
try {
} finally {
• If an exception is thrown in the try block, and in
the finally block, the second supplants the first
• Was "Text" written successfully?
How it’s Done (One Resource)
• Try-finally – with one resource:
BufferedWriter br =
new BufferedWriter(new FileWriter(path));
try {
// This exception is more important
} finally {
try {
// ... than this one
} catch(IOException ioe) {}
How it’s Done (Two Resources)
static void copy(String src, String dest) throws IOException {
InputStream in = new FileInputStream(src);
try {
OutputStream out = new FileOutputStream(dest);
try {
byte[] buf = new byte[8 * 1024];
int n;
while ((n = >= 0)
out.write(buf, 0, n);
} finally {
try {
} catch(IOException ioe) {}
} finally {
try {
} catch(IOException ioe) {}
Automatic Resource
• ARM statement is a form of the try statement
that declares one or more resources
• The scope of these resource declarations is
limited to the statement
• When the statement completes, whether
normally or abruptly, all of its resources are
closed automatically
• As of b89 not yet available, but definitely
going to be inside JDK7
ARM Syntax – Two Resources
static void copy(String src, String dest) throws IOException {
try (InputStream in = new FileInputStream(src);
OutputStream out = new FileOutputStream(dest)) {
byte[] buf = new byte[8192];
int n;
while ((n = >= 0)
out.write(buf, 0, n);
• Code is still 4 lines
• Boilerplate was 11 (try, catch, finally,
close() clauses), now it’s 0
• The first exception is thrown if a problem
occurs, the close() exception is hidden
An Interface Must be Chosen
• A class must implement a designated
interface to make it eligible for automatic
resource management
public interface Closeable {
public void close() throws IOException;
• An obvious choice would be Closeable
• close() method throws IOException
• Precludes its use in a general purpose
resource management facility
An Interface Must be Chosen (2)
• It is possible to retrofit Closeable with a
parameterized superinterface
package java.lang;
public interface Disposable<X extends Throwable> {
void close() throws X;
• Disposable would become:
public interface Closeable extends Disposable<IOException> {
void close() throws IOException;
ARM – Notes
• No interface is chosen, nor implemented yet
• As of b89
• Migration
• Any resource that must be closed manually
should be retrofitted to implement the
Disposable interface
• In the JDK, this includes:
• Closeable (all streams implement it)
• Connection, Statement, and ResultSet
Proposal Moto
• New code should use ARM statements for
clarity and correctness
• Existing code can be replaced by ARM for
increased clarity and improved behavior
• Given the number of resource management
errors observed in existing code, it may be
worth the time to do this systematically
• Proposal author gives high-profile examples
• Any modern IDE can search for uses of a
method (in this case, Disposable.close())
ARM – Shortcomings
"One shortcoming of the construct is that it does
not provide a way for the programmer to indicate
that exceptions thrown when closing a resource
should be ignored"
"In the case of the copy method ideally the
program would ignore exceptions thrown when
closing the InputStream but not the OutputStream"
"There are several ways this could be achieved“
• The proposal does not state what they are
Suppressed Exceptions
• ARM discards suppressed exceptions
• Proposal implies they can be saved by
adding them in suppressing exception via
two new methods to Throwable:
• void addSuppressedException(Throwable)
• Throwable[]getSuppressedExceptions()
• As of b89 not implemented and it’s not clear
whether they will be
3. Improved Type
Inference for Generic
Instance Creation
The Problem
• Type inference works on method invocations
• Type inference does not work on .ctors
• Google collections solved this by factories
public class Lists {
// ArrayList
public static <E> List<E> newArrayList() {
return new ArrayList<E>();
public static <E> List<E> newArrayList(int i) {
return new ArrayList<E>(i);
List<String> list = Lists.newArrayList();
What is the Fuss All About?
• Simply this:
Map<String, List<String>> anagrams =
new HashMap<String, List<String>>();
• … becomes:
Map<String, List<String>> anagrams = new HashMap<>();
• <> is called the ‘diamond‘
• Cannot be omitted because no difference can
be made between raw HashMap and a
parameterized one
• [Ctrl+Shift+F] fails on diamond in NetBeans 6.9
• Implemented in b89
Diamond <>: Quiz
• Which of these are valid?
public static void main() {
List l = new ArrayList<>();
new ArrayList <>().addAll(new ArrayList<>());
new ArrayList <>().addAll(new ArrayList<String>());
new ArrayList <String>().addAll(new ArrayList<>());
• I think the organizers forgot to give us stuff
that we can give away
Diamond <>: Advanced
• This is supposed to work:
public class AdvancedExample {
public static void main() {
method("", new ArrayList<>(), new ArrayList<>());
public static <T> T method(
T a, List<T> b, List<Map<T, T>> c) {
return a;
• …but does not yet (as of b89)
4. Simplified
Varargs Method
Simplified Varargs Method…
• The compiler currently generates an "unsafe
operation" warning when a programmer tries
to invoke a varargs (variable arity) method
with a non-reifiable varargs type
• This change moves the warning from the call
site to the method declaration
• Major advantages
• reduces the total number of warnings
reported to and suppressed by programmers
• Enables API designers to use varargs with
non-reifiable types
A Picture is Worth a 1000 Words
/** NOT WORKING in b89, no change with jdk1.6.0_20 */
public static void main() {
Callable<String> t = null;
//OLD: Warning: "uses unchecked or unsafe operations“
List<Callable<String>> merged = asList(t);
// NEW: Warning: "unchecked generic array creation"
private static <T> List<T> asList(T... elements ) {
return Arrays.asList(elements);
Simplified Varargs – Example
interface Sink<T> {
void add(T... a);
/** NOT WORKING in b89, no change with jdk1.6.0_20 */
interface BrokenSink<T> extends Sink<T> {
// OLD: no warning
// NEW: Warning: "Overriddes non-reifiable varargs type
with array"
void add(T[] a);
/** NOT WORKING in b89, no change with jdk1.6.0_20 */
class StringSink implements Sink<String> {
// OLD: no warning
// NEW: Warning: "override generates a more specific
varargs type erasure"
public void add(String... a) {}
5. Collection
Collection Literals
• Again a syntax sugar
/** NOT WORKING in b89 */
public static void main(String... args) {
List<String> list = ["Edno", "Dve"];
Set<String> set = {"Edno", "Dve"};
Map<String, Integer> map = {"Edno" : 1, "Dve" : 2};
// Note:
Object s = { }; // empty set;
Object m = {:}; // empty map;
• Not yet available, so no demo 
6. Indexing Access
Syntax for Lists
and Maps
Collection Literals
• Syntax sugar
/** WORKING in b89 */
public static void main(String... args) {
List<String> list =
Arrays.asList(new String[]{"a", "b", "c"});
Map<Integer, String> map =
new HashMap<Integer, String>(4);
String firstElement = list.get(0);
map.put(1, "Edno");
String firstElement = list[0];
map[1] = "Edno";
7. Language Support
for JSR 292
The Da Vinci Machine Project
Da Vinci: a multi-language renaissance
for the Java Virtual Machine architecture
• This project will prototype a number of
extensions to the JVM
• So that it can run non-Java languages
• With a performance level comparable to that
of Java itself
• Emphasis is on general purpose extensions
• Hosted on OpenJDK
The Da Vinci Machine Project (2)
• Looking to remove “pain points” already
observed by implementers of successful or
influential languages
• Sub-projects with major activity include
• Dynamic invocation
• Continuations
• Tail-calls
• And interface injection
• Large number of more speculative, lowerpriority sub-projects
JSR 292 Support in javac
• java.dyn.InvokeDynamic will accept any
method call and turn it into an
invokedynamic instruction
• The type java.dyn.MethodHandle will accept
any argument and return types
• Bytecode names acceptable to the JVM can be
spelled from Java code, using #" "
• java.dyn.InvokeDynamic serves as a bare
reference type: anything implicitly converts to it
• it can be cast to anything, but it is not a
subtype of java.lang.Object
JSR 292 – Example
// Works in b89
// type (Object, int) -> boolean
boolean z =
java.dyn.InvokeDynamic.<boolean>myEquals(x, y);
// Works!!! in b89
MethodHandle hndl = MethodHandles.lookup().findVirtual(
PrintStream.class, "println", MethodType.methodType(
void.class, String.class));
hndl.invokeGeneric(System.out, "holy cow?!");
// Works in b89
String #"g 1 $!$#%" = "Text";
System.out.println(#"g 1 $!$#%");
9. Underscores in
Underscores in Numbers
• Too much sugar can cause diabetes
• May seem useless, but don’t judge too quickly
/** WORKING in b89 */
public static void main(String... args) {
int oldBillion = 1000000000;
int newBillion = 1_000_000_000;
10. Binary Literals
Binary Literals
• The syntax is 0b11110000;
• See where underscores come in handy?
/** WORKING in b89
public static void
int oldBinary1 =
int oldBinary2 =
main(String... args) {
128 ^ 0 ^ 0 ^ 16 ^ 8 ^ 0 ^ 0 ^ 1;
int newBinary = 0b1001_1001;
out.println(format("[0b1001_1001] is {0}", newBinary));
Closures in Java
First-class Functions, Function
Types and Lambda Expressions
What are Closures?
• Closures – definition
• Closures are functions that are evaluated in
an environment containing one or more
bound variables [Wikipedia]
• In English: a little snippet of code (function)
that can be passed as argument of some
method for subsequent execution
• Closures come from functional programming
languages like Lisp
• Limited support for closures since JDK 1.1,
in the form of anonymous classes
First-class and Anonymous
• First-class functions are programming
paradigm that supports
• Data structure holding a function with its
parameters and return type
• Passing functions as arguments to other
functions and invoking them
• Returning functions as result
• Anonymous functions
• Functions without name (lambda functions)
• Take some parameters and return a value
Lambda Expressions
• Lambda calculus
• A formal mathematical system for function
definition, function application and recursion
• Typed and untyped lambda calculus
• Lambda expressions
• Anonymous functions that take parameters
and return values, e.g.
• x → x*x
• (x, y) → x*x + y*y
• A.k.a. lambda functions
Project Lambda
• Project Lambda
• Goals
• To formulate a proposal to add first-class
functions, function types, and lambda
expressions (informally, "closures") to Java
• To implement a prototype suitable for inclusion
in JDK 7
• Official Web Site
• Status
• Straw-man proposal, still no JSR
Lambda Expressions in Java
• Lambda expressions in Java use the # syntax
• Function with no arguments, returns 42:
• Function with int argument:
#(int x)(x + x)
• Function with two int arguments:
#(int x, int y)(x * y)
Lambda Expressions with
Code Block
• Lambda expressions can have body
• A Java code block:
#(int x, int y) {
int z = (int)Math.sqrt(x*x + y*y);
if (z < 10)
return x;
else if (z > 10)
return y;
return 0;
Function Types
• Function types are data types that hold a
reference to lambda function or method:
#int() fortyTwo = #()(42);
#int(int) triple = #(int x)(3*x); #int(int,int)
mult = #(int x, int y)(x * y);
• Functions stored in variable of function type
can be invoked like any other function:
int result = triple(5);
int multResult = mult(3, 5);
Functions as Arguments
• Lambda functions can be passed as
arguments to a method
public long sum(int[] arr, #int(int) fn) {
long sum = 0;
for (int element : arr)
sum += fn(element);
return sum;
int[] arr = new int[] {1, 2, 3, 4};
long squaresSum = sum(arr, #(int x)(x*x));
System.out.println(squaresSum); // 30
Functions as Return Value
• Lambda functions can be returned as result
of method execution:
public #int(int) adder(int c) {
return #(int x)(x + c);
#int(int) a42 = adder(42);
System.out.println(a42(2)); // 44
Function Conversions
• Lambda functions can be converted to abstract
class / interface defining a single method:
Thread th = new Thread(new Runnable() {
public void run() {
Thread th = new Thread(#(){
doSomeStuff(); doMoreStuff(); } )
Variable Capture
• We can share local state between the body of
a lambda expression and its enclosing scope
• A new keyword shared is introduced
shared int comparisonsCount = 0;
Collections.sort(data, #(String a, String b) {
return a.compareTo(b);
Instance Capture
• The this reference of the enclosing class
could be accessed in a lambda expression:
class CountingSorter {
private int comparisonsCount = 0;
#(String a, String b) {
return a.compareTo(b);
Extension Methods
• Extension methods allow the author of an
existing interface to add methods to that
interface while preserving compatibility
• For example, we need to add a method for
filtering members from any collection by
given Boolean condition:
Set<Integer> set =
new Set<Integer>(new int[] {1,2,3,4,5});
Set<Integer> filteredSet =
set.filter(#boolean(int x)(x < 3));
Extension Methods (2)
• Defining extension methods:
class Collections {
static <T> Set<T> filter(
Set<T> s, #boolean(T) pred) { … }
static <S,T> Set<S> map(
Set<T> s, #S(T) func) { … }
interface Set<T> extends Collection<T> {
Set<T> filter(#boolean(T)) import static
<S> map(#S(T)) import static;
Extension Methods (3)
• Using extension methods:
int ints = new int[] { 1, 2, 3, 4, 5 };
int[] transformedInts =
s.filter(#(int x)(x % 2 == 0))
.map(#(int x)(x + 3));
// transformedInts = { 5, 7 }
int[] transformedInts =
Collections.filter(s, #(int x)(x % 2 == 0)),
#(int x)(x + 3)
Parallel Arrays API
• The class ParallelArray<T> allows parallel
aggregate operations over a collection
• Apply transformation to each element
• Map each element to a new element
• Select subset of the elements by predicate
• Reduce elements to a single value (e.g. sum)
• ParallelArray<T> can utilize efficiently
multi-core / multiprocessor systems
• Ideal candidate for extension methods
Upgrade ClassLoader Architecture
The Problem
• Bug ID: 4670071
• Submit Date: 17-APR-2002
• Release Fixed: 7(b47)
• Means: Fixed in JDK7 (build 47)
• b47 got released Q1 2009
• The bug is about a classloader deadlock
• deadlocks as caused by non-interceptible
loadClassInternal() calls
• How many of you know about the existence
of bug 4670071?
Method to close a
• Complex Java programs sometimes create
their own class loaders using
the URLClassLoader type
• With it applications can load classes and
resources from a search path of URLs:
• file:
• jar:
• http:
• which load from directories, jar files, and http
servers respectively
The Problem
• A frequent problem has been how to support
updated implementations of loaded classes
• In principle, once the application clears all
references to a loader object, the garbage
collector will eventually ensure that all
resources are released and closed
• Applications need to be able to do this in a
predictable and timely fashion
• It is a particular problem on Windows,
because open files cannot be deleted or
A Simple Solution
• To alleviate this problem, URLClassLoader
has acquired a new method called close()
• since b48 of JDK 7
• Invalidates the loader, so that no new classes
can be loaded from it
• It also closes any jar files that were opened by
the loader
• This allows the application to delete/replace
these files and if necessary create new loaders
using new implementations
/** @since 1.7 */
Unicode 5.1
• Java 6 is Unicode 4.0 compliant
• Java 7 will be Unicode 5.1 compliant
• Most up-to-date version of Unicode is 5.2
(October 2009)
• What's new in Unicode 5 ?
• Unicode 5.0 will include 1,369 new characters
and 9 new blocks (~alphabets)
• Unicode 5.1 will have 1,624 additional char’s
making a grand total of 100,713 breaking the
100K mark for the first time
5.0 Phoenician Controversy
• The Phoenician (Финикийски език) "debate“
will be remembered with disgust for many
years to come
• Thousands of postings on the Unicode
public mailing list
• Diametrically opposed (and
immovable) positions
• Finally in 5.1: the enigmatic Phaistos Disc
• First proposed for encoding ten years ago
• Delayed because there were undeciphered
symbols found on a unique artifact
JSR 203:
More New I/O APIs for the
Java Platform
NIO2 – Introduction
• New I/O or non-blocking I/O, usually
called NIO, is a collection of Java
programming language APIs that offer
features for intensive I/O operations
• It was introduced with the J2SE 1.4
• NIO was developed under the Java
Community Process as JSR 51
• As of 2006, an extension to NIO, called NIO2,
is being developed under JSR 203
• JSR 203 is scheduled to be included in JDK 7
How to Copy a File
• Up to Java 6 (w/o channels) it looks like this:
try {
from = new FileInputStream(fromFile);
to = new FileOutputStream(toFile);
byte[] buffer = new byte[4096];
int bytesRead;
while ((bytesRead = != -1)
to.write(buffer, 0, bytesRead); // write
} finally {
// Close to and from
• Familiar?
• The presenter learned this pattern 8 years ago
(Ironically taught by the other presenter)
How to Copy a File (2)
• is used to represent a file
• @since 1.0
• Is there a way to copy metadata?
• JDK7: -> java.nio.file.Path
FileSystem local = FileSystems.getDefault();
Path from = local.getPath(FileName);
Path to = local.getPath(toFileName);
• won’t be deprecated, but should
• Path is a better name (might be a dir, right?)
// -> java.nio.filePath
Path p = new File("/foo/bar.txt").toPath();
Cool New Things: resolve()
• resolve()
public static void resolve() {
FileSystem fileSystem = FileSystems.getDefault();
Path currentDir = fileSystem.getPath(".");
Path srcDir = fileSystem.getPath("src");
Path file1 = fileSystem.getPath("./");
Path file2 = fileSystem.getPath(“../");
"file2: " +
Cool New Things: relativize()
• relativize()
public static void relativize() {
FileSystem fileSystem = FileSystems.getDefault();
Path source = fileSystem.getPath(".");
Path temp = fileSystem.getPath("/temp");
Path relativeSource =
(Stream Control
Transmission Protocol)
• Stream Control Transmission Protocol
(SCTP) is a Transport Layer protocol
• serving in a similar role as TCP and UDP
• Features of SCTP include:
• Multihoming support: both endpoints of a
connection can consist of more than one IP
• Chunks delivered within independent streams
• Protect against flooding attacks
• No Windows supports SCTP
JDK7: The SCTP Project
• The goal of this Project is:
• To develop an API for the Stream Control
Transport Protocol (SCTP)
• And a corresponding OpenJDK prototype
• The API is implementation agnostic
• Included in build 56
• Could be hacked to work with JDK6
• Currently only Solaris is supported
(Sockets Direct Protocol)
• The Sockets Direct Protocol (SDP) is a
networking protocol originally defined by
the InfiniBand Trade Association
• Transport agnostic protocol for Remote Direct
Memory Access (RDMA)
• RDMA is a direct memory access from one
computer’s memory into another’s without
involving either one's operating system
• JDK7’s SDP implementation works,
unfortunately, only on Solaris
Java 7 New Features
Resources – Java Chronology
• JDK 7 – Features
• JDK 7 – Milestones
Resources – Compressed oops
• Compressed oops in the Hotspot JVM
• Wikipedia – 64-bit
• ILP32, LP64, and LLP64
• C Programming Language
Resources – Garbage Collection
• Garbage-First Garbage Collection
• JavaOne: G1 Garbage Collector
• Garbage Collection – Wikipedia
• Wikipedia – Hard and Soft Real-time Systems
Resources – Dynamic Langs
• New JDK 7 Feature: Support for Dynamically
Typed Languages in the Java Virtual Machine
• John Rose's weblog at Sun Microsystems
• JSR 292: Supporting Dynamically Typed
Languages on the Java Platform
Resources – Project Jigsaw
• Project Jigsaw: Language changes for Modules
• Project Jigsaw – Mark Reinhold’s Blog
• Is the JDK Losing its Edge(s)?
Resources – JSR 308
• Type Annotations Specification (JSR 308)
• Type Annotations FAQ (JSR 308)
• The Checker Framework: Custom Pluggable
Types for Java
Resources – Project Coin
• Project Coin
• Strings in switch
• Automatic Resource Management
Resources – Project Coin (2)
• Improved Type Inference for Generic
Instance Creation
• Simplified Varargs Method Invocation
• Collection Literals
Resources – Project Coin (3)
• Indexing access syntax for Lists and Maps
• Language support for JSR 292
• Binary Literals
• Underscores in numbers
Resources – Closures
• Project Lambda
• Project Lambda: Straw-Man Proposal
• Closures for Java – Mark Reinhold’s Blog
Resources – Upgrade
ClassLoader Architecture
• Draft Proposal for ClassLoader Deadlock Fix
•[email protected]/msg00863.html
• java.lang.ClassLoader.loadClassInternal(St
ring) is Too Restrictive
Resources – URL ClassLoader
• Closing a URLClassLoader
• Class URLClassLoader – close()
Resources – Unicode 5.1
• JDK 7 – Features – Unicode 5.1
• What's new in Unicode 5.0?
• What's new in Unicode 5.1?
Resources – NIO2
• Java New I/O
• JSR 203: The Open Road – java.nio.file
Resources – SCTP
• SCTP Project
Resources – SDP
• Understanding the Sockets Direct Protocol
• Sockets Direct Protocol – Wikipedia
• Remote Direct Memory Access
• Zero-copy
Resources – Authors
• Mihail Stoynov
• Svetlin Nakov

similar documents