-
Notifications
You must be signed in to change notification settings - Fork 5.8k
8340404: CharsetProvider specification updates #21076
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
8340404: CharsetProvider specification updates #21076
Conversation
👋 Welcome back jlu! A progress list of the required criteria for merging this PR into |
@justin-curtis-lu 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:
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 115 new commits pushed to the
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. ➡️ To integrate this PR with the above commit message to the |
@justin-curtis-lu The following label will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command. |
Webrevs
|
* questions. | ||
*/ | ||
module provider { | ||
exports spi; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a bit of anti pattern for service provider modules to export an API, can you drop this? I don't think it's possible to check the test setup while that is there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for taking a look Alan. Your test comments should be addressed in 790abd0.
Did you have any comments on the current doc change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you have any comments on the current doc change?
I've been slow to reply on that because I'm not 100% sure if the spec is correct. Can you double check that the CCL is actually used. I think it uses the system class loader, and maybe the platform class loader for the extended charsets.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi Alan,
I think you're right that the CCL is not used.
The standard charsets are loaded via the SystemClassLoader, the extended are loaded via the platformClassLoader, and BazProvider does appear to be loaded via the SystemClassLoader. See below,
// Assert default context class loader is the system class loader
Thread.currentThread().getContextClassLoader(); // default context class loader -> jdk.internal.loader.ClassLoaders$AppClassLoader@1d81eb93
ClassLoader.getSystemClassLoader(); // system class loader -> jdk.internal.loader.ClassLoaders$AppClassLoader@1d81eb93
// Change the default context class loader
Thread.currentThread().setContextClassLoader(new FooLoader()); // Change default context class loader to not be the system
// Check the class loaders for the various Charsets
Charset.availableCharsets().get("utf-8").getClassLoader(); // standard -> null
Charset.availableCharsets().get("Big5").getClassLoader(); // extended -> jdk.internal.loader.ClassLoaders$PlatformClassLoader@55a95ab1
Charset.availableCharsets().get("BAZ").getClassLoader(); // provider -> jdk.internal.loader.ClassLoaders$AppClassLoader@1d81eb93
Thread.currentThread().getContextClassLoader(); // context class loader -> CharsetProviderAsModuleTest$FooLoader@1d15c6cc
Can we simply omit the line:
"Charset providers are looked up via the current thread's context class loader".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for checking. I remember JDK-4619777 and it's possible there are one or two other JBS issue on the topic. It may be been interesting to include a charset provider with a dynamically loaded application at one point but seems less interesting in 2024. So I think we should just update the spec to align with the long standing behavior, meaning specify that the charset provider must be visible to the system class loader. I think "by some other platform-specific means" by can be dropped too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated in d90f6ca.
throw new RuntimeException("SPI BazProvider did not provide BAZ Charset"); | ||
} else { | ||
bazCs = cs.get("BAZ"); | ||
var aliases = bazCs.aliases(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this needs to test that bazCs.getClass().getModule() is a named module.
* @bug 8340404 | ||
* @summary Check that a CharsetProvider SPI can be deployed as a module | ||
* @modules provider | ||
* @build provider/module-info provider/spi.BazProvider |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can use @build provider/*
here and jtreg will do the right thing.
* @test | ||
* @bug 8340404 | ||
* @summary Check that a CharsetProvider SPI can be deployed as a module | ||
* @modules provider |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The @modules
tag is used for test selection, I don't know what L28 does.
@justin-curtis-lu this pull request can not be integrated into git checkout JDK-8340404-CharsetProvider-asModule
git fetch https://git.openjdk.org/jdk.git master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push |
@@ -36,14 +36,28 @@ | |||
* zero-argument constructor and some number of associated charset | |||
* implementation classes. Charset providers may be installed in an instance | |||
* of the Java platform as extensions. Providers may also be made available by |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is not related to module path, but taking this opportunity, let's amend this sentence that refers to "extensions" which is obsolete.
* loader}. | ||
* loader}. See {@link java.util.ServiceLoader##developing-service-providers | ||
* Deploying Service Providers} for further detail on deploying a charset | ||
* provider as a module or on the class path. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would better to say "deployed" rather than "available" here, that will align with the later text.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I presume you meant the "available" on line 37 should be "deployed" and changed as such.
* loader}. | ||
* zero-argument constructor and some number of associated {@code Charset} | ||
* implementation classes. Charset providers are deployed by adding them to either | ||
* the application module path or the application class path. In order to be looked |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The latest update to the class description looks quite good. I think this sentence can be simplified down to "Charset provider are deployed on the application module path ...".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in 08e8161
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the approval @AlanBateman . Could you also review the CSR when you get the chance.
Thanks for the reviews. |
Going to push as commit 082125d.
Your commit was automatically rebased without conflicts. |
@justin-curtis-lu Pushed as commit 082125d. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Please review this PR and CSR which clarifies that a CharsetProvider SPI can be provided via the application module path.
This came as a result from a comment on the PR of JDK-8339735.
I included some minor wording on deploying as a module, with a link to
Service Loader's
Developing Service Providers section to handle the heavy lifting. However, I am happy to adjust as needed, if it is felt that more info should be laid out directly onCharsetProvider's
class description itself.An associated test is provided to confirm that a
CharsetProvider
can be deployed as a module.Additionally some outdated info is corrected as part of this change.
Progress
Issues
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/21076/head:pull/21076
$ git checkout pull/21076
Update a local copy of the PR:
$ git checkout pull/21076
$ git pull https://git.openjdk.org/jdk.git pull/21076/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 21076
View PR using the GUI difftool:
$ git pr show -t 21076
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/21076.diff
Webrev
Link to Webrev Comment