1 / 141

Mastering Java 7 New Features

Discover the latest advancements in Java 7 with insights on Garbage-First GC, Dynamic Languages, and Project Jigsaw. Get a comprehensive overview and implementation guide for enhanced Java programming.

williamlane
Download Presentation

Mastering Java 7 New Features

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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 www.devbg.org

  2. 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

  3. 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

  4. 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)

  5. Introduction and Chronology

  6. OpenJDK JDK7 is the second JDK done via the OpenJDK effort OpenJDK is free, open-source and GPL licensed 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

  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”

  8. 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 a JSR While doing this presentation we used the term JSR TBD in lieu of the missing JSR

  9. Source Control System Official SCM is SVN, still Note: it takes a 'while' Unofficial Mercurial forest repositories available since November 2007 Note: this also takes a 'while' >svn co https://jdk7.dev.java.net/svn/jdk7/trunk >hg fclone http://hg.openjdk.java.net/

  10. 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 

  11. Compressed 64-bit Object Pointers

  12. What is an oop? An "oop", or "ordinary object pointer" in HotSpot parlance is a managed pointer to an object 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

  13. 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 pointers 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

  14. 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 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 <base> + (<narrow-oop> << 3) + <offset>

  15. 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

  16. 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

  17. Zero Based Compressed oops 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: 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 <oop-base> + (<narrow-oop> << 3) + <field-offset> (<narrow-oop> << 3) + <field-offset> <wide_oop> = <narrow-oop>

  18. Garbage-First GC (G1)

  19. 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 deaths 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

  20. 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 compaction

  21. 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

  22. G1 Additional Facts Garbage-first is a server-style garbage collector Targeted for multi-processors with large memories meets a soft real-time goal with high probability while achieving high throughput Added in Milestone1 (02.01.2009) Released in Java 6 update 6u14 Support contract controversy

  23. Dynamic Languages in JVM

  24. Dynamic Languages in JVM • Da Vinci Machine Project • A.k.a. Multi Language Virtual Machine –http://openjdk.java.net/projects/mlvm/ • 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

  25. 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 – java.dyn.MethodHandle • Anonymous classes in the JVM

  26. 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

  27. 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

  28. Dynamic Invoke – Example staticvoid greeter(String x) { System.out.println("Hello, " + x); } static MethodHandle greeterMethodHandle = MethodHandles.lookup().findStatic( DynamicInvocation.class, "greeter", MethodType. methodType(void.class, String.class)); static { Linkage.registerBootstrapMethod( "bootstrapDynamic"); }

  29. Dynamic Invoke – Example (2) privatestatic 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); site.setTarget(target); System.out.println("Set the CallSite target to " + greeterMethodHandle); return site; } } publicstaticvoid main(String... args) { InvokeDynamic.hail("dynamic invocation"); }

  30. Java Modularity Project Jigsaw

  31. 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 download 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

  32. 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 reworked

  33. 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

  34. 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 language Otherwise the compile-time module environment can differ dramatically from the run-time module environment

  35. 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

  36. 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

  37. 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 M1@1.0 provides M2@2.0, M3@3.0 { requires M4@4.0, M5@5.0; permits M6; // only M6 can depend on M1 } module M; package P; publicclassFoo {...}

  38. JSR 308: Annotations on Java Types

  39. JSR 308 – Introduction Java SE 6 permits annotations only on declarations 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 ElementType.TYPE_PARAMETER

  40. Source Locations for Annotations on Types  A type annotation appears before the type The annotation on a given array level prefixes the brackets that introduce that level The varargs syntax ... is treated analogously to array brackets and may also be prefixed by an annotation @Nonnull String s = ""; publicstaticvoid main(String @NonEmpty ... args) { @English String s @NonEmpty [] = new String[]{""}; }

  41. 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 An annotation on a type parameter declaration appears before the declared name or wildcard public String toString() @Readonly { ... } Map<@NonNull String, @NonEmpty List<@Readonly Document>> f;

  42. JSR 308: More Examples publicstaticvoid 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 { returnnull; } // helper only publicstatic <T> T method(String s) {returnnull;}

  43. Reflection 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 implementations

  44. 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

  45. An Example That Makes Sense @DefaultQualifier("NonNull") 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) neighbors.add(e.to()); return neighbors; } }

  46. Small Language Enhancements (Project Coin)

  47. 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)

  48. 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

  49. 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

  50. 1. Strings in Switch

More Related