JaroslavTulach commented on pull request #3414:
URL: https://github.com/apache/netbeans/pull/3414#issuecomment-1007188894


   First of all I'd like to point out I have already approved your PR. The 
changes are sane and acceptable from some architecture perspective. My 
following comments are just result of viewing them from a different angle...
   
   > Let's get a little philosophical...
   
   Thanks for writing down your thoughts. Yes, I expected you had something 
like that in mind. You worked in 
[Systinet](https://en.wikipedia.org/wiki/Mercury_Interactive) where **URL**, 
**URI**, **URN** were essential. Your focus on the nuances between them is 
understandable.
   
   I also know that `mailto:` isn't technically URL. But for me `java.net.URL` 
is just a class, I have no mental problem to encode `mailto:` into 
`java.net.URL` and later throw an `org.openide.text.UserTypeSomeTextException`.
   
   I am more scared of duplicating the _existing_ API by a (95% similar) 
concept, just to be _pure_ and absolutely correct.
   
   >... goal is ... an ID ... images ... (without) ... the physical bits... URI 
is really an **identifier** ... URL allows to locate ... that's what 
`URLStreamHandler`s are for...invent an additional protocol, 'uidefaults' 
   
   From a point of Java programmer and maintainer (creator) of the previous 
(messy?) system, I'd call the **URI** vs. **URL** debate an unimportant 
difference and I'd just encode `UIDefaults` & co. images in `java.net.URL` and 
later throw an exception (or paint the icon into `data:`, if useful).
   
   > the protocol would not be probably registered - and the referenced bits 
are ephemeral.
   
   Yes, there are problems passing Java URLs into OS or browser. Each has its 
own set of handlers and the intersection is small (`http`, `file`, `ftp`?).
   
   > So IMHO there should have been URIs from the start 
   
   Indeed!
   
   However there was no `java.net.URI` when NetBeans started. The [java.net 
package](https://www.cs.princeton.edu/courses/archive/fall97/cs461/jdkdocs/api/Package-java.net.html)
 contained just `java.net.URL` and other APIs like 
[Class.getResource](https://www.cs.princeton.edu/courses/archive/fall97/cs461/jdkdocs/api/java.lang.Class.html#getResource(java.lang.String))
 used it to refer to other objects than just those on _World Wide Web_.
   
   If we started from scratch right now, I'd support your idea to use 
`java.net.URI`. However we have `java.net.URL` and I'd rather fit into existing 
design than complicate the conceptual area (from a Java programmer perspective) 
just because of little (philosophical) differences between **URL** and **URI**.
   
   > Does that explain the introduction - does it seem acceptable ? 
   
   Yes, your position is acceptable. It just leads to more complicated system. 
If we pretended **URI** could be represented by `java.net.URL` (as in the early 
days of Java), we'd get simpler result.
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Reply via email to