[
https://issues.apache.org/jira/browse/JENA-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14528468#comment-14528468
]
ASF GitHub Bot commented on JENA-931:
-------------------------------------
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/56#issuecomment-99085428
I'm definitely up for breaking this down. :)
The major moves here are:
- I replaced any interface inside oaj.atlas for which I could find a
functionally-equivalent Java 8 type with that Java 8 type, and resolved the
various syntactical changes that resulted (mostly just renaming of things, of
which you can see quite a lot).
- Following on that, I used lambda notation to shorten and clarify code
that directly involved those types from step 1. (In other words, I didn't go
looking for opportunities, I just took them when I happened to be "in the
neighborhood" and saw them: there are plenty of more places, I think, to
exercise lambda syntax).
- A few places where I could determine clearly that a method or type was
not in use anywhere in the codebase and that the functionality provided was
either available elsewhere (typically in Guava) or constructable in Java 8 in
an obvious "one-liner", I removed it.
- Lastly, for a few types (notably 'MultiMap' and 'MultiSet') I happened to
know that excellent well-exercised Guava versions already existed, so I swapped
them out and toasted the Jena versions.
To your specific points:
- `oaj.atlas.lib.Closeable`: I clearly misunderstood the semantics of this
type. I thought it was simply a narrowing of ` java.io.Closeable` to disallow
checked exceptions, so that the additional warnings would be a _good_ thing.
Since it is independent, I will remove the new relationship: would it not also
make sense to add some kind of comment explaining the particular semantics on
oaj.a.l.Closeable`? I have to admit, I didn't look at it twice before thinking
"try-with-resources".
- `NodeTransform` I will put it back in in the optimizer. If I understand
you correctly, the type itself should be declared inside oaj.sparql and used
only there, yes?
- Ah, I completely forgot about `@deprecated`. Just plain forgetfulness.
I'll get those comments tagged correctly.
Shall I make these changes, and then we can figure out how to parcel this
stuff out into reasonable commits?
JENA-931
> Shift org.apache.jena.atlas in jena-base onto Java 8 types
> ----------------------------------------------------------
>
> Key: JENA-931
> URL: https://issues.apache.org/jira/browse/JENA-931
> Project: Apache Jena
> Issue Type: Improvement
> Components: Jena
> Affects Versions: Jena 3.0.0
> Reporter: A. Soroka
> Labels: Java8, typesystem
>
> Several types in org.apache.jena.atlas in module jena-base duplicate the
> semantics of types introduced in Java 8, e.g. Jena's Transform is
> substantially the same as Java 8's Function, Jena's Filter is substantially
> the same as Java 8's Predicate, etc.
> When this ticket is done, all such types will subtype the appropriate Java 8
> types, will be deprecated, and will no longer be used inside the Jena code
> base. A further ticket may lead to actual removal of those deprecated types,
> at a convenient future moment and in a non-disruptive fashion.
> Where possible, declarations and uses of similar types throughout the Jena
> code base should be converted to use the types in o.a.j.atlas, for clarity
> and concision. Some such migration of this kind can occur as part of this
> ticket, although a wholesale shift onto o.a.j.atlas may take some time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
