Java 18 was released on March 22, 2022.
It has four features of interest to XML developers.
- UTF-8 is now the default charset on every platform (except for console IO.) This change may cause old code to break. Deal with it!
- A built-in static webserver. This serves only fixed pages. This is something that developers wanting to create Unit Tests for their code will appreciate, rather than having to supply and configure Jetty or another webserver: it will allow better mocking of microservices in particularly. For XML developers, it will allow better testing of AJAX code, or e.g. XSLTs which pull in external tables using the document() function in XPath. For Schematron, it may make it easier to test where you have external tables or compound documents. It also gives some other choices for packaging e-pub etc documents.
- The Vector API is starting to look more baked. This allows SIMD features, where the CPU can perform the same operation on an array of similar data, 128 or 256 or 512 bytes at a time. In a sense, this is opposite to Java Records, which allow leaner final objects: instead of an array of records of data items, the Vector API works best if you have separate arrays for each distrinct data item (integer, long, double, etc).
Warning: while the Vector API itself is now more settled and full-featured, in the Java 18 release, not all the methods have been implemented by the Java compiler to use vector instructions. Which means that if you use a method implemented with old scalar instructions, it may even have worse performance than if you had not used the Vector API at all. I have seen example mentioned relating to masks and to reductions.
So it seems that the sweet spot for Java 18 and text processing/parsing/transcoding might be the simple approach of using a vector to read in a chunk of data and check whether the bytes are allow some optimized scalar code or not: for example, for transcoding from UTF-8 to UTF-16, you read in 256 bytes (or whatever) and if all are ASCII range (=<0x7F) you can convert by copying every byte to a zeroed 512 byte array, otherwise you use the complete state-machine approach.
For an example of this approach (for C++ instrinsics) see my Using C++ Intrinsics for Pipelined Text Processing on the Wayback Machine.
Interesting that it has taken almost 20 years to get to the stage where the reader's question about doing this in Java is getting near an answer. Glacial and self-defeating is the only way I can see this tardiness: every time you hear people say glibly that performance does not matter for X, you can be sure that some other more efficient technology Y is coming to disrupt, whose proponents will find it obvious that X is an inefficient dinosaur. (For another angle on this, see XML as a canary in the mine: can Intel ISPC help stagnant C get its mojo back?)