On Wed, 10 Nov 2021 09:22:32 GMT, Сергей Цыпанов <d...@openjdk.java.net> wrote:
> Looking into File.pathSeparator I've found out that currently we initialize > them as > > public static final String separator = "" + separatorChar; > > Which after compilation turns into > > NEW java/lang/StringBuilder > DUP > INVOKESPECIAL java/lang/StringBuilder.<init> ()V > LDC "" > INVOKEVIRTUAL java/lang/StringBuilder.append > (Ljava/lang/String;)Ljava/lang/StringBuilder; > GETSTATIC java/io/File.pathSeparatorChar : C > INVOKEVIRTUAL java/lang/StringBuilder.append (C)Ljava/lang/StringBuilder; > INVOKEVIRTUAL java/lang/StringBuilder.toString ()Ljava/lang/String; > PUTSTATIC java/io/File.pathSeparator : Ljava/lang/String; > > This can be simplified to > > public static final String separator = String.valueOf(separatorChar); > > Which is in turn complied into more compact > > GETSTATIC java/io/File.pathSeparatorChar : C > INVOKESTATIC java/lang/String.valueOf (C)Ljava/lang/String; > PUTSTATIC java/io/File.pathSeparator : Ljava/lang/String; > > The changed code is likely to slightly improve start-up time as it allocates > less and does no bound checks. FWIW the specific pattern of `"" + foo` could probably profitably translate into `String.valueOf(foo)` regardless of `StringConcatFactory` availability. (And translating `String` concat to use `SCF` in class initializers is likely a pessimization most of the time.) I'm no expert on javac but I suspect implementing (and worse: specifying) minor improvements to the translation might be more effort than it's worth, though, so point fixes like these seem fine to me. ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6326
