Topics

Featured in Development

Alex Bradbury gives an overview of the status and development of RISC-V as it relates to modern operating systems, highlighting major research strands, controversies, and opportunities to get involved.

Featured in Architecture & Design

Will Jones talks about how Habito, the leading digital mortgage broker, benefited from using Haskell, some of the wins and trade-offs that have brought it to where it is today and where it's going next. He also talks about why functional programming is beneficial for large projects, and how it helps especially with migrating the data store.

Featured in AI, ML & Data Engineering

Katharine Jarmul discusses research related to fair-and-private ML algorithms and privacy-preserving models, showing that caring about privacy can help ensure a better model overall and support ethics.

Featured in Culture & Methods

This personal experience report shows that political in-house games and bad corporate culture are not only annoying and a waste of time, but also harm a lot of initiatives for improvement. Whenever we become aware of the blame game, we should address it! DevOps wants to deliver high quality. The willingness to make things better - products, processes, collaboration, and more - is vital.

Featured in DevOps

Service mesh architectures enable a control and observability loop. At the moment, service mesh implementations vary in regard to API and technology, and this shows no signs of slowing down. Building on top of volatile APIs can be hazardous. Here we suggest to use a simplified, workflow-friendly API to shield organization platform code from specific service-mesh implementation details.

Mark Reinhold on Java 9 and Beyond

Today at EclipseCon, Mark Reinhold presented the keynote "Java 9 and Beyond" which looked at the upcoming features for Java 9 and future plans for the Java ecosystem.

One of the main changes in Java 9 will be the introduction of the Java Module System, under the JEP200 umbrella. This is intended to provide a modularised JDK and correspondingly smaller amounts of code that needs to be loaded when running applications that don't need the whole environment, or in Mark's words "It should not be necessary to depend on CORBA to print 'Hello World'". The work on modularisng both the Java VM source code layout (JEP201) as well as modularising the individual Java components and the run time images (JEP220) will end up with a number of different distinct modules, of which java.base will be the core layer, with others such as java.logging and java.sql (containing both the java.sql and javax.sql packages) that will depend upon it.

Modules themselves can express dependencies between them, but packages are also exported from modules for the use of others. Due to internal implementation details, some packages (such as sun.reflect.* from the java.base module) are made available to friends (like java.logging and java.sql) although these won't be visible to normal Java code. Dependencies are transitive, so code that depends on java.sql will automatically inherit a dependency on java.logging, in the same way that Eclipse bundles using Require-Bundle operate. Security checks with the java.lang.SecurityManager::checkPackageAccess are performed to ensure that the module boundaries are checked at run-time.

These modularisations mean the removal of the ubiquitous rt.jar (Which replaced Java 1.1's classes.zip) and enable the creation of profiles, to reduce the total footprint of the JVM. The compact1 profile – containing the java.base module with the java.lang package and others – clocks in at around 11Mb of size, with compact2 adding RMI and XML (17Mb) and compact3 adding java.naming, java.management and java.sql (30Mb). The full JRE is still available with a buffet option of 55Mb and the JDK extends that to ~150Mb. The modules have also resulted in the removal of the extension classpath and some reorganisation of the lib path (specifically, the movement of the *.properties files from lib/ to a new directory conf/)

One impact to code is the change of the jar: protocol handler for system classes to the new jrt: protocol (Java Run Time). This will allow classes to be loaded from what was rt.jar by specifying the module. So references like jar:file:/path/to/rt.jar!java/lang/Class.class will become instead jrt:/java.base/java.lang.Class.class. These should be implementation details for callers of the ClassLoader.getSystemResource() which has always returned an opaque URL, but code that assumes a relationship to a JAR file or filesystem will be broken. Tools that navigate the rt.jar (such as IDEs like Eclipse and IntelliJ) will instead have to use a different mechanism to navigate modules; a new FileSystem has been registered so that browsing FileSystem.getFileSystem("jrt:/") will allow a path-based access to list out all modules available and their contents.

These modules will be able to be linked into a single runtime using jlink, a new tool in Java 9 to build a custom image that contains only the required dependencies that can be run. The implication was this would be a static linking option to provide a single executable (like Google's Go produces).

Modularisation finally enables the removal of the *.internal.* and sun.* packages. Although code should never have been using these in the first place, the lack of inter package boundaries has resulted in their use inadvertently in codebases. Classes such as sun.misc.BASE64Encoder and sun.misc.BASE64Decoder should be replaced with their standard counterparts in java.util.Base64.Encoder and java.util.Base64.Decoder. A tool jdeps, available in Java 8, will present dependencies of internal classes on existing files, as well as indicating what modules are used in Java 9.

The (possible) Future

Mark Reinhold also discussed about possible future additions to the JVM, such as value classes (structs) and enhanced generics for value types (such as value classes or primitives). These are not scheduled for inclusion in any future, but the thinking and investigating leads to the possibility of inclusion at some point in the future.

A value class is one that represents fixed structure of data, like a class. Unlike a (reference) class however, the implementation allows for the JVM to optimise the data structure directly on the stack, or in arrays, a contiguous memory layout. This improves the access of data structures and importantly improves performance on CPUs which can load contiguous memory in blocks instead of following an array of pointers elsewehre in the heap. An implementation might look like:

Value classes are final by default, so the data structure needs to be fully initialized at creation time. This allows for the JIT optimisation to pass values through to method calls and not to keep copies around where unnecessary. Value classes can have methods and implement interfaces (and potentially subtype other value classes) but they aren't references, so cannot be compared with null. Value classes could be used to implement other primitive-like types, such as int128, Complex or Tuple.

To realise generics with value classes requires some changes; for example, ArrayList<T> has a remove(int index) and a remove(T value) method. Generifying this with int would result in a method clash and cause problems. Whilst creating a new method removeAt(int index) solves the problem, to allow existing types to continue the existing method (for non value types) needs to be exported. A possible approach is to use conditional compilation, which can be implemented using something like a 'where ref T { }' conditional compilation block that exports code for reference types but not for value types. Project Valhalla is investigating how these two concepts might co-exist in the future, but is at the active research stage at present.

Mark Reinhold also briefly mentioned Project Panama, which aims to improve the performance of Java to Native code calling with the Java Foreign Function Interface proposed in JEP191 based upon JRuby's existing JNA and JNR implementations. He concluded the presentation by saying that Java is evolving, and tacking big issues in measured steps – first generics in Java 5, then lambdas in Java 8 and modularity in Java 9 – with a laser-like focus on backwards compatibility so as not to break existing code or consumers.

Re: Unsafe?

Your message is awaiting moderation. Thank you for participating in the discussion.

Mark specifically mentioned sun.misc.Unsafe as a class they never intended to be public and an example for the need for modules and access restriction. He also mentioned moving and/or reimplementing key components of Unsafe that are being used into a publicly available package like java.util or something similar if/when sun.misc is access controlled.