RFC: Netx - implement -Xclearcache command line option

Dr Andrew John Hughes ahughes at redhat.com
Thu Oct 7 14:33:12 PDT 2010

On 17:39 Wed 06 Oct     , Omair Majid wrote:


> >
> > Does it have to be called R and not 'translate' or something more readable?
> >
> I am sure we can change it to something more sensible. I was just 
> sticking with what the rest of Netx uses (there is already a R function 
> in the same class). Still, I would like to handle that in a separate 
> patch if it is ok.
> BTW, I am sure you know that a lot of programs use _ as the translate 
> function. Is _ a valid java identifier? ;)

Yeah, you can use '_', I just checked.  I presume you could also use $ but that's usually
reserved for autogenerated code.

I agree this is something to fix in a different patch.  I'm not too familiar
with the NetX code so these things come as a surprise to me :-)

> >>> Should we really be catching IOExceptions rather than allowing them to propogate?
> >>>
> >>
> >> Catching IOExceptions is just ignoring the errors. So the question is do
> >> we want to ignore the errors and continue on or should we stop if we hit
> >> any errors. Since the lock file is meant to stop a race condition
> >> (between deleting jars and using them) which is not likely to happen, I
> >> think an error in lock file creation should be ignored. If for some
> >> reason a lock file can not be created, Netx should not abort running the
> >> application. If you dont think this makes sense, please let me know and
> >> I will change it.
> >>
> >
> > That sounds sensible.  I'm just always wary of catch blocks.  I've seen them
> > used all too often to mask exceptions instead of handling them (including in
> > example code used by lecturers!)
> >
> Heh. That's true. I think checked exceptions even (sort of) encourage 
> this. I am afraid of swallowing exceptions too (or worse, handling them 
> at the wrong level), but in this particular instance it makes sense to 
> do just that.

Yeah I agree on that score.

> Thanks for looking over the changes.

No problem, please commit to the usual quartet of code trees.

> Cheers,
> Omair

Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint = F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

More information about the distro-pkg-dev mailing list