Re: r31993 - JavaHL Path.isUrl method

[Mark Phippard-3]

Dan,

Not sure if you have any plans for this method, but it is generally
not a good idea to use the java.net.URL class any more than necessary.
 When you construct the class doesn't it try to make a connection to
the URL?  It can make things very slow to use it.

--
Thanks

Mark Phippard
http://markphip.blogspot.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Mark Phippard-3]

On Thu, Jul 3, 2008 at 8:49 PM, Mark Phippard <markphip@...> wrote:

> Not sure if you have any plans for this method, but it is generally
> not a good idea to use the java.net.URL class any more than necessary.
>  When you construct the class doesn't it try to make a connection to
> the URL?  It can make things very slow to use it.

I also seem to recall this class does not consider svn:// a valid URL.
 Just the protocols it knows how to handle, like file:// and
http(s)://

--
Thanks

Mark Phippard
http://markphip.blogspot.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Talden]

> Not sure if you have any plans for this method, but it is generally
> not a good idea to use the java.net.URL class any more than necessary.
>  When you construct the class doesn't it try to make a connection to
> the URL?  It can make things very slow to use it.

It shouldn't do anything when creating the URL

  List<URL> list = new ArrayList<URL>();
  for(int i = 0 ; i < 1000; i++) list.add(new URL("http://some_domain/" + i));

That should execute much quicker than if it were testing the URL
validity for each create.

--
Talden

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Talden]

>> Not sure if you have any plans for this method, but it is generally
>> not a good idea to use the java.net.URL class any more than necessary.
>>  When you construct the class doesn't it try to make a connection to
>> the URL?  It can make things very slow to use it.
>
> I also seem to recall this class does not consider svn:// a valid URL.
>  Just the protocols it knows how to handle, like file:// and
> http(s)://

Correct.  You'd need to provide a handler for that protocol.

--
Talden

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Mark Phippard-3]

On Thu, Jul 3, 2008 at 9:01 PM, Talden <talden@...> wrote:

>> Not sure if you have any plans for this method, but it is generally
>> not a good idea to use the java.net.URL class any more than necessary.
>>  When you construct the class doesn't it try to make a connection to
>> the URL?  It can make things very slow to use it.
>
> It shouldn't do anything when creating the URL
>
>  List<URL> list = new ArrayList<URL>();
>  for(int i = 0 ; i < 1000; i++) list.add(new URL("http://some_domain/" + i));
>
> That should execute much quicker than if it were testing the URL
> validity for each create.

I think it depends on your JVM, possibly the supplier, definitely the
version.  Just Google it.  For example:

http://www.symphonious.net/2007/03/29/javaneturl-or-javaneturi/



--
Thanks

Mark Phippard
http://markphip.blogspot.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Daniel L. Rall]

On Thu, 03 Jul 2008, Mark Phippard wrote:

> Dan,
>
> Not sure if you have any plans for this method, but it is generally
> not a good idea to use the java.net.URL class any more than necessary.
>  When you construct the class doesn't it try to make a connection to
> the URL?  It can make things very slow to use it.

Mark, I used it in the patch I just sent to Alexander Kitaev for a problem
he turned up while using SVNKit (dev@ is CC'd on the discussion).

To the best of my knowledge, java.net.URL doesn't establish a network
connection until its openConnection() method is called, and I didn't notice
anything at odds with that expectation in its documention [1]. Do you know
something I don't?  :-)

This is a trivial method, so I'd be fine switching to any other
implementation which obeys the test case I provided (e.g. URI [2], perhaps?).
--

Daniel Rall

[1] http://java.sun.com/j2se/1.5.0/docs/api/java/net/URL.html
[2] http://java.sun.com/j2se/1.5.0/docs/api/java/net/URI.html

[Daniel L. Rall]

On Fri, 04 Jul 2008, Talden wrote:

> >> Not sure if you have any plans for this method, but it is generally
> >> not a good idea to use the java.net.URL class any more than necessary.
> >>  When you construct the class doesn't it try to make a connection to
> >> the URL?  It can make things very slow to use it.
> >
> > I also seem to recall this class does not consider svn:// a valid URL.
> >  Just the protocols it knows how to handle, like file:// and
> > http(s)://
>
> Correct.  You'd need to provide a handler for that protocol.

Retarded:

1) testPathIsURL(org.tigris.subversion.javahl.BasicTests)junit.framework.AssertionFailedError: 'svn://example.com' should be considered a URL
        at org.tigris.subversion.javahl.BasicTests.testPathIsURL(BasicTests.java:173)

Fixed in r31996.

Thanks, Dan

[Nick Crossley]

> On Thu, 03 Jul 2008, Mark Phippard wrote:
>
>> Dan,
>>
>> Not sure if you have any plans for this method, but it is generally
>> not a good idea to use the java.net.URL class any more than necessary.
>>  When you construct the class doesn't it try to make a connection to
>> the URL?  It can make things very slow to use it.
>
> Mark, I used it in the patch I just sent to Alexander Kitaev for a problem
> he turned up while using SVNKit (dev@ is CC'd on the discussion).
>
> To the best of my knowledge, java.net.URL doesn't establish a network
> connection until its openConnection() method is called, and I didn't notice
> anything at odds with that expectation in its documention [1]. Do you know
> something I don't?  :-)
>
> This is a trivial method, so I'd be fine switching to any other
> implementation which obeys the test case I provided (e.g. URI [2], perhaps?).

The hashcode() and equals() methods of java.net.URL resolve the hostname
with DNS, and so can also be blocking operations.

As others have said, in many cases the java.net.URI class is better if you
can do what you need with its methods.

Nick.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...