Re: [p2-dev] URLs, URIs, and IDs (oh my) - summary

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

> 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 Windows devices and
archive URIs ("jar:file:/a!/" is not hierarchical but EMF's URI
says it is). The first deviation means that it won't properly handle file:
URIs on non-Windows platforms that have a segment containing the : character.
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.  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. 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().
 

We have a somewhat bad habit in Eclipse of reinventing
the wheel when we perceive the Java class library isn't good enough. 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.
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.

John

Scott Lewis <slewis@xxxxxxxxx>
Sent by: p2-dev-bounces@xxxxxxxxxxx

10/01/2008 07:05 PM

Please respond to
slewis@xxxxxxxxx; Please respond to
P2 developer discussions <p2-dev@xxxxxxxxxxx>

To	P2 developer discussions <p2-dev@xxxxxxxxxxx>
cc
Subject	Re: [p2-dev] URLs, URIs, and IDs (oh my) - summary

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