This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch: merge File.toURI() from Classpath


Hi,

On Wed, 2004-07-07 at 05:21, Stephen Crawley wrote:
> For the record, grep tells me that Sun's JDK 1.4.2 class libraries
> throws InternalError in 145 places.   Notwithstanding the wording of the
> InternalError javadoc, Sun uses it extensively for library errors. In a
> couple of cases, the comments that indicated that the developer thought
> that InternalError was the wrong exception ... but used it anyway.
> 
> On the other hand, grep tells me that JDK 1.4.2 throws RuntimeException
> in 157 places.

Quick note. As pointed out in the GNU Classpath Hacker Guide
http://www.gnu.org/software/classpath/docs/hacking.html#SEC2
Never under any circumstances refer to proprietary code while working on
GNU Classpath. GNU Classpath can be developed while just relying on free
software tools. Please make this as easy as possible for everybody and
just use only free software whenever you can.

Yes, I know that running grep over a bunch of source files isn't the
same as studying some proprietary implementation while working on a free
implementation like GNU Classpath. But we like to make it as clear and
easy as possible to avoid any confusion about whether or not people
hacking on GNU Classpath ever refer to proprietary implementations while
working on compatible free implementations. They don't. Keeping it that
simple means we don't have to open up a giant can of legal worms. It can
easily be kept closed.

Thanks,

Mark

BTW. FWIW. I think Chris has it right. The book by Joshua Bloch makes a
very good case. We should just define a ClasspathAssertionFailure that
extends RuntimeException and takes a cause (and/or string) as argument.
Then at every place we get an unexpected exception that should not
happen or some other pre/post condition failure inside the core
libraries that was never supposed to happen we throw this. It doesn't
even matter that much what another implementation does. We should do it
better and more consistent.

Attachment: signature.asc
Description: This is a digitally signed message part


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]