On Fri, 8 Jul 2022 14:04:14 GMT, Roger Riggs <rri...@openjdk.org> wrote:
>> But if I roll back the added constructor I'll go through existing public one >> `public String(byte[] bytes, int offset, int length, Charset charset)` doing >> bounds check twice, won't I? > > The new constructor looks very odd, especially when it does not have an > explanation and doesn't describe the required preconditions for calling it. > Is there a better way than adding a non-functional argument? > The "unused" name is going to draw a warning from IntelliJ and some > enterprising developer is going to try to remove it, not understanding why > its there. And there is a bit of overhead pushing the extra arg. > > The constructor should be private, it has a very narrow scope of use given > the lack of checking its args. > > It would be nice if the Hotspot compiler would recognize the llmits on the > range and optimize away the checks; > it would have broader applicability then this point fix. > I would be interesting to ask the compiler folks if that's a future > optimization. > These source changes make it harder to understand what's happening where; > though that is sometimes work it for a noticeable performance improvement. Well, we already have e.g. `String(char[], int, int, Void)` and `String(AbstractStringBuilder asb, Void sig)` where trailing argument is for disambiguation against private constructors. I did the same for mine and applied the same naming as in other trailing `Void` params. ------------- PR: https://git.openjdk.org/jdk/pull/9407
