Java SE 7: The Platform Evolves · Java SE 7: The Platform Evolves Scott Seighman Principal Sales Consultant. This presentation will give you an overview of the new features being
70
Java SE 7: The Platform Evolves Scott Seighman Principal Sales Consultant
Java SE 7: The Platform EvolvesScott SeighmanPrincipal Sales Consultant
Presenter
Presentation Notes
This presentation will give you an overview of the new features being included in Java SE 7 and how they will help in the development of new Java applications. The goal is to make developers more productive, applications more robust and with better performance.
2
Priorities for the Java Platforms
Grow Developer Base
Grow Adoption
Increase Competitiveness
Adapt to change
Presenter
Presentation Notes
Since acquiring Sun Micrososystems, Oracle have determined a set of priorities for Java. Java is the most populsar programming language in the workd today (based on reports from people like IDC as well as more anecdotal evidence like the TIOBE programming community index – Java is still number one as of June 2011). The goal is to continue to increase the number of developers who’s primary development language is Java. Having more developers should hopefully lead to greater adoption of Java for applications. Just as important are the competitiveness of Java in terms of performance and ROI compared to other languages. For these top three things to happen Java cannot stay static and so it is important that Java adapts to changes in both the types of applications being developed as well as how they are deployed (the fork-join framework is a good example of how Java is adapting to the greater prevalence of multi-core and multi-CPU machines).
3
Java Communities
Presenter
Presentation Notes
Java is not just about one compnay; there is a thriving community that has grown around this, as proved by the large number of JUGs using this presentation to educate developers about how Java SE 7 can help them. There are many areas to the Java community from open source projects like NetBeans, Eclipse and OpenJDK to Java user groups, Java champions and the Java community process.
Community Development of Java Technology Specifications
Presenter
Presentation Notes
Oracle is commited to the JCP and has successfully made changes that have now alllowed new JSRs to be filed and to start moving forward in a timely manner. The idea of the JCP is to involve companies and individuals who have investment in Java technology in how the platform evolves.
5
JCP Reforms
• Developers’ voice in the Executive Committee• SOUJava• Goldman Sachs• London JavaCommunity• Alex Terrazas
• JCP starting a program of reform• JSR 348: Towards a new version of the JCP
Presenter
Presentation Notes
To reform the JCP a number of changes have started taking place. Firstly new members have been elected to the Executive committee SouJava, the largest Java User Group in Brazil, Goldman Sachs to help represent the financial community who are very large users of Java, The London Java Community and Alex Terrazas who is filling the empty space on the Java ME executive committee JSR348 will define how the JCP will make improvements in areas of transparency (all discussions through publically accessible mailing lists), participation, agility and governance.
6
Evolving the Language From “Evolving the Java Language” - JavaOne 2005• Java language principles
– Reading is more important than writing– Code should be a joy to read– The language should not hide what is happening– Code should do what it seems to do– Simplicity matters– Every “good” feature adds more “bad” weight– Sometimes it is best to leave things out
• One language: with the same meaning everywhere• No dialects
• We will evolve the Java language• But cautiously, with a long term view• “first do no harm” also “Growing a Language” - Guy Steele 1999
“The Feel of Java” - James Gosling 1997
Presenter
Presentation Notes
What is really important to note here is that we are using a slide from JavaOne 2005, this means that from the beginning we have been following the same principles and we are committed to continue to follow these principles as we evolve the language. - We want the code to be easy to read. - The language won't hide anything, and it should do what it seems to do - Even if there are great ideas and features, we are very careful deciding if that feature should be included in the language, some good features add so much weight, it's actually better to leave it out of the language. Again, we are committed to evolved the language, but very cautiously, we want java to be around for very long time.
7
So you want to change the language?
Presenter
Presentation Notes
We always get the questions from developers: Why don't we add this cool feature into the language? Well, even the smallest change will require a LOT of work, and this is just the list of things that need to be updated to cope with changes in the language, no matter how small they are.
8
Java SE 7 Release Contents
• Java Language• Project Coin (JSR-334)
• Class Libraries• NIO2 (JSR-203)• Fork-Join framework, ParallelArray (JSR-166y)
• Miscellaneous things• JSR-336: Java SE 7 Release Contents
Presenter
Presentation Notes
This slide show the contents for Java SE 7, and we will go through each of this topics on a separate section, so here is just the list. JSR-336 is called an umbrella JSR and provides the complete set of features that are included in Java SE 7, even though several components have their own JSR
9
AnnouncingJava 7
Project Coin
coin, n. A piece of small changecoin, v. To create new language
10
Project Coin Constraints
• Small language changes• Small in specification, implementation, testing• No new keywords!• Wary of type system changes
• Coordinate with larger language changes• Project Lambda• Modularity
• One language, one javac
Presenter
Presentation Notes
From the list of proposals, we selected not only the good ones, but the ones that involve small language changes. By small language changes we mean: small in specification, implementation and testing. We didn't allow any new keywords, that will conflict with the language. The project coin hasn't been an isolated project, as we've evolved it we've coordinated with other projects like lambda and modularity, making sure what we include today, will be optimal in the future when all these projects became available.
11
Better Integer Literal
• Binary literals
• With underscores for clarity
int mask = 0b101010101010;
int mask = 0b1010_1010_1010;long big = 9_223_783_036_967_937L;
Presenter
Presentation Notes
Finally we have support for binary literals, and also support for underscores, that allow you to group together, and make it easier to read the literals.
12
String Switch Statement
• Today case label includes integer constants and enum constants
• Strings are constants too (immutable)
Presenter
Presentation Notes
Before Java SE 7, you can only use integer constants and enum constants in the case of the switch statement. Now with JDK 7 you can also have String, as they are also constants.
This is an example pre Java SE 7. In this code, the monthNameToDays method has two parameters, a string representing a month, and an int for the year. The method will return an int representing the number of days that month has in that particular year. Because it was not possible to use string in switch statements, we ended up with a bunch of if statements, plus a bunch of comparison for the months, using the method equals from the String class. Long, ugly and easy to make mistakes!!!!
14
Strings in Switch Statementsint monthNameToDays(String s, int year) {
switch(s) {case "April": case "June":case "September": case "November":
return 30;
case "January": case "March":case "May": case "July":case "August": case "December":
return 31;
case "February”:...
default:...
Presenter
Presentation Notes
This example shows the monthNameToDays method using the JDK 7, where you can use the string in the switch statement, making your code, smaller, clearer, and easier to read.
15
Simplifying Generics
• Pre-generics•List strList = new ArrayList();
Presenter
Presentation Notes
Now, lets have a look at a different topic, Generic. Lets go back in time, before the JDK 5, before we have generics, when we created collections without specifying the type for the elements stored in that collection.
16
Simplifying Generics
• Pre-generics•List strList = new ArrayList();
• With Generics
List<String> strList = new ArrayList<String>();
Presenter
Presentation Notes
Then, Java SE 5.0 introduced generics, where you specify the type for the elements been store by the collection, this is great as it provides compile-time type safety. The problem is that you have to specify that type in both sides of the declaration. It's not big deal if the declaration is as simple as list of Strings, but if you have a collection holding a collection holding another collection, the code can get quite long and confusing as it's showed in the next slide.
17
Simplifying Generics
• Pre-generics•List strList = new ArrayList();
• With Generics
List<String> strList = new ArrayList<String>();List<Map<String, List<String>> strList =
new ArrayList<Map<String, List<String>>();
Presenter
Presentation Notes
This slide shows how long the declaration can became using generics, specially when you have nested collections.
18
Diamond Operator
• Pre-GenericsList strList = new ArrayList();
• With Generics
• With diamond (<>) compiler infers type
List<String> strList = new ArrayList<String>();List<Map<String, List<String>> strList =new ArrayList<Map<String, List<String>>();
List<String> strList = new ArrayList<>();List<Map<String, List<String>> strList =new ArrayList<>();
Presenter
Presentation Notes
JDK 7 introduce the diamond operator, now you only need to specify once the type of elements been hold by the collection, on the left hand side, the rest is taking care for you, as java will “infer” the type that will go on the right hand side. This is more complex than just having the compiler perform string substitution. For certain cases the type to be inserted is not represented by the string in the variable declaration (wildcards are a good example). The compiler must infer the type parameter for the instantiation from the type parameter of the variable declaration.
19
Copying a File
InputStream in = new FileInputStream(src);OutputStream out = new FileOutputStream(dest);
byte[] buf = new byte[8192];int n;
while (n = in.read(buf)) >= 0)out.write(buf, 0, n);
Presenter
Presentation Notes
Lets move into a different area, the Automatic resource managements. First lets study this code. We have two streams, one for reading data (in), and one for writing data (out) The code will read from the in stream and write what is read into out stream.
20
Copying a File (Better, but wrong)
InputStream in = new FileInputStream(src);OutputStream out = new FileOutputStream(dest);
The first issue that we have with the previous slide, is that when you use resources you need to make sure you close them after you finish. If there is any exception reading from or writing to them, you should be able to still close the streams. This code here is a bit better, but we still haven't got it perfect. Lets imagine you get an exception reading from in stream, then you will be sent to the finally clause. Great, that sounds perfect, but lets imagine that when you are executing the finally close, again you get an exception when you try to close the in stream, then the code will never close the out stream, not good.
21
Copying a File (Correct, but complex)
InputStream in = new FileInputStream(src);try {
OutputStream out = new FileOutputStream(dest);try {
Then the solution will be to use two different try blocks. In one finally block we close the out stream, and in the second one we close the in stream. The code looks good, but a bit complex. When you have a longer and more complex code, it's very easy to forget to close the resources properly.
22
Copying a File (Correct, but complex)
InputStream in = new FileInputStream(src);try {
OutputStream out = new FileOutputStream(dest);try {
Even if the code looks correct, we can be loosing very important information about the exceptions. Lets imagine you got really unlucky today, and when the execution started you got the first exception trying to write on the out stream. Execution will jump to the first finally block, where the out steam will be close. Again, remember you are really unlucky today, and this close method call generate a second exception, then you will be thrown to the second finally block. This seems to be ok, the problem that we are facing is lost of information. As it's today, we only store information about the last occurred exception, meaning at this point we already forgot there was an exception trying to write to the stream, and usually the first exception is the most important and meaningful one. Now in the second finally close we get a third exception, one more time the new exception will erase any previous information, now we only know there was an exception when trying to close the in stream.
23
Automatic Resource Management
try (InputStream in = new FileInputStream(src),OutputStream out = new FileOutputStream(dest))
JDK 7 introduce a solution for the issues presented in the previous slides, the automatic resource management. Now you don't have to worry about closing your resources, they will be automatically closed when the try block finish execution. Please note the new definition of the try block, where you include the resources to be managed.
24
The Details
• Compiler desugars try-with-resources into nested try- finally blocks with variables to track exception state
• Suppressed exceptions are recorded for posterity using a new facility of Throwable
• API support in JDK 7• New superinterface java.lang.AutoCloseable• All AutoCloseable and by extension java.io.Closeable
types useable with try-with-resources• anything with a void close() method is a candidate• JDBC 4.1 retrofitted as AutoCloseable too
Presenter
Presentation Notes
To summarize: - Compiler will track the resources, and make sure everything gets close properly. - Suppresed exceptions are recorded, so you will have a full details (as shown in the next slide) - Of course this wont happen by magic, there is a new interface, the AutoClosable interface, any resources that want to be auto managed should implement this interface.
25
More Informative Backtraces
java.io.IOExceptionat Suppress.write(Suppress.java:19) at Suppress.main(Suppress.java:8) Suppressed: java.io.IOException
at Suppress.close(Suppress.java:24)at Suppress.main(Suppress.java:9)
Suppressed: java.io.IOExceptionat Suppress.close(Suppress.java:24) at Suppress.main(Suppress.java:9)
Presenter
Presentation Notes
With automatic resource management even though there are potentially several levels of nesting for the finally clauses that are not immediately visible the full trace of the exceptions that were thrown will be reported.
When you are dealing with code that may throw exceptions you need to catch all of them in a catch block. Until the JDK 6 there was no way to group exceptions, and share common code, and you ended up with a big list of catch blocks as shown in this slide
Now with JDK 7 you can group under the same catch, several exceptions using the “|' operand. Simpler, cleaner and you can reuse common code.
31
AnnouncingJava 7
Library Changes
• New I/O2 (NIO2)• Concurrency APIs (Fork/Join)
32
Background and Motivation
• Need something better than java.io.File• Doesn't work consistently across platforms• No useful exceptions when a file operation fails• Missing basic operations (file copy, move, ...)• Limited support for symbolic links• Limited support for file attributes, performance issues• No way to plug-in other file system implementations
• Need a new file system API• JSR-203 tasked to define this and more
33
New I/O 2 (NIO2) Libraries
• Original Java I/O APIs presented challenges for developers • Not designed to be extensible• Many methods do not throw exceptions as expected• rename() method works inconsistently• Developers want greater access to file metadata
• Java NIO2 solves these problems
JSR 203
Presenter
Presentation Notes
The existing Java IO APIs are fifteen years old. They were not designed to be extensible so lack features like a service provider interface and pluggability to support different file system features. File systems have moved on considerably in this time. One very big problem is the inconsistent use of exceptions. Many methods in the File class return a boolean to indicate success or failure. If an operation fails there is no way to determine why. The rename method works inconsistently and won’t work across volumes or file systems. Support for links is very platform specific With advances in file system structure many applications need greater access to file system meta-datat and, again this is not possible with java.io. The NIO2 APIs are intended to address these limitations.
34
Java NIO2 Features
•Path is a replacement for File• Biggest impact on developers
• Better directory support• list() method can stream via iterator• Entries can be filtered using regular expressions in API
• Symbolic link support• Asynchronous I/O support•java.nio.file.Filesystem
• interface to a filesystem (FAT, ZFS, Zip archive, network, etc)•java.nio.file.attribute package
• Access to file metadata
Presenter
Presentation Notes
From a developer’s perspective the biggest change will be to replace use of the File object with the Path object. Since File was not designed to be extended it was not possible to add functionality so a new class was required. In many places this can be used in exactly the same way, but there are a few differences that developers will need to be aware of to use this correctly. In the existing IO API reading the contents of a directory blocks until all entries have been retrieved. If you are reading several million file names across a network connection (not unusual today) this can take a very long time. NIO2 now provides support for streaming entries so they can be processed as they arrive. There is also support for filtering as part of the API so that it is easy to list only certain types of file and so on. Symbolic link support is optional and is based on the long standing UNIX semantics. Most of the time the link is treated as a normal file, exceptions to this include the delete operation and WalkFIleTree (although the FOLLOW_LINKS option can be used with this). To provide extensibility the Filesystem class provides an interface to a Filesystem which can be any form of file storage system, for example a ZIP file can be accessed as if it were a filesystem even though it is itself a file on another filesystem. The attribute package provides enhanced access to metadata for files and also solves a longstanding performance problem, namely that every request for an attribute results in a separate stat() call
35
Path Class• Equivalent of java.io.File in the new API
• Immutable• Have methods to access and manipulate Path• Few ways to create a Path
• From Paths and FileSystem
//Make a reference to the pathPath home = Paths.get(“/home/fred”);
//Resolve tmp from /home/fred -> /home/fred/tmpPath tmpPath = home.resolve(“tmp”);
//Create a relative path from tmp -> ..Path relativePath = tmpPath.relativize(home)
File file = relativePath.toFile();
Presenter
Presentation Notes
Although the Path class is a replacement for the File class there are some differences worth noting. Since Path is an interface it cannot be instantiated directly (unlike File which is a class). The Paths class provides a set of factory methods for creating Path objects, but there are also ways to create a Path from another Path. This is logical because a hierarchical filesystem allows a path to be created between two files in a relative way (frequently using .. To indicate moving to the parent). Path supports both absolute paths, i.e. how to access the file from the root of the filesystem and relative paths, i.e. how to access the file relative to the current directory.
36
File Operation – Copy, Move
• File copy is really easy• With fine grain control
• File move is supported• Optional atomic move supported
Finally the most obvious file system operations are supported in a clean consistent way in Java. Copying, moving and renaming files is all performed using a Path for each part of the operation. Three copy options can also be specified to copy the attributes of the file rather than using the defaults, to replace an existing file if one already exists at the destination path and to make the move an atomic operation from the filesystem perspective. The Files class provides a large number of utility methods for typical filesystem operations (copy, move, delete, createDirectory and so on).
37
Directories
• DirectoryStream iterate over entries• Scales to large directories• Uses less resources• Smooth out response time for remote file systems• Implements Iterable and Closeable for productivity
• Filtering support• Build-in support for glob, regex and custom filters
Path srcPath = Paths.get(“/home/fred/src”);
try (DirectoryStream<Path> dir = srcPath.newDirectoryStream(“*.java”)) {
for (Path file: dir)System.out.println(file.getName());
}
Presenter
Presentation Notes
The DirectoryStream class provides an iterator that can be used to read entries from a directory. One point of note is that, as the DirectoryStream provides an Iterator, it is not possible to use the DirectoryStream more than once, since there is no way to reset an Iterator,. There is built in support for regular expressions so complex patterns can be used like *.{c,h,cpp,hpp,java}
38
File Change Notification
• Watch files and directories for changes• Typically done by polling• Scanning directories, checking file timestamps, ...
• WatchService• Watches registered objects for events• Makes use of native event notification facility where possible• All providers required to support monitoring of directories
• Events when files are created, deleted, or modified• Extendable to other objects and events
39
Service Provider Interface
• FileSystemProvider is the factory for FileSystem instances
• Develop and deploy custom file system implementations• Deploy as JAR file on class path or in extensions
directory
• ZIP file system• Example provider included in the JDK 7 demos• Treats contents of zip or JAR file as a file system
40
Concurrency APIs
• JSR166y• Update to JSR166x which was an update to JSR166
• Adds a lightweight task framework• Also referred to as Fork/Join
• Thread Pool improvements (Doug Lea)• Scalability, performance
•Phaser• Reusable synchronization barrier• Barrier similar to CyclicBarrier and CountDownLatch
•TransferQueue interface• Extension to BlockingQueue• Implemented by LinkedTransferQueue
Presenter
Presentation Notes
Java SE 7 includes updates to the concurrency APIs first introduced in Java SE 5. This is an update to an update the original utilities were defined in JSR166. This was extended in JSR166x (Java SE 6) and extended further through JSR166y (Java SE 7). Introduces the fork-join framework for fine grained parallelism The Phaser which is a reusable synchronization barrier, similar in functionality to CyclicBarrier and CountDownLatch but supporting more flexible usage. A TransferQueue is a BlockingQueue in which producers may wait for consumers to receive elements. A TransferQueue may be useful for example in message passing applications in which producers sometimes (using method transfer(E)) await receipt of elements by consumers invoking take or poll, while at other times enqueue elements (via method put) without waiting for receipt. Non-blocking and time-out versions of tryTransfer are also available. A TransferQueue may also be queried, via hasWaitingConsumer(), whether there are any threads waiting for items, which is a converse analogy to a peek operation. Like other blocking queues, a TransferQueue may be capacity bounded. If so, an attempted transfer operation may initially block waiting for available space, and/or subsequently block waiting for reception by a consumer. Note that in a queue with zero capacity, such as SynchronousQueue, put and transfer are effectively synonymous. This is implemented by the LinkedTransferQuue which is an unbounded TransferQueue based on linked nodes. This queue orders elements FIFO (first-in-first-out) with respect to any given producer. The head of the queue is that element that has been on the queue the longest time for some producer. The tail of the queue is that element that has been on the queue the shortest time for some producer.
41
1970 1975 1980 1985 1990 1995 2000 2005 2010
1
10
100
1,000
10,000
1,000,000
100,000
10,000000
Clock (MHz)
Transistors (1,000s)
42
Niagara 1 (2005)8 x 4 = 32
Niagara 2 (2007)8 x 8 = 64
Rainbow Falls16 x 8 = 128
43
Trends
• One core - Threads were for asynchrony, not parallelism
• Some cores - Coarse-grained parallelism usually enough• Application-level requests were good task boundaries• Thread pools were a reasonable scheduling mechanism
• Many cores - Coarse-grained parallelism insufficient• Application-level requests won’t keep cores busy• Shared work queues become a bottleneck
Need to find finer-grained, CPU-intensive parallelism
44
The key challenges for multicore code
(1) Decompose problems into parallelizable work units(2) Continue to meet (1) as the number of cores
increases
45
Divide and Conquer
46
Fork Join Framework• Goal is to take advantage of multiple processor• Implementation of ExecutorService interface• Designed for task that can be broken down into
smaller pieces• Eg. Fibonacci number fib(10) = fib(9) + fib(8)
• Pseudo code: if I can manage the task
perform the taskelse
fork task into x number of smaller/similar taskjoin the results
Presenter
Presentation Notes
The fork-join framework is designed for fine grained tasks where a large task can easily be broken up into a large number of sub-tasks. This is best suited to sub-tasks that do not rely on shared, mutatable data. The framework will work well with shared, read-only data, but if multiple subtasks are trying to modify shared data the issues of locking and contention reduce the frameworks overall efficiency.
47
Key Classes• ForkJoinPool
• Executor service for running ForkJoinTask• ForkJoinTask
• The base class for forkjoin task• RecursiveAction
• A subclass of ForkJoinTask• A recursive resultless task• Implements compute() abstract method to perform
calculation• RecursiveTask
• Similar to RecursiveAction but returns a result
Presenter
Presentation Notes
The main classes for the Fork Join framework: ForkJoinPool – Creates a pool of worker threads to execute the tasks. ForkJoinTask – a task to be processed RecursiveAction – A recursively decomposable task that does not return a result RecursiveTask – A recursively decomposable task that does return a value
48
ForkJoin Example – Fibonaccipublic class Fibonacci extends RecursiveTask<Integer> {
private final int number;public Fibonacci(int n) { number = n; }
Fibonacci f1 = new Fibonacci(number – 1);Fibonacci f2 = new Fibonacci(number – 2);f1.fork(); f2.fork();return (f1.join() + f2.join());
} }
}
Presenter
Presentation Notes
This example shows the calculation of Fibonacci sequence value using the FJ framework. The class extends the RecursiveTask class with a generic type parameter of Integer to show that the result generated will be of type Integer. The class overrides the compute method which will be called by the framework to generate the result. In the case where the number is not zero or one the task is forked into two subtasks which are added together to produce the result. The calls to join will block until a result is available.
49
ForkJoin Example – Fibonacci
ForkJoinPool pool = new ForkJoinPool();Fibonacci r = new Fibonacci(10);pool.submit(r);
while (!r.isDone()) {//Do some work ...
}
System.out.println("Result of fib(10) = "+ r.get());
Presenter
Presentation Notes
Here we create a new ForkJoinPool to process the Fibonacci calculation. We instantiate the initial task to calculate the 10th Fibonacci value and submit this to the pool of worker threads. We can continue to work in parallel with this checking for when the task is completed using the isDone method. The result is provided as a Future so we use the get method to retrieve the result. Alternatively we could simply call get once we’ve submitted the task and this would block until the task was complete. Notice that none of this code reuies any direct manipulation of either threads or locks. This is all handled by the framework
50
Fork/Join and Thresholds
• Determines whether a task will execute a sequential computation rather than forking parallel sub-tasks.
• If the threshold is too large:• Program might not create enough tasks to fully take
advantage of the available processors/cores.
• If the threshold is too small:• Overhead of task creation and management could become
significant.
• In general, some experimentation will be necessary to find an appropriate threshold value.• Profiling
51
Fork/Join and Thresholds
• In general, some experimentation will be necessary to find an appropriate threshold value.• Profiling
52
Fork/Join Performance Considerations
• The fork/join framework minimizes per-task overhead for compute-intensive tasks• Not recommended for tasks that mix CPU and I/O activity
• A portable way to express many parallel algorithms• Code is independent of execution topology• Reasonably efficient for a wide range of core counts• Library-managed parallelism
53
Client Libraries
• Nimbus Look and Feel• Platform APIs for shaped and translucent windows• JLayer (formerly from Swing labs)• Optimized 2D rendering
Presenter
Presentation Notes
Java SE 7 als includes some updates to the client libraries.
54
Nimbus Look and Feel
• Better than Metal for cross platform look-and-feel• Introduced in Java SE 6u10, now part of Swing• Not the default L&F
Presenter
Presentation Notes
The Nimbus look and feel was introduced in Java SE 6 update 10 as a replacement for the metal cross platform L&F. In Java SE 7 this has been moved to a standard part of the platform (previously it was an oracle extension package, now it is in the javax.swing.plaf package). The decision was made not to make this the default L&F, this will continue to be Metal. Although many people in the community wanted this it was decided that the impact on existing applications would be too great.
55
JLayer component Easy enrichment for Swing components
Presenter
Presentation Notes
The Jlayer component provides an easy way to add an overlay to existing Swing components. Examples are a progress wheel or highlighting only valid choices in a multiple-choice component.
56
JLayer component The universal decorator
• Transparent decorator for a Swing component• Controls the painting of its subcomponents• Catches all input and focus events for the whole hierarchy
// wrap your component with JLayerJLayer<JPanel> layer = new JLayer<JPanel>(panel);
// custom ui provides all extra functionalitylayer.setUI(myLayerUI);
// add the layer as usual componentframe.add(layer);
Presenter
Presentation Notes
The Jlayer can intercept all input and focus events so it appears to the user as that component for interaction. Here we create a new Jlayer for a previously instantiated Jpanel component. A custom component, myLayerUI, is then added to the layer so that it will provide the extra functionality. The layer is then added to a Frame which will add both the underlying Jpanel and the custom UI.
57
The DaVinci Machine Project (JSR-292) (A multi-language renaissance for the JVM)
Better
Presenter
Presentation Notes
Lets talk about the changes being made in the JVM In Java SE 7
58
Languages Like Virtual Machines
• Programming languages need runtime support• Memory management / Garbage collection• Concurrency control• Security• Reflection• Debugging integration• Standard libraries
• Compiler writers have to build these from scratch• Targeting a VM allows reuse of infrastructure
Presenter
Presentation Notes
Programming languages have proliferated over that last few years as people have come up with more and more ideas for how best to approach solving different types of problem in the most effective way. This is referred to as domain specific languages (DSLs). As a compiler writer there are a variety of tasks that are common to many languages; how to manage memory for storage of intermediate results, how to manage concurrent execution of code, security, and so on. Since many virtual machines already provide these features targeting a language at a VM makes life a lot easier for compiler writers and for developers it gives them access to a large set of existing libraries for everyday tasks. Since the JVM has been developed over 15 years many bugs have already been eliminated and performance has been extensively tuned.
59
JVM Specification
“The Java virtual machine knows nothing about the Java programming language, only of a particular binary
format, the class file format.”
1.2 The Java Virtual Machine Spec.
Presenter
Presentation Notes
The Java Virtual Machine perspective clearly states that the JVM has no knowledge of Java the language. It understands the Java bytecodes and, provided it is handed a valid set of bytecodes, will execute them, regardless of how they were generated, This makes the job of compiling from languages other than Java much easier. However, even though the JVM does not know about the Java language it was designed with Java in mind. As such it was built to support a language that uses single inheritance, static typing and does not have support for explicit pointers. This doesn’t mean you can’t compile a dynamically typed language to bytecodes, but it doesn’t make the job harder.
60
Languages Running on the JVM
Clojure
Tcl
JavaScript
v-language
CAL
Sather
Funnel
MiniPLAN
Lisp
Scheme
Basic
Logo JHCR
TermWare
Drools
Prolog
LLP
JESS
Eiffel
Smalltalk
C#
G
GroovyNice
Anvil
Hojo
Correlate
Ada
Bex Script
Tea
PHP
Phobos Sleep
FScript
JudoScript
JRuby
ObjectScript
Jickle
Yoix
Simkin
BeanShell
DawnWebL
iScript
Jython
Pnuts
Yassl
Forth
PiccolaSALSA
Processing
Zigzag
Tiger
Tiger
IconPascal
Oberon
Modula-2
Luck
E
Rexx JavaFX Script Scala
Presenter
Presentation Notes
As we can see the result is that many people have written compilers that will take all sorts of languages and created compilers for them; you can see functional languages, dynamically typed languages, list based languages and so on.
61
What slows down a JVM …
• Non-Java languages require special call sites.• Example: Smalltalk message sending (no static types).• Example: JavaScript or Ruby method call (different lookup
rules)
• In the past, special calls required simulation overheads• such as reflection and/or extra levels of lookup and indirection• which have inhibited JIT optimizations.
• Result: Pain for non-Java developers.• Enter Java 7
62
Passing the burden to the JVM
• Now, invokedynamic call sites are fully user- configurable• ...and are fully optimizable by the JIT.
• Result: Much simpler code for language implementors• ...and new leverage for the JIT.
63
Key Features of invokeDynamic
• New bytecode instruction: invokedynamic.• Linked reflectively, under user control.• User-visible object: java.lang.invoke.CallSite• Dynamic call sites can be linked and relinked, dynamically
• New unit of behavior: method handle• The content of a dynamic call site is a method handle.• Method handles are function pointers for the JVM.
(Or if you like, each MH implements a single-method interface.)
• Now, invokedynamic call sites are fully user-configurable• A fully optimizable by the JIT.
• Result: Much simpler code for language implementors• New leverage for the JIT.
64
InvokeDynamic Bytecode
• JVM currently has four ways to invoke method• Invokevirtual, invokeinterface, invokestatic, invokespecial
• All require full method signature data• InvokeDynamic will use method handle
• Effectively an indirect pointer to the method
• When dynamic method is first called bootstrap code determines method and creates handle
• Subsequent calls simply reference defined handle• Type changes force a re-compute of the method
location and an update to the handle• Method call changes are invisible to calling code
Presenter
Presentation Notes
The biggest issue for dynamically typed languages running on the JVM is performance, specifically of how method calls get made. Since Java was designed with static typing it is possible to resolve methods at compile time and include the reference directly in the code (dynamic class loading might seem like an issue, but the new class is still static in its references). The JVM has four ways to invoke a method; most calls will go through invokevirtual. For interfaces invokeinterface is used, static methods use invokestatic and constructors are called by invokespecial. Since these all required a full method signature compiler writers for dynamically typed languages must resolve the reference every time a method is called in case a type involved in the call has changed. To make life easier we are including the first new bytecode in the JVM instruction set since it was launched. This is called InvokeDynamic and will not be used by Java (at least not until Java SE 8). The basic idea is that when a method is first called bootstrap code will resolve the reference and store a method handle in a callsite (effectively a function pointer). Subsequent calls to the method will find there is already a method handle and call the method through the callsite. If a type involved in the method signature changes the compiled code can detect this, resolve the method based on the new signature and store the changed reference in the call site. Therefore the method only needs to be resolved when changes are made not every time the method is called. This is much more efficient.
65
CallSite and MethodHandle• invokedynamic linked to a CallSite
• CallSite can be linked or unlinked• CallSite holder of MethodHandle
• MethodHandle is a directly executable reference to an underlying method, constructor, field• Can transform arguments and return type• Transformation – conversion, insertion, deletion, substitution
Presenter
Presentation Notes
This provides a bit more detail. The method handle is the way the method or constructor can be executed. For dynamically typed languages manipulation of the method handle and callsite is more efficinet in many cases by a factor of 10
66
More details about method handles
• A direct method handle points to a Java method.• A DMH can emulate any of the pre-existing invoke
instructions.• A bound method handle includes an saved argument.
• The bound argument is specified on creation, and is used on call.
• The bound argument is inserted into the argument list.• Any MH can be be bound, and the binding is invisible to
callers.• An adapter method handle adjusts values on the fly.
• Both argument and return values can be adjusted.• Adaptations include cast, box/unbox, collect/spread, filter, etc.• Any MH can be adapted. Adaptation is invisible to callers.
68
Miscellaneous Things
• Security• Eliptic curve cryptography• TLS 1.2
• JAXP 1.4.4• JAX-WS 2.2• JAXB 2.2• SCTP, SDP Support• XToolkit is default (Motif no longer supported)• ClassLoader architecture changes•close() for URLClassLoader• Javadoc support for CSS
Presenter
Presentation Notes
Here are a few miscellaneous things that don’t fit into the preceeding areas. Some minor changes to cryptography in terms of the underlying algorithm used. Various updates to Java APIs defined in other JSRs Some minor changes to class loading which will only have an impact on a very small number of developers. Finally! Javadocs get CSS support so we can bring javadocs into the 21st Century.
69
JDK 7 Platform Support
• Windows x86• Server 2008, Server 2008 R2, 7 & 8 (when it GAs)• Windows Vista, XP
• Linux x86• Oracle Linux 5.5+, 6.x• Red Hat Enterprise Linux 5.5+, 6.x• SuSE Linux Enterprise Server 10.x, 11.x• Ubuntu Linux 10.04 LTS, 11.04
• Solaris x86/SPARC• Solaris 10.9+, 11.x
• Apple OSX x86• will be supported post-GA, detailed plan TBD
• Note: JDK 7 should run on pretty much any Windows/Linux/Solaris. These configurations are the ones primarily tested by Oracle, and for which we provide commercial support.
Presenter
Presentation Notes
Your takeaway from this slide is that Java will be available on the plaforms you expect it to. Java 7 for the Mac will not be done by the time we release JDK7, but we are working on getting it back to the mac as soon as possible.
• Hotspot 21• Java SE 7 Support• Rebranding• Improved JMX
Agent• Command line
servicability tool (jrcmd)
--- Premium ---• Improved JRockit
Mission Control Console support
JDK 7 GA – 07/11
• Hotspot 22• Performance• Enable large heaps
with reasonable latencies
JDK 7u2
• Hotspot 23• More performance• Improved command
line servicability (jcmd)
• Enable large heaps with consistent reasonable latencies
• No PermGen
--- Premium ---• Complete JRockit
Flight Recorder Support
JDK 7uX
• Hotspot24• Java SE 8 Support• All performance
features from JRockit ported
• All servicability features from JRockit ported• Compiler
controls• Verbose logging--- Premium ---
• JRockit Mission Control Memleak Tool Support
• Soft Real Time GC
JDK 8 GA
Presenter
Presentation Notes
We will ”converge” by moving and re-implementing the missing goodies from JRockit into the Hotspot codebase. Most of those changes will go into the OpenJDK, but some will remain premium features. E.g, JRockit Mission Control. Once all of the features are moved, we will prounce the convergence complete. Well, in all honesty, we will probably make a bigger deal than that from it, but it sounds less dramatic when you know how its done. Hopefully, the convergence will be completed by JDK 8 GA, but I’m making no promises today.
71
More Project CoinSmall Language Changes
Project Lambda (JSR 335)Closures and lambda expressions Better support for multi-core processors
Project Jigsaw (JSR-294)Modularizing the Java Platform
Java SE 8
Presenter
Presentation Notes
Here’s a very quick look at the major features being proposed for Java SE 8 Project Jigsaw will bring true modularity to the Java platform and applications. The idea is to move away from jar files and their limitations and support things like versioning and simplified inter-dependency definitions. Project Lambda will bring closure-like support to Java in the form of lambda expressions. This is a replacement for single abstract method classes which are used frequently in Java and anonymous inner classes. This will also build on the fork-join framework to provide ParallelArray functionality to enhance support for multi-processor/core machines. There will also be more small language changes in the form of an extension to project Coin. There are no details of what these changes will be at this time.
72
Conclusions
• Java SE 7• Incremental changes• Evolutionary, not revolutionary• Good solid set of features to make developers life easier
• Java SE 8• Major new features: Modularisation and Closures• More smaller features to be defined
• Java continues to grow and adapt to the changing world of IT
Presenter
Presentation Notes
To conclude we can see that Java SE 7 is an incremental change over Java SE 6 providing evolutionary, not revolutionary new features. The changes that are included provide a good, solid set of enhancements to make developers lives easier whilst not affecting backwards compatability. Support for things like the fork-join framework will enable applications to benefot from developments in hardware without having to write complex code. Java SE 8 which we only covered very briefly will introduce more substantial features that will help Java developers to be even more productive. The important thing to get from this presentation is that Java is not “the new Cobol”. It is adapting to the needs of developers and new types of applications and platforms.
73
The preceding is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.
Presenter
Presentation Notes
This is the standard Oracle safe-harbour statement. Please allow the audience to read this in their own time.
