8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase

[doom369]

isEmpty is faster + has less byte code + easier to read. Benchmarks could be found here.

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed

Issue

• JDK-8252999: Cleanup: Replace .equals("") with .isEmpty() throughout the codebase ⚠️ Title mismatch between PR and JBS.

Download

$ git fetch https://git.openjdk.java.net/jdk pull/29/head:pull/29
$ git checkout pull/29

[bridgekeeper]

Hi @doom369, welcome to this OpenJDK project and thanks for contributing!

We do not recognize you as Contributor and need to ensure you have signed the Oracle Contributor Agreement (OCA). If you have not signed the OCA, please follow the instructions. Please fill in your GitHub username in the "Username" field of the application. Once you have signed the OCA, please let us know by writing /signed in a comment in this pull request.

If you already are an OpenJDK Author, Committer or Reviewer, please click here to open a new issue so that we can record that fact. Please use "Add GitHub user doom369" as summary for the issue.

If you are contributing this work on behalf of your employer and your employer has signed the OCA, please let us know by writing /covered in a comment in this pull request.

[openjdk]

@doom369 The following labels will be automatically applied to this pull request: awt build hotspot i18n javadoc jdk jmx net nio security serviceability swing.

When this pull request is ready to be reviewed, an RFR email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label (add|remove) "label" command.

[doom369]

/signed

[bridgekeeper]

Thank you! Please allow for up to two weeks to process your OCA, although it is usually done within one to two business days. Also, please note that pull requests that are pending an OCA check will not usually be evaluated, so your patience is appreciated!

[thatsIch]

@doom369 jcheck requires an associated issue

[doom369]

@mrserb hello. Thanks for the review. Any further actions required from me?

[kevinrushforth]

Before this Enhancement can be formally reviewed, you will need a JBS bug ID. If you are already working with a Committer or Reviewer in the jdk project who has agreed to sponsor your change, they can file the Enhancement request. Otherwise, you can file it using the web interface at bugreport.java.com. Once you have a JBS bug ID, you need to edit the PR title to include that bug ID (without the JDK-) replacing "Improvement".

Since this PR cuts across many functional areas (each gray label represents a functional area), you should expect a longer review process, since someone from each functional area will need to look at the changes in their area (like @mrserb started to do for the 2d area).

[doom369]

@kevinrushforth thanks. Done.

Similar issues:
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8215014
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8251246
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8223237

could be joined somehow?

[mlbridge]

Webrevs

• 00: Full (0942f92)

[AlanBateman]

The code in java.base was updated to use String::isEmpty in JDK 12 (JDK-8215281). There was follow-up in JDK 13 to do the same in the java.desktop module (JDK-8223237). Changing the remaining usages make sense although I see that more more than half are in tests.

It would be good to hear from security-dev on the changes to the Apache Santuario code (in java.xml.crypto module) in case it would be better to contribute those upstream instead. Ditto for the Apache Xalan code (in the java.xml module) but it may be significantly forked already that it doesn't matter.

I assume you can use JDK-8215014 rather than creating a new issue.

[dholmes-ora]

This should be broken up to deal with the files in different functional areas under different bugids and PRs. Otherwise the cross-posting to so many lists is prohibitive. Files in different areas need to be reviewed by different teams. Thank you.

[doom369]

I have in mind dozens of improvements all over the code like this one. I already did some further review and in most cases, those tiny changes go trough all codebase. I can create PR for every separate module, but in general, it would multiply x5 the number of PRs in total. If you think it's a better way to go, no problem, I can do that.

[kevinrushforth]

@dholmes-ora raises a good point. Hopefully there is a balance point between a dozen different bugs / pull requests each targeting one area and one bug / PR targeting a dozen separate areas. I don't have a good general rule to suggest. Maybe @AlanBateman or @jddarcy can offer some advice?

[dholmes-ora]

14 cc'd mailing lists is unworkable. You need to be subscribed to lists to post, but even if you are a reply-all will be delayed due to all of the mails being held up for moderator approval due to:

" Too many recipients to the message"

I have a longer email coming once it gets through the moderator approval delay. :(

[AlanBateman]

Patches that do global replace are always awkward. In this case, there are 150 files changed and most seem to be tests or changes to tools used in the build (includes src/hotspot/share/prims/jvmtiEnvFill.java). If these are dropped from the patch then it leaves just 43 files, many of which are from 3rd party code that can also be dropped. This should reduce the patch down to a manageable 24 or so files that should be trivial to review.

[JornVernee]

Since one of the motivations for this change is micro benchmark performance, please add a benchmark to the JDKs micro benchmark suite as well. (see e.g. https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/lang).

Please note that we can not consider any information on external websites for the review, so please add any relevant information to the PR body instead.

Also, what testing has been done for these changes?

[jonathan-gibbons]

I have in mind dozens of improvements all over the code like this one.

That sounds scary. Broad updates like these cause unnecessary churn in the codebase, and can make merging and back porting harder. Changes should be discussed ahead of time with the appropriate teams.

[prrace]

1. This is un-necessary churn.
2. I can't even be sure I am finding the ones in my area because there's so much here
3. The ones I can find have no need of whatever performance improvement this might bring.
   I think this whole PR should be withdrawn, and there may an attempt at measuring the benefits of this for the various cases before submitting in appropriate smaller chunks. But I'll tell you now I don't see a need for the test updates you are making.

[doom369]

Ok, sorry for the distraction.

[bradfordwetmore]

Our local Santuario maintainer says:

In general, changes to Apache Santuario should also be made at Apache so we stay in sync.

[stuart-marks]

Hi @doom369, I hope we didn't end up wasting too much of your time with this. I wanted to respond to a comment you made earlier in this PR,

I have in mind dozens of improvements all over the code like this one.

It's hard to see, but as you discovered, the JDK has different groups of people maintaining different areas, and sometimes there are hidden constraints on those different areas, for example, to avoid divergence with upstream source bases. And as you discovered, sometimes those source bases might need to maintain compatibility with an older JDK ... so we don't want to update this code even though it's IN the JDK.

Those kind of constraints generally don't apply to code in the java.base module, since there's nothing upstream of it, and by definition it cannot depend on anything outside the JDK. Generally -- though there are exceptions -- we're more receptive to keeping stuff in java.base (and sometimes related modules close to the core) on the latest and greatest stuff. There are some constraints, however. There are some things we can't use too early during initialization of the JDK, such as lambdas. Also, there is some code lurking around that is sometimes executed by the boot JDK, which is typically one release behind. (This is definitely the case for tools like javac, but I think it might also apply to some things in base.)

Anyway, if you'd like to pursue some of these improvements, drop a note to core-libs-dev@openjdk and we can talk about it.

Thanks.

[doom369]

@stuart-marks thanks. Sure, I understand that maintaining OpenJDK is not a simple task. I thought as change is super simple without any side effects it can go through. But I was wrong. That's fine. I'll focus on java.base when I have some free time.