Bug in kjas, behaviour of kjas vs plain java

Koos Vriezen koos.vriezen at xs4all.nl
Mon Sep 19 09:16:51 BST 2005


On Mon, Sep 19, 2005 at 09:25:35AM +0200, Stefan Brüns wrote:
> Am Montag, 19. September 2005 08:57 schrieb Koos Vriezen:
> > On Mon, Sep 19, 2005 at 02:47:12AM +0200, Stefan Brüns wrote:
> > > Hi,
> > >
> > > I found a difference of behaviour between kjas using kio and plain java.
> > >
> > > Although it is stated that the openConnection method of an
> > > java.net.URLConnection does not fetch any data from a server, it is also
> > > stated [1] that "Operations that depend on being connected, like
> > > getContentLength, will implicitly perform the connection, if necessary."
> > >
> > > I have attached a patch that will change this.
> >
> > Please don't use zip for diff files. Better to attach the plain text in
> > case the patch is small, like this time. That saves a reviewer to unzip
> > and open the file (and in case of a big patch, please consider
> > gzip/bzip2 because it's just a single file)
> 
> Using zipped files comes from my work as translator, unzipped utf-8 files 
> sometimes get mangled by stupid mail programs. And normally, I use bzip2, but 
> kmail "compression" option for attachments uses zip by default - hm ...

Yeah, blaim the mailer :-)

> > > Tested with http://www.petzall.se/daap/ (which now works), and many
> > > applets on sun's page (which worked already before).
> >
> > Looks ok, but why did you cache the exceptions? Also the check for
> > 'connected' is already done in the base class of KIOHttpConnection. Hmm,
> > should we also connect when connected+disconnected?
> 
> The exceptions have to be catched because of suns wisdom to make connect() 
> throw an exception, but let the methods implicitly calling connect() not to 
> throw any. Not catching gives a compiler error.
> 
> I chose to connect() only if not connected to avoid erronous debug messages. 
> As the documentation states, calling connect() when already connected does 
> nothing ("the call is ignored"), so this should be true for any overriding 
> classes, too.

That makes sense indeed. Ok, I'll apply it then.

Thanks,

Koos




More information about the kfm-devel mailing list