John,
Comments below.
John Arthorne wrote:
> IMHO the EMF URI impl is technically superior
to java.net.URI and should be used for all impls
I'm curious what this opinion is based on. Apart from
a couple of convenience methods, the only differences I see with the
EMF
implementation are deviation from RFC 2396 to handle
It would be interesting to consider footprint. I see on the order of
17 fields, with a great many strings. I'm not sure if there's much in
the way of string sharing going on, but only measurements will tell...
Generally they are very similar in terms of accessor methods (not
surprisingly because they implement the RFC). The path in EMF is
represented in a more fine-grained way... That might save space but
then again, it might not.
Windows devices and
archive URIs ("jar:file:/a!/" is not hierarchical but EMF's URI
says it is).
Yes. This is important because only hierarchical URIs support resolve
and deresolve and it's often important to interpret relative paths
within an archive. I suspect this would cause issues when using URIs.
The first deviation means that it won't
properly handle file:
URIs on non-Windows platforms that have a segment containing the :
character.
I'm not sure how that follows.
Both deviations mean it behaves quite
differently from java.net.URI, so
when you inevitably need to convert between the two you're likely to
get
into trouble.
I'm not sure that follows either. Generally if you create it with a
string, you get the same string back when you ask for that string
representation. I suspect the manipulations of archive URIs will
require special case handing with java.net.URI...
The EMF class does optimize for space over
speed compared
to java.net.URI, but in our situation of one URI per repository the
space
is not an issue.
Paths in the the IResource APIs were important compared to strings; I
wonder if URIs didn't cause an issue?
As for convenience methods, these are
easily added as
static methods on a utility class, which beats reimplementing and
maintaining
the 3000+ lines of a URI implementation. There are also several
conveniences
lost in the EMF class such as resolve(String), toFile(), toURL(), and
other
class library conveniences like new java.io.File(URI), and
java.io.File.toURI().
Of course you can add those... You won't be using EMF's URI anyway.
You'd be creating your own. If there are no advantages from being able
to optimize or tailor your own, you'd definitely be best to reuse
something that exists.
We have a somewhat bad habit in Eclipse of reinventing
the wheel when we perceive the Java class library isn't good enough.
Can you say icu4j? :-P
This
creates a barrier for Java developers coming to Eclipse who have to
learn
the quirks of our different implementations. This also creates friction
when Eclipse APIs need to interact with non-Eclipse APIs that use
either
the class library or their own custom implementations, introducing not
only the overhead of conversion but subtle bugs due to differences in
implementation.
In this case, the String-> URI -> String -> anything else
should generally avoid that.
There is also of course the bloat and
maintenance overhead of carrying
your own implementation. Overall I agree that java.net.URI lacks some
conveniences,
and can be maddeningly strict at times in its interpretation of the
RFC,
but I can live with it. I reimplemented the workspace using
java.net.URI
and found it to be a perfectly capable implementation once you learn
how
to use it.
It's not clear given what you've said, why you don't just use String?
When you need to manipulate it in detail, you create a structured
representation and when you're done, you turn it back a string...
John
I thought I would take a note to give my 'lessons
learned' summary from
the discussion to this point:
1) For implementation, URI is the obvious/natural choice.
IMHO the EMF URI impl is technically superior to java.net.URI
and
should be used for all impls
2) It's an open question as to whether *also* using IDs + extensible
Namespaces are worth the costs of abstraction. IMHO the needs vary
significantly by project:
p2: URI probably could be used in every place needed...as
it's
almost always resources (meta-data files) that are being referred
to....at least AFAIK
e4 connection framework: I'm of the opinion that using
URI *only*
for all connections would be doable-but-clumsy...and that it would make
sense to use ID's
with easy access to URIs for resources (e.g. IResourceID)
ECF: we will use IDs (interface) and EMF and/or java.net.URI
(Equinox/OSGi-available impl) so clients can use what makes sense for
them (resource-based or not)
3) Don't let your API get put in a competitive position with an API
done
by Ed 'Ice Man' Merks :). Actually, I hope it's clear to all that
ID/Namespace is *not* a competitive alternative to use of URI (whether
java or emf)...as clearly for resources some impl of URI/RFC 2396 is
the
way to go. But what I suppose I should have said more clearly up
front
is that ID/Namespace in *addition* to URI is a possible way to get both
some greater generality, and therefore supporting some use cases that
we
(ECF) have found important e.g. non-resource-based
connections/identifiers like user ids, service ids, channel ids, group
ids, etc.
Scott
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
|