At the risk of many modules, combining oaj.atlas and guava into a
"non-RDF" package now seems wrong to me. Instead, a module for just
shading guava then separately oaj.atlas (eventually).
Is many modules a problem? (I don't think - for Jena3 we can even have
jena-system.jar as a uber jar, including space reduced with ProGuard or
similar).
RE: #48 I don't see that including in jena-core and shading has an
advantages and the use one package name in one place and different
packages in another seems like a disadvantage.
I don't think bumping all the versions is necessary either; it's all
behind the delivery jars.
JENA-905 collects things together as this is being split over email and
github.
Andy
On 20/03/15 16:35, Stian Soiland-Reyes wrote:
+1 to the 'before' option.
On 20 March 2015 at 15:34, Andy Seaborne <[email protected]> wrote:
On 19/03/15 18:23, Stephen Allen wrote:
I've used the Guava cache before and I really like the design.
We obviously may have some issues with it being a dependency as was
discussed in the email thread you linked. For my usage, I would have no
problem keeping my application up to date with the latest Guava (as long
as
Jena keeps up to date). But maybe we would need to shade it so other
people won't get conflicting versions. Presumably when/if Jigsaw arrives
we won't have to worry about this problem any more.
If we do decide to make Guava a dependency, it would be nice (although a
big change) to take a pass through and eliminate utility methods/classes
that we have that are provided by Guava (I'm thinking of
org.apache.jena.atlas.iterator.Iter specifically).
-Stephen
Hi Stephen,
Guava seems the best I've come across so far. Shading seems like a good idea
as an insurance policy. It's not hard (I just tried it out).
If we shade it, we can do that before or after the RDF code.
If "before", we add a new module to produce org.apache.jena.guava.** and
code against that. This is the version I prefer.
If "after", we write code against com.google.guava.** and shade the output
jars. Each jar has to be done so it's a bit tedious.
If "before" we can put org.apache.jena.atlasin that module, produce
"jena-ourbasetuff.jar" as a very early step in the build. Any other non-RDF
code canmigrate as people see fit.
Using ProGuard to shrink the jar is orthogonal IMO (though the guava jar is
2.3M so while non-trivial for Android, it's not that large for
desktop/server use).
Re: Jigsaw. Maybe - I don't know whether the code has to migrate to java9 or
whether exiting code can be wrapped. Even with org.apache.jena.guava but
otherwise the same code, switching to raw use should be quite easy (famous
last words!).
As to clean up - anyone is welcome to tidy anything up. If Jena3 is Java8,
then maybe we can jump to Java8 streams , Optional, etc. Guava seems to
have an goal of portability across Android, GWT and is currently Java 1.6.
Andy
[1] https://code.google.com/p/guava-libraries/wiki/FunctionalExplained
