> On Thu, 3 May 2001, Morgan Delagrange wrote:
> > On Thu, 3 May 2001, Park, Sung-Gu wrote:
> >
> > > I'd like recommend you not to use java.net.URL class.
> > > It's confused develpers to use it related to the compatibility.
> > > The calss in JDK 1.x doesn't have the userinfo part.
> > > However, The class in JDK 2.x have the userinfo part.
> > > Perhaps, developers might expect to set credentails for
> > > HttpClient by using the class.
> > > So I recommend us to have the arguments of host, port and
> > > possibly path as String.
> > > (It's just like the user and password for credentials... )
> > > Actually, the class is just for parsing... not URLConnection. here...
> > >
> > > What do you guys think of my opinion? ;-)
> > >
> >
> > I take your point, but can't we simply note this in the JavaDocs? It
> > seems like many applications that use HttpClient will be working from
> > URLs, and it would be nice to support them in the interface with the
> > appropriate warnings.
> >
>
> I would suggest that HttpClient should, at a minimum, *support* the use of
> URLs as constructor arguments. Getting the syntax of a URL correct is
> something lots of Java developers do with string manipulations, and it
> causes untold numbers of bugs. I'm going to be going through the code for
> Tomcat and Struts to clean up the cases where I am currently doing this,
> to avoid future problems with funky things like IPv6 literal host
> addresses (which use ":" instead of "." to separate the components of the
> IP address.
Yes, I've seen the thread on IPv6, and it's a very good point.
Using URLs is very convinient indeed.
> Take string arguments if you want in alternative constructors -- just
> don't deprecate the URL based ones, please :-).
>
> > - Morgan
> >
> >
> >
>
> Craig
>
> PS: With regards to JDK 1.1 versus 1.2 -- is that really an
> issue? HttpClient is of course free to decide what the minimum platform
> it wants is, but I note that many/most of the Commons packages are
> starting with JDK 1.2 as a minimum platform.
I suppose we could add a requirement for JDK 1.2, or invoke the appropriate
methods through reflection.
Remy
