[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] URLs, URIs, and IDs (oh my) - summary


> 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