1:36 p.m.
Hi Galder,
Since my last message about JDK 9 build b88, a number of new JEPs have
been integrated into JDK 9 b93
available here <https://jdk9.java.net/download/>;. I'd like to point you
to a few that are now available for testing in this JDK 9 Early Access
build:
JEP 254: Compact Strings (http://openjdk.java.net/jeps/254)
This JEP adopts a more space-efficient internal representation for strings.
We propose to change the internal representation of the String class
from a UTF-16 char array to a byte array plus an encoding-flag field.
The new String class will store characters encoded either as
ISO-8859-1/Latin-1 (one byte per character), or as UTF-16 (two bytes per
character), based upon the contents of the string. The encoding flag
will indicate which encoding is used.
JEP 165: Compiler Control (http://openjdk.java.net/jeps/165)
This JEP proposes an improved way to control the JVM compilers. It
enables runtime manageable, method dependent compiler flags. (Immutable
for the duration of a compilation.)
Method-context dependent control of the compilation process is a
powerful tool for writing small contained JVM compiler tests that can be
run without restarting the entire JVM. It is also very useful for
creating workarounds for bugs in the JVM compilers.
JEP 243: Java-Level JVM Compiler Interface
(http://openjdk.java.net/jeps/243)
This JEP instruments the data flows within the JVM which are used by the
JIT compiler to allow Java code to observe, query, and affect the JVM's
compilation process and its associated metadata.
JEP 268: XML Catalog API (http://openjdk.java.net/jeps/268)
This JEP develops a standard XML Catalog API that supports the OASIS XML
Catalogs standard, v1.1. The API will define catalog and
catalog-resolver abstractions which can be used with the JAXP processors
that accept resolvers.
Existing libraries or applications that use the internal API will need
to migrate to the new API in order to take advantage of the new features.
Rgds, Rory
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
2:19 p.m.
On 27/11/2015 13:36, Rory O'Donnell wrote:
JEP 254: Compact Strings (http://openjdk.java.net/jeps/254)
This JEP adopts a more space-efficient internal representation for strings.
We propose to change the internal representation of the String class
from a UTF-16 char array to a byte array plus an encoding-flag field.
The new String class will store characters encoded either as
ISO-8859-1/Latin-1 (one byte per character), or as UTF-16 (two bytes per
character), based upon the contents of the string. The encoding flag
will indicate which encoding is used.
This one sounds very promising, in the context of our last talks.
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
2:23 p.m.
On 27 November 2015 at 13:19, Tristan Tarrant <ttarrant(a)redhat.com> wrote:
On 27/11/2015 13:36, Rory O'Donnell wrote:
> JEP 254: Compact Strings (http://openjdk.java.net/jeps/254)
>
> This JEP adopts a more space-efficient internal representation for strings.
>
> We propose to change the internal representation of the String class
> from a UTF-16 char array to a byte array plus an encoding-flag field.
> The new String class will store characters encoded either as
> ISO-8859-1/Latin-1 (one byte per character), or as UTF-16 (two bytes per
> character), based upon the contents of the string. The encoding flag
> will indicate which encoding is used.
This one sounds very promising, in the context of our last talks.
Yes, but we also need a way to Marshall these efficiently. I haven't
looked yet, but I'd assume we'd need to be able to read that internal
flag somehow, to adjust wire encoding strategies.
Hopefully David will get interested?
Sanne
3123
days inactive
3123
days old
infinispan-dev@lists.jboss.org
2 comments
3 participants
participants (3)
-
Rory O'Donnell -
Sanne Grinovero -
Tristan Tarrant