Excellent! I think, making this clear distinction between what's public
and what's not, gives us more flexibility. E.g. we can experiment with
ideas not having to worry about removing anything later, in case an idea
has flaws.
By the way, at first I thought removing guava entirely from applib is
too much effort. But after digging into it, I'd say, its not that hard.
I'd love to remove the dependency on reflections.org as well (without
any urge). But that would need some investigation. Refactoring showed,
we have few uses-cases for reflections, now (with the Internal API
branch) all 'redirected' through the interfaces provided by _Reflect.
Cheers Andi
On 27.01.2018 09:37, Dan Haywood wrote:
OK, thanks Andi.
Well, for myself I'm happy to leave these classes in isis-core-applib,
ie where you've moved them. In any case, suspect folk will be moving
to Java 9 in the next year, and so we're gonna have to figure out a
way to bundle Isis for both Java 8 and Java 9 (ie with
module-info.java). In the module-info.java we'll just not export that
new package.
Cheers
Dan
