-
Notifications
You must be signed in to change notification settings - Fork 11k
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
Guava + JPMS #7094
base: master
Are you sure you want to change the base?
Guava + JPMS #7094
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,20 @@ | ||
/* | ||
* Copyright (C) 2024 The Guava Authors | ||
* | ||
* Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except | ||
* in compliance with the License. You may obtain a copy of the License at | ||
* | ||
* http://www.apache.org/licenses/LICENSE-2.0 | ||
* | ||
* Unless required by applicable law or agreed to in writing, software distributed under the License | ||
* is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express | ||
* or implied. See the License for the specific language governing permissions and limitations under | ||
* the License. | ||
*/ | ||
|
||
/** | ||
* Guava: Future Internals. | ||
*/ | ||
module com.google.common.util.concurrent.internal { | ||
exports com.google.common.util.concurrent.internal; | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,30 @@ | ||
/* | ||
* Copyright (C) 2024 The Guava Authors | ||
* | ||
* Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except | ||
* in compliance with the License. You may obtain a copy of the License at | ||
* | ||
* http://www.apache.org/licenses/LICENSE-2.0 | ||
* | ||
* Unless required by applicable law or agreed to in writing, software distributed under the License | ||
* is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express | ||
* or implied. See the License for the specific language governing permissions and limitations under | ||
* the License. | ||
*/ | ||
|
||
/** | ||
* Guava Testlib | ||
*/ | ||
open module com.google.common.testlib { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It seems fine to be more permissive for the test library here by using There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Left it this way to be conservative in general :) although happy to drop as well. |
||
requires java.logging; | ||
requires com.google.common; | ||
requires com.google.common.util.concurrent.internal; | ||
|
||
exports com.google.common.collect.testing; | ||
exports com.google.common.collect.testing.features; | ||
exports com.google.common.collect.testing.google; | ||
exports com.google.common.collect.testing.testers; | ||
exports com.google.common.escape.testing; | ||
exports com.google.common.testing; | ||
exports com.google.common.util.concurrent.testing; | ||
} |
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 assume that you don't know of any specific harm that would arise if we were to modularize the
android
flavor, as well? There is probably some risk, since Android-focused tools are less likely to be aware of modules than JVM-focused tools, but I'd expect it to be pretty small at this point. The upside would be that cross-platform libraries (which may declare a dependency onguava-android
even when most of their users run on the JVM) would still be able to use a properly modularized Guava.I ask because our internal setup actually makes it easier for me to make the change in both places. This wouldn't require any changes on your part; in my internal copy of this PR, our internal setup already made the changes to
android
:) But in the unlikely event that anyone knows of reasons for me to undo that, I can do so.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 am not aware of any problem this would cause. Android supports up to JVM 21 bytecode, and IIRC modules are ignored past the
javac
phase.Yeah, but keep in mind we are packaging the module within the version root at
META-INF/versions/9/*
, so a badly behaving tool would need to (1) be unaware of, or lack support for, modules, and would have to (2) scan JARs on the modulepath blindly, and would have to (3) violate JDK 8 spec (by not skipping that as an invalid class name), and would have to (4) have updated Guava to the latest version, implying it is maintained.This fear keeps me up at night, too, but I think that actually affords quite a bit of protection. Even ancient tools which were released pre-JDK8 should have no issue since classes were not valid in
META-INF/*
at all back then. Thus, the risky part would be shipping themodule-info.class
at the root of the JAR, which probably isn't even that risky. That could be done in a few versions once confidence is in place, or when Java 9 becomes the minimum.Ah, I see. If you want to apply the change uniformly, I am all for it. I stayed out of Android and GWT because I am not sure if there is other dark magic going on.