search

apache / accumulo-access

Apache Accumulo Access Control Library
https://accumulo.apache.org
Apache License 2.0
4 stars 11 forks source link

Use Java module mechanism to limit non public API types #81

Open keith-turner opened 3 months ago

keith-turner commented 3 months ago 
          It is not part of the public API, its package private.  The project has [this script](https://github.com/apache/accumulo-access/blob/main/src/build/ci/find-unapproved-public.sh) that attempts to validate that only a small subset of types are public.  The project only has single package so the non public api stuff is set to package private and then the script checks that. 

         I suppose we could also use the new Java module mechanisms for this project since its new and so small, should hopefully be easy to do.

_Originally posted by @keith-turner in https://github.com/apache/accumulo-access/pull/80#discussion_r1693394791_

keith-turner commented 3 months ago

Maybe the java module mechanism could be use to limit the types available publicly instead of relying on package private and the script mentioned in the description, not sure.

ctubbsii commented 3 months ago

I think modules can only be as granular as packages, and everything in that package is accessible via reflection. So, if you want something not exposed, even by reflection, you have to put it in a separate package in a separate module and define the relationships between the modules in your module-info.java. In the other module, it will probably have to be more visible (public) so you can use it across the traditional package boundaries.

keith-turner commented 3 months ago

@ctubbsii I read about modules a long time ago when they first came out, but can not remember the details. Reading your comment I am wondering if you think modules are workable for accumulo-access? My interpretation of your comment is that its workable but will require a reorg of code into a diff package layout.

ctubbsii commented 3 months ago

Yes, I think it's workable, and yes I think it will require a slight reorg, so that internal "impl" code is in a separate package. But I'm no expert on modules. I mainly think it'd be a good library to try it with, because it's low risk on a small library, and there's much knowledge yet to be gained from trying it :smiley_cat: