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

refactor: Reduce API implementation classes visibility #227

Merged
merged 38 commits into from
Oct 30, 2023

Conversation

guicamest
Copy link
Contributor

@guicamest guicamest commented Oct 26, 2023

Description of changes

As described in #223 (comment):

Classes visibility are reduced in order to avoid leaking the classes to the user of the library who could potentially write some code with this information. This will benefit the maintenance of the library, as it'll provide more freedom to implementation changes without risking breaking user code. After all, this library is an implementation of NIO so that users shouldn't care if a Path is an S3Path or AWSS3Path. This is how the default implementations are implemented, for example, class LinuxFileSystem is not public.

Code coverage

image

image

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@guicamest
Copy link
Contributor Author

guicamest commented Oct 26, 2023

Looking at FileSystems.newFileSystem javadoc, it looks like the method is intented for creating filesystems, not just a FileSystem object. If this is correct, then the implementation of newFileSystem in the S3FileSystemProvider would be incorrect, as it is getting a FileSystem object, not creating a FileSystem. Given the description on the README about the relationship FileSystem <-> Buckets, it would mean creating a Bucket).

The default FileSystem implementations throw when newFileSystem is called:
image
image

IMHO, I think it will be a good opportunity to remove the current implementation of newFileSystem for v2.x.x , leaving it unimplemented (UnsupportedOperation) until:

  • it is implemented for bucket creation (new feature, non breaking) or,
  • left unimplemented but following the specification

What are your thoughts @markjschreiber ?

@markjschreiber
Copy link
Contributor

markjschreiber commented Oct 26, 2023

You make a good point. I would be in favor of being able to use it to create a bucket. The map of key value pairs passed to it would need to map to properties that can be set on the CreateBucketRequest. We would need to move the current functionality of the newFileSystem over to the getFileSystem method on the S3FileSystemProvider.

@guicamest
Copy link
Contributor Author

We would need to move the current functionality of the newFileSystem over to the getFileSystem method on the S3FileSystemProvider.

Exactly!

Would it be ok to turn it into unimplemented for this PR and leave the implementation for a future PR? Otherwise it'll be a hell to review as it is already big.

@guicamest guicamest marked this pull request as ready for review October 29, 2023 17:02
Copy link
Contributor

@markjschreiber markjschreiber left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this refactoring. I have asked a couple of questions in the review and there are some suggested changes.

public S3FileSystem newFileSystem(URI uri) {
return newFileSystem(uri, Collections.EMPTY_MAP);
public FileSystem newFileSystem(URI uri, Map<String, ?> env) {
throw new NotYetImplementedException("This method is not yet supported in v2.x. It might be implemented for bucket creation");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add an issue to implement this for bucket creation?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure I'll do

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Created #243, feel free to add any information you consider relevant 🙏

@@ -14,34 +14,16 @@
* limitations under the License.
*/

package software.amazon.nio.spi.s3x;
package software.amazon.nio.spi.s3;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You seem to have moved some of the s3x... classes into the s3 package. Is this intentional? If so you should probably move the rest as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes it was intentional. By changing the visibility of fileSystemInfo in the superclass of the S3XFileSystemProvider, I needed to move this one to the same package.

The one left in s3x package is S3XFileSystemInfo, I can move it👍

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 1c80df9

@markjschreiber
Copy link
Contributor

Merging the other PRs has created a conflict here. You can probably resolve it by rebasing this onto HEAD

…igured. Hide `S3Path` from `FileSystem.getPath`
Copy link
Contributor

@markjschreiber markjschreiber left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great

@markjschreiber markjschreiber merged commit e53d7fe into awslabs:main Oct 30, 2023
1 check passed
@guicamest guicamest deleted the classesVisibility branch October 31, 2023 05:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants