Skip to content

Latest commit

 

History

History
227 lines (218 loc) · 9.23 KB

README.md

File metadata and controls

227 lines (218 loc) · 9.23 KB

License: GPL v3

java-incubator-projects

preface

  • the goal of this paper is to show main java incubator projects
  • note that this paper is not updated on a daily manner, so don't hold your breath
  • up-to-date: 11.11.2020

project amber

  • https://openjdk.java.net/projects/amber/
  • explore and incubate smaller, productivity-oriented Java language features that have been accepted as candidate JEPs under the OpenJDK JEP process
  • adapting to rising developer expectations
  • exemplary shipped features
    • diamond operator 
      List<String> list = new ArrayList<>()
    • static methods type inference 
      List<String> empty = Collections.emptyList() // instead of Collections.<String>emptyList()
    • lambda args type inference 
      Predicate<String> isEmpty = s -> s.length() == 0 // instead of (String s) -> s.length() == 0
    • local variable type inference 
      var i = 1;
    • enhanced switch expressions 
      static void howMany(int k) {
    switch (k) {
        case 1  -> System.out.println("one");
        case 2  -> System.out.println("two");
        default -> System.out.println("many");
    }
}
  • incubating
    • record 
      record Point(double x, double y)
      • first-class support for modeling data-only aggregates
        • the state, the whole state and nothing but the state
      • close a possible gap in java's type system
      • language-level syntax for a common pattern
      • reduce class boilerplate
      • something like data in kotlin
    • sealed type
      • defines a closed hierarchy
    • pattern matching
    • smart casts 
      if (obj instanceof String s) {
    // can use s here
} else {
    // can't use s here
}

project loom

  • https://openjdk.java.net/projects/loom/
  • adapting to rising scale expectations
    • threads in java
      • thread scheduling is done by the OS
      • thread stack is pre-reserved
      • so far, one implementation: OS threads
      • OS threads must support all applications in all languages
        • cannot be specialized for the task, are good overall but not specialized
      • task-switching requires switch to kernel
      • ram-heavy - megabyte-scale
      • scheduling is a compromise for all usages
        • bad cache locality
    • many lightweight/virtual threads
      • small number "carrier" heavyweight/kernel threads managed by scheduler
    • the use of Thread.currentThread() and ThreadLocal is pervasive
      • without support, or with changed behaviour - little existing code would run
      • scope locals expected to supplant most used of ThreadLocal
      • since Java 5 we've encouraged people not to use the Thread API directly anyway
        • use Executor and Future, so the baggage and past API mistakes are largely inconspicuous
  • main goal
    • continuations & fibers
  • continuation is the ability to suspend computation and then resume it
    • example 
      public class ContinuationExample {
    public static void main(String[] args) {
        var scope = new ContinuationScope("example");
        var continuation = new Continuation(scope, () -> {
            System.out.println("hello");
            Continuation.yield(scope);
            System.out.println("hello again");
        });
        System.out.println("start continuation");
        continuation.run();
        System.out.println("run it again");
        continuation.run();
    }
}
      will print 
      start continuation
hello
run it again
hello again
    • wraps a runnable
    • Continuation.run() executes the runnable
      • can stop itself with a yield
      • a call to run() will restart the runnable just after the yield
    • yield copy the all stack frames on the heap
      • then run() move some stack frames back
        • when resuming, only thaw a few frames
        • install a return barrier if more frames exists
        • return barrier will thaw a few more frames when hit
    • scheduling explicit (yield, run)
      • no OS context switch
    • no heap reservation
      • only store what is actually needed
  • fiber = continuation + scheduler
    • scheduling is done by application not OS
    • wraps a task in a continuation
      • continuation yields when the task needs to block
      • continuation is continued when the task is ready to continue
    • scheduler using an ExecutorService
      • a fiber is scheduled on the thread
    • blocking calls (read, write, sleep)
      • freeze the fiber, schedule another one
      • re-scheduled
        • when a read/write/locks/etc will not block
        • maybe scheduled on another thread
  • fiber vs continuation
    • fiber delegates the suspension (yield) to the continuation
      • all blocking calls internally a yield
      • the jdk code calls run() on the continuation when it can be rescheduled
  • code like sync, works like async
    • synchronous
      • easy to read
      • fits well with language (control flow, exceptions)
      • fits well with tooling (debuggers, profilers)
      • but
        • costly to create and block
        • a limited resource
    • asynchronous (reactive)
      • scalable
      • but
        • hard to read
        • very hard to debug and profile
        • often obscures business logic
  • structured concurrency
    • core idea: "every time that control splits into multiple concurrent paths, we want to make sure that they join up again"
    • implementation detail: FiberScope 
      FiberScope scope = FiberScope.open();

try {
    Fiber<String> fiber1 = scope.schedule(task1);
    Fiber<String> fiber2 = scope.schedule(task2);
} finally {
    scope.close(); // blocks until fiber1 and fiber2 terminate
}

project panama

  • https://openjdk.java.net/projects/panama/
  • improving and enriching the connections between the Java virtual machine and well-defined but "foreign" (non-Java) APIs
  • better interop with native code and data
  • example for target improvements
    • native function calling from JVM
    • new data layouts in JVM heap
  • "if non-java programmers find some library useful and easy to access it should be similarly accessible to java programmers" John Rose, JVM Architect

project valhalla

  • https://openjdk.java.net/projects/valhalla/
  • adapting to modern hardware
  • every object in java has identity
  • goal: pure data aggregator without identity
    • code like a class, works like int
  • valhalla goals
    • provide denser memory layout (inline/value types)
    • specialized generics (including primitive, value types)
    • pure data aggregator without identity
    • inline classes
    • jvm cleanup
  • why value types?
    • smaller footprint (no object header)
    • better locality (no dereference)
    • simpler semantics (no identity)
    • lowe operational impact (no allocation and GC)

project metropolis

  • https://openjdk.java.net/projects/metropolis/
  • big idea: java-on-java
    • reduce dependency on c/cpp/assembly and rely on self-optimization
    • reduce complexity and cost of maintenance
  • first goal: replace JIT (C2)
    • currently experimenting with GraalVm + SubstrateVM
    • GraalVM already part of the openJDK
  • potentially replace other components in the future

project portola

  • https://openjdk.java.net/projects/portola/
  • java in a world of containers
  • java's characteristics make it ideal for container deployment
    • safe, performant, reliable, rich ecosystem
  • having java remain the first choice for deployments in the cloud
  • main goal: provide a port of the JDK to the Alpine Linux distribution