Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI #3416

Closed
wants to merge 4 commits into from

Conversation

@c-cleary
Copy link
Contributor

@c-cleary c-cleary commented Apr 9, 2021

Description

This fix is part of a previous effort to both cleanup/modernise JNDI code, the details of which can be seen in JDK-8048091. A number JNDI methods under java.naming use Anonymous Inner Classes in cases where only a single object unique to the requirements of the method is used. The issues these occurrences of AICs cause are highlighted below.

Issue

  • AICs, in the cases concerned with this fix, are used where only one operation is required. While AICs can be useful for more complex implementations (using interfaces, multiple methods needed, local fields etc.), Lambdas are better suited here as they result in a more readable and concise solution.

Fixes

  • Where applicable, occurrences of AICs were replaced with lambdas to address the issues above resulting primarily in more readable/concise code.

Progress

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

Issue

  • JDK-8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/3416/head:pull/3416
$ git checkout pull/3416

Update a local copy of the PR:
$ git checkout pull/3416
$ git pull https://git.openjdk.java.net/jdk pull/3416/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 3416

View PR using the GUI difftool:
$ git pr show -t 3416

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/3416.diff

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Apr 9, 2021

👋 Welcome back ccleary! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk openjdk bot added the rfr label Apr 9, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Apr 9, 2021

@c-cleary The following labels will be automatically applied to this pull request:

  • core-libs
  • security

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 pull request command.

@mlbridge
Copy link

@mlbridge mlbridge bot commented Apr 9, 2021

Webrevs

}
});
(PrivilegedAction<String>) () -> System.getProperty(propName, defVal)
);

This comment has been minimized.

@AlanBateman

AlanBateman Apr 9, 2021
Contributor

If you want to avoid the cast then you could create the PrivilegedAction explicitly, e.g.

PrivilegedAction pa = () -> System.getProperty(propName, defVal);
return AccessController.doPrivileged(pa);

This comment has been minimized.

@RogerRiggs

RogerRiggs Apr 9, 2021
Contributor

An alternative here would be to use sun.security.action.privilegedGetProperty(prop, default).
The package is already exported from java.base to java.desktop, etc.

This comment has been minimized.

@c-cleary

c-cleary Apr 9, 2021
Author Contributor

That is a very neat alternative yes. Approaching the problem like that especially improves the readability JdkLDAP.java in my opinion.
I don't think casting has any major performance hits for these fixes, so is your suggestion mostly for readability's sake?

This comment has been minimized.

@RogerRiggs

RogerRiggs Apr 9, 2021
Contributor

Right, not a performance problem. Just simpler to use an existing method to read a privileged property.
And there will be one less doPriv.

This comment has been minimized.

@c-cleary

c-cleary Apr 9, 2021
Author Contributor

I think I may change the PR to reflect what Alan suggested. Its more readable than the lambda-with-cast solution in that an action is created and then an action is carried out as supposed to fitting it all into one call. Its also as concise.

Copy link
Contributor

@RogerRiggs RogerRiggs left a comment

Looks good.

A general reminder about one important difference between an anonymous inner class and a lambda.
An anonymous has identity but a lambda does not; or only accidentally.
None of the uses here require identity.

}
});
(PrivilegedAction<String>) () -> System.getProperty(propName, defVal)
);

This comment has been minimized.

@RogerRiggs

RogerRiggs Apr 9, 2021
Contributor

An alternative here would be to use sun.security.action.privilegedGetProperty(prop, default).
The package is already exported from java.base to java.desktop, etc.

private static final long getLong(final String propName, final long defVal) {
return AccessController.doPrivileged(
(PrivilegedAction<Long>) () -> Long.getLong(propName, defVal).longValue()
);

This comment has been minimized.

@RogerRiggs

RogerRiggs Apr 9, 2021
Contributor

And GetIntegerAction here. Though it only supports an int value.

This comment has been minimized.

@c-cleary

c-cleary Apr 9, 2021
Author Contributor

Thanks for the suggestion Roger, I think the privilegedGetProperty(prop, default) for the getProperty() method looks great.

WRT to using it for getInt() and getLong(), I think its reasonable to use other means for these methods in the interest of consistency due to, as you pointed out, only int being supported. Would you think? Or would it be better to use the same means in all 3 methods?

This comment has been minimized.

@RogerRiggs

RogerRiggs Apr 9, 2021
Contributor

Its a slippery slope that might require a bit more investigation to check the expected value sizes to see if a change to the number of bits in the value for each property might break something. Technical debt can take you down a rabbit hole. Quickest to just convert to the lamba as you proposed.

This comment has been minimized.

@c-cleary

c-cleary Apr 12, 2021
Author Contributor

I have stuck with the lambda conversion solution in the current changes, however WRT to Alan's previous feedback on creating a PrivilegedAction explicitly as it makes everything a bit more readable.

new PrivilegedAction<String>() {
public String run() {
try {
return System.getProperty(propName, defVal);
} catch (SecurityException e) {
return defVal;
}
}
});
private static final String getProperty(final String propName, final String defVal) {
PrivilegedAction<String> pa = () -> System.getProperty(propName, defVal);
return AccessController.doPrivileged(pa);
Comment on lines -401 to +400

This comment has been minimized.

@dfuch

dfuch Apr 12, 2021
Member

Hmmm... This is not strictly equivalent but will work because java.naming is loaded by the boot loader and has the permission to read all system properties. I guess the code on the left-hand side was written at a time where JNDI was still in a stand-alone library?

This comment has been minimized.

@YassinHajaj

YassinHajaj Apr 25, 2021

@dfuch I noticed the same about the swallowed exception that returns the default value. This wouldn't cause any regression?

This comment has been minimized.

@dfuch

dfuch Apr 26, 2021
Member

As I noted - the SecurityException should never occur so I don't expect this could cause a regression.

@dfuch
dfuch approved these changes Apr 12, 2021
Copy link
Member

@dfuch dfuch left a comment

LGTM

@openjdk
Copy link

@openjdk openjdk bot commented Apr 12, 2021

@c-cleary This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI

Reviewed-by: rriggs, dfuchs, aefimov, chegar

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 41 new commits pushed to the master branch:

  • 7006070: 8265061: Simplify MethodHandleNatives::canBeCalledVirtual
  • 1935655: 8264957: Cleanup unused array Type::dual_type
  • 954b9a1: 8264795: IGV: Upgrade NetBeans platform
  • f2f7aa3: 8262291: Refactor reserve_memory_special_huge_tlbfs
  • 008fc75: 8264224: Add macosx-aarch64 to Oracle build configurations
  • f4e6395: 8264190: Harden TLS interop tests
  • 18bec9c: 8265084: [BACKOUT] 8264954: unified handling for VectorMask object re-materialization during de-optimization
  • 9dd9625: 8263763: Synthetic constructor parameters of enum are not considered for annotation indices
  • 1ee80e0: 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding
  • d84a7e5: 8264124: Update MXBean specification and implementation to extend mapping of CompositeType to records
  • ... and 31 more: https://git.openjdk.java.net/jdk/compare/f7a6c63ad30a67b34868118a4a88ed100e8bd769...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@RogerRiggs, @dfuch, @AlekseiEfimov, @ChrisHegarty) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

@openjdk openjdk bot added the ready label Apr 12, 2021
Copy link
Member

@AlekseiEfimov AlekseiEfimov left a comment

The change looks good to me with one small suggestion:

}
}
);
PrivilegedAction<ClassLoader> pa = () -> Thread.currentThread().getContextClassLoader();

This comment has been minimized.

@AlekseiEfimov

AlekseiEfimov Apr 12, 2021
Member

We can use here an instance method reference to beautify code a little bit more:
PrivilegedAction<ClassLoader> pa = Thread.currentThread()::getContextClassLoader;

This comment has been minimized.

@c-cleary

c-cleary Apr 13, 2021
Author Contributor

Good idea, also would fit in with the style of the method just after, priviligedHasNext() as that also uses a functional interface.

This comment has been minimized.

@c-cleary

c-cleary Apr 13, 2021
Author Contributor

Changes included as described in commit 5d6ecd3

This comment has been minimized.

@dfuch

dfuch Apr 13, 2021
Member

Here again this is not strictly equivalent but AFAIK Thread::currentThread doesn't require any permission, so this should be OK.

@c-cleary
Copy link
Contributor Author

@c-cleary c-cleary commented Apr 13, 2021

/integrate

@openjdk openjdk bot added the sponsor label Apr 13, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Apr 13, 2021

@c-cleary
Your change (at version 5d6ecd3) is now ready to be sponsored by a Committer.

@dfuch
dfuch approved these changes Apr 13, 2021
@AlekseiEfimov
Copy link
Member

@AlekseiEfimov AlekseiEfimov commented Apr 15, 2021

/sponsor

@openjdk
Copy link

@openjdk openjdk bot commented Apr 15, 2021

@AlekseiEfimov @c-cleary Since your change was applied there have been 92 commits pushed to the master branch:

  • 6293299: 8264824: java/net/Inet6Address/B6206527.java doesn't close ServerSocket properly
  • 6b90715: 8265278: doc build fails after JDK-8262981
  • 0fee6ec: 8264318: Lanai: DrawHugeImageTest.java fails on apple M1
  • 81877f7: 8262501: jdk17 libjvm link failure with --as-needed and clock_gettime in librt
  • b23dbdb: 8257804: Test runtime/modules/ModuleStress/ModuleStressGC.java fails: 'package test defined in module jdk.test, exports list being walked' missing from stdout/stderr
  • 9d669c9: 8262981: Create implementation for NSAccessibilitySlider protocol
  • abdff79: 8163086: java/awt/Window/TranslucentJAppletTest/TranslucentJAppletTest.java fails
  • b72d99e: 8233564: [TESTBUG] MouseComboBoxTest.java is failing
  • 2b5869a: 8233565: [TESTBUG] NullModalityDialogTest.java fails on MacOS
  • bba16f6: 8264818: G1: Improve liveness check for empty pinned regions after full gc marking
  • ... and 82 more: https://git.openjdk.java.net/jdk/compare/f7a6c63ad30a67b34868118a4a88ed100e8bd769...master

Your commit was automatically rebased without conflicts.

Pushed as commit 4e90d74.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment