Java 7 * New Features - Svetlin Nakov

Java 7 – New Features
Svetlin Nakov
Bulgarian Association of Software Developers
Egyptian Java User Group (EGJUG)
Cairo, 2 May 2010
About the Speaker
• Svetlin Nakov
• 15+ years software engineering
• PhD in computer science from
Sofia University
• Chairman of the Bulgarian Association
of Software Developers (BASD) –
• Author of 6 books about Java, .NET
and software engineering
• Web site:
Table of Contents
• Java 7 – Introduction and Chronology
• Dynamic Languages in JVM
• Java Modularity – Project Jigsaw
• Language Enhancements (Project Coin)
• Closures for Java
• JSR 203: NIO 2
• Other new features:
• Compressed 64-bit oops, Garbage-First GC,
Upgraded Class-Loaders, URLClassLoader.
close(), Unicode 5.1, SCTP and SDP
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
Java 7 – Milestones
• 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 Java 7 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' (e.g. one night)
• 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 I couldn’t figure it out 
• Strangely enough the option is there:
• Source compatibility: 1.7
• NetBeans
• 6.9 Beta supports JDK7
• Compiles successfully the M7 syntax
Languages in JVM
The Da Vinci Machine Project
Da Vinci: a multi-language renaissance
for the Java Virtual Machine architecture
• Prototype a number of extensions to the JVM
• A.k.a. Multi Language Virtual Machine –
• Allows non-Java dynamic languages to run
efficiently in the JVM
• Emphasis is on general purpose extensions
• Hosted on OpenJDK
Dynamic Languages in JVM
• Da Vinci Machine sub-projects include:
• Dynamic invocation
• Continuations
• Tail-calls
• And interface injection
• 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
Modularization – Introduction
• 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:
(Extended) 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
JSR 308: 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;}
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
Management (ARM)
ARM – The Problem
• A resource is as an object that must be
closed manually
• InputStream, Reader, Writer, DB connection
• 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) {}
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 now 4 lines
• Removed the boring nested try, catch,
finally, close() clauses
• The first exception is thrown if a problem
occurs, the close() exception is hidden
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 ARM is not yet available, but
definitely going to be inside JDK7
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
• What about general purpose resources?
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
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
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 <>: 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
method with a non-reifiable varargs type
• JDK 7 will move the warning from the call
site to the method declaration
• Major advantages
• Reduces the total number of warnings
reported to and suppressed by programmers
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 = ["One", "Two"];
Set<String> set = {"One", "Two", "Three"};
Map<String, Integer> map = {"One" : 1, "Two" : 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 Indexers
• Syntax sugar
/** NOT 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, "One");
String firstElement = list[0];
map[1] = "One";
7. Language Support
for JSR 292
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, "Merhaba");
// 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
• ParallelArray<T> is ideal candidate for
extension methods
• Can utilize efficiently multi-core /
multiprocessor systems
• 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)
JSR 203:
More New I/O APIs for the
Java Platform (NIO.2)
NIO2 – Introduction
• New I/O or non-blocking I/O, usually
called NIO
• Collection of Java 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
Cool New Things: resolve()
• resolve() – resolves a relative path
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() – makes path relative
public static void relativize() {
FileSystem fileSystem = FileSystems.getDefault();
Path source = fileSystem.getPath(".");
Path temp = fileSystem.getPath("/temp");
Path relativeSource =
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 the streams "to" and "from"
• Familiar?
• Most developers write this incorrectly
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();
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?
Compressed 64-bit
Object Pointers
What is an oop?
• An "oop", or "ordinary object pointer" in the
JVM is a managed object pointer
• It is normally the same size as a native
machine pointer
• 64 bits on an 64-bit OS
• 32 bits on an 32-bit OS
• 32-bit JVM can address less than 4GB
• 64-bit JVM can address all the available RAM
• But this costs a lot of memory lost in oops
Compressed oops
• Compressed oops allow to address up to 32
GB RAM with 32-bit pointers
• The address space is mapped using a 64-bit
base and 32-bit oop
• This allows applications to address up to four
billion objects (not bytes)
• Java heap can grow up to 32 GB
Garbage-First GC
Garbage-First GC (G1)
• G1 (garbage-first) garbage collector
• Improved performance and less freeze time
• Server-style garbage collector
• Targeted for multi-processors with large
• Meets a soft real-time goal with high
• Added in Milestone1 (02.01.2009)
• Released in Java 6 update 6u14
Method to close a
• URLClassLoader has new method called
/** @since 1.7 */
• since b48 of JDK 7
• Closes any JAR files that were open by the
• Allows the application to delete/replace these
files and if necessary to create new loaders
• Invalidates the loader, so that no new classes
can be loaded from it
Unicode 5.1
Unicode 5.1 in Java 7
• 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
(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 – 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 – NIO2
• Java New I/O
• JSR 203: The Open Road – java.nio.file
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 – Upgrade
ClassLoader Architecture
• Draft Proposal for ClassLoader Deadlock Fix
• http:[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 – SCTP
• SCTP Project
Resources – SDP
• Understanding the Sockets Direct Protocol
• Sockets Direct Protocol – Wikipedia
• Remote Direct Memory Access
• Zero-copy
Resources – Authors
• Authors of this presentation:
• Svetlin Nakov
• Mihail Stoynov

similar documents