The Brief Yet Complicated History of JDK 12's String::transform Method
JDK 12 has already seen some turmoil with respect to the String class.
Join the DZone community and get the full member experience.Join For Free
It was recently proposed that the Java preview feature Raw String Literals (JEP 326) be removed from JDK 12 and it is now official that the preview feature will be removed (version 25 of Java SE 12 [JSR 386] removes it). Several methods had been added to the JDK String class to support this feature. Those methods that were added to versions of the JDK prior to JDK 12 [such as String::lines] are likely to remain available even after the raw string literals preview feature has been removed. However, it has already been decided that one method added to
String in JDK 12 (
String::align) should be removed from JDK 12 as part of removing raw string literals. The method String::transform was added to JDK 12 and the remainder of this post looks at
String::transform, as currently implemented in JDK 12, in more detail and discusses why its already controversial short history implies that it could be a potential candidate for removal along with raw string literals.
String::transform implementation has been available in JDK 12 Early Access Builds since ( Build 24 [ 15 December 2018] is latest available build as of this writing) and was introduced via JDK-8203442 ("String::transform").
There was quite a bit of discussion related to this method being added to the JDK. The following bullets outline key discussion points.
- Jim Laskey wrote that the "originating goal" of
String::transformwas to "allow custom alignment methods for those developers not satisfied with
- Other messages further describe the motivation for, intent of, and benefits of
- Rémi Forax wrote, "...it's nice to be able to be able to write code fluently from left to right..."
- Jim Laskey wrote, "String::transform was intended to facilitate custom manipulation (alignment) of raw string literals, in the most string generalized way."
- The "Description" of JDK-8203442 states, "The String::transform instance method allows the application of a lambda function to a string."
- JDK-8203703 supplies examples to illustrate that "...steps can be discerned more clearly" with String::transform than with static methods in which the "reader is forced to interpret portions of the expression from the inside out."
String, but then was changed to return
Objectand Jim Laskey wrote about that change, "'transform' became generic when the case was made that other types might also be relevant." He concluded, "I might be led back to just supporting
- The naming of
String::transformhas been challenging with some of the following names proposed (listed in alphabetic order):
- Rémi Forax has written that "more variants (
transformToDouble) [are needed] to be useful."
- Brian Goetz has described why the current plan is to implement this functionality via the method
String::transformrather than an operator such as
- Stuart Marks has written that "this particular decision [
String::transform] sets a precedent for the use of the name 'transform' for methods that do similar things on other classes" and references JDK-8140283 and JDK-8214753:
- JDK-8140283 proposes the addition of the "
chain" method for Stream and Optional to "mitigate" the "disrupt[ion of] the linear flow of the pipeline stages" when using methods that acts upon a
Optionaland return something that is itself "chainable").
- JDK-8214753 proposes the addition of "
Optional::transform" that would allow for "an arbitrary operation on an
- JDK-8140283 proposes the addition of the "
- There was some confusion and consternation related to how
String::transformwas added to OpenJDK 12, but Stuart Marks's message summarizes the events leading to the addition of this method.
- Tomasz Linkowski has pointed out that it's likely that
String::transform(and any similar method added to
Stream) will get used in select cases where there are easier ways to do the same thing already without the new method. The examples he provides of potential misuse of
string.transform(String::toLowerCase)" and "
Two online examples demonstrate how
String::transform might be used in its most common use cases:
- JDK-8203703 ("String::transform") provides a "Solution" example that demonstrates how
String::transformcan improve code readability by allowing for operations acting on
Strings to be read in order from left-to-right rather than being read "from the inside out."
- A message on the core-libs-dev mailing list provides an example of using
String::transformto convert a
Stringinto an instance of a class other than
Stephen Colebourne asked the same question I was wondering when I read that raw string literals were to be removed from JDK 12: "Is
String::transform going to be removed as well given the removal of raw strings and its controversial nature?" Although I have not seen anything authoritative and definitive regarding whether
String::transform will remain in JDK 12, there are three pieces of evidence that lead me to think it will be staying.
- I have not seen anything saying that
String::transform, which is already in JDK 12 as of Early Access Build 22, is to be removed. There are issues written to remove compiler support associated with raw string literals and even to remove another String method (
String::align), but I'm not aware of a similar issue written for
- It has been stated that while
String::transformwas added as part of the raw string literal work, it was also stated that
String::transform"stands on its own."
- The two examples I cited earlier on how to use this method do not rely on or require raw string literals. In other words, the method can be used regardless of the presence or absence of raw string literals.
String::transform has not been around for a long time (less than one year), but it already has a significant history. The method is available currently in JDK 12 (since Early Access Build 22) and I suspect it will remain part of
String's API despite the removal of raw string literals from JDK 12.
Published at DZone with permission of Dustin Marx, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.