Re: Parsing of URL's which contain Windows Path separator
Shirish, Oooh, I'm not sure that any change to URL of this kind would be compatible. It may have been desirable to have this kind of behavior when URL was being originally created, but it is a legacy class, now replaced with URI, and I'm not sure a change like this could be done in a way to preserve compatibility with existing code. -Chris On 20/08/12 16:04, Shirish Kuncolienkar wrote: Any thoughts on the following It will be good if the one could create relative url from other url which is based on windows style path. example "hello.html" relative "http://someserver/foo/bar"; becomes "http://someserver/foo/hello.html"; In the similar way "hello.html"relative to "file:///C:\foo\bar" can be resolved to "file:///C:/foo/hello.html" currently the URL parser resolves it to "file:hello.html" (this behavior is correct going by the api spec, since windows file separator character is considered as a special character)
hg: jdk8/tl/langtools: 7192744: fix up tests to accommodate jtreg spec change
Changeset: 37008b4cd97a Author:jjg Date: 2012-08-20 13:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/37008b4cd97a 7192744: fix up tests to accommodate jtreg spec change Reviewed-by: darcy ! test/tools/javac/processing/6348499/T6348499.java ! test/tools/javac/processing/T6920317.java
Parsing of URL's which contain Windows Path separator
Any thoughts on the following It will be good if the one could create relative url from other url which is based on windows style path. example "hello.html" relative "http://someserver/foo/bar"; becomes "http://someserver/foo/hello.html"; In the similar way "hello.html"relative to "file:///C:\foo\bar" can be resolved to "file:///C:/foo/hello.html" currently the URL parser resolves it to "file:hello.html" (this behavior is correct going by the api spec, since windows file separator character is considered as a special character)
Re: Http client API
On 17.08.2012 14:30, Michael McMahon wrote: On 09/08/12 19:15, Chris Hegarty wrote: Michael, Looking good, some comments. 1) Why the use of CookieManager, rather than CookieHandler? I would expect that CookieHandler would be a cleaner API CookieHandler is a very low level API, which doesn't offer much functionality beyond managing the cookies yourself, which is what you would have to do, if there were no cookie capabilities in the http api. So, I don't know what we would gain from using it. While CookieManager isn't perfect (and we'd like to suggest a few improvements) it is a higher level API that does take care of cookie management with some common policies pre-defined. java.net.CookieHandler is an abstract class, almost an interface, that represents everything an HTTP client needs to manage cookies. java.net.CookieManager is a concrete implementation of java.net.CookieHandler. At least that is the case in the current java.net.* design. That said, shouldn't new HttpClient depend on the more abstract java.net.CookieHandler, rather than the more concrete java.net.CookieManager, for the sake of API cleanness and extensibility? If one prefers java.net.CookieManager over java.net.CookieHandler, it is possible to use the former everywhere where the latter is expected, but not the other way around. As a side note, in the plugin environment, it might be more natural and less invasive to interface the browser cookie store via java.net.CookieHandler rather than java.net.CookieManager. FWIW, the current plug-in implementation, com.sun.deploy.net.cookie.DeployCookieSelector, does extend java.net.CookieHandler. Just my two cents. Thank you, -- Vasiliy
hg: jdk8/tl/jdk: 7191777: test/java/lang/ProcessBuilder/Basic.java failing intermittently due to additions for 4244896
Changeset: 59aa7660ade4 Author:robm Date: 2012-08-20 14:52 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/59aa7660ade4 7191777: test/java/lang/ProcessBuilder/Basic.java failing intermittently due to additions for 4244896 Reviewed-by: dholmes, alanb ! test/java/lang/ProcessBuilder/Basic.java
