| Re: [p2-dev] URLs, URIs, and IDs (oh my) - summary |
|
John, Comments below. John Arthorne wrote: 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. 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...
|