RE: NotYetImplementedError [Was: NYIException]
Etienne Gagnon wrote: So, my proposal is: (1) Throw NotYetImplementedError extends Error (or LinkageError?) (2) Document clearly that users of Classpath SHOULD NOT catch this exception, but use System.getProperty(gnu.classpath.version) instead. (3) Document, in the VM interface, that such property should be set, of course. I fully support this proposal and I like the idea of extending LinkageError. Regards, Jeroen ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NotYetImplementedError [Was: NYIException]
Stephen, Do as you like. I do not want to fight on this. I think that my proposal is the best approach to (1) handle missing functionality in a way that will make life easier to users trying to run Java applications on classpath-based free vms amd (2) mimick the LinkageError usually expected in case of *unexpected* missing functionality (in contrast with *expected* missing functionality, indicated by UnsupportedOperationExcaprion). You seem to hold on your vision very strongly, and I am not ready to spend the effort to convince you. Etienne On Mon, Sep 29, 2003 at 02:32:49PM +1000, Stephen Crawley wrote: Stephen Crawley wrote: If no user is allowed to catch this new error/exception, why are we going to the bother of creating it in the first place?? So that, when a user runs his application on top of a Free jvm using Classpath, he can identify clearly missing functionality (at run time, at least). This is equally satisfied by throwing UnsupportedOperationException with a stereotypical message; e.g. throw new UnsupportedOperationException(not implemented yet - details) If the only reason for creating the new exception is as a documentation aid, then a better approach would be to throw UnsupportedOperationException with a stereotypical error message and or stereotypical javadoc description. No, because UnsupportedOperationException carries different semantics: it implies that the application was expecting some operation could be missing (as is the case with collections). I cannot see for the life of me where you are got this different semantics idea from. The documentation for the exception defines its semantics as: Thrown to indicate that the requested operation is not supported. That is it. Our usage would be entirely consistent with this. An unimplemented operation is (by definition) not supported because it is not implemented yet!! Even the Collections Framework javadocs say (typically) that the exception is thrown because (e.g.) xyz is not supported by this collection without necessarily saying why. See in my other message the example with JDK versions leading to LinkageError (not LinkageException extends UnsupportedOperationException). What is happening here is that you are calling a method that does not exist in the older JDK. If we want this effect, we should NOT provide skeleton implementations for missing methods at all. This would give a compilation error when the application is compiled against Classpath, and a LinkageError if the end user ran it the Classpath platform. (Not that I think this would be a good idea ... ) I think it is unreasonable to expect application developers to know which features where unimplemented / implemented in which versions of Classpath. IMO, this far more awkward than catching an exception. Not at all. A normal Java programmer should expect nothing. He should simply try to run his application, and if a NYIE happens, he should try to either: (1) implement the missing functionality (and contribute to classpath) (2) try to circumvent the missing functionality by using equivalent, but implemented, classes/methods. Huh? A moment ago you were suggesting that the application programmer should use properties containing Classpath version numbers and god-like awareness of which versions of Classpath implemented which methods. You were saying that this was easier to do than catching a NYIE. My comment was addressing this. Now you seem to be saying (?) that the application programmer shouldn't be writing his application to be aware of missing functionality at all?? Fine ... but then you've taken my remarks out of context. -- Steve ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NotYetImplementedError [Was: NYIException]
Etienne Gagnon wrote: Stephen, Do as you like. I do not want to fight on this. I think that my proposal is the best approach to (1) handle missing functionality in a way that will make life easier to users trying to run Java applications on classpath-based free vms amd (2) mimick the LinkageError usually expected in case of *unexpected* missing functionality (in contrast with *expected* missing functionality, indicated by UnsupportedOperationExcaprion). You seem to hold on your vision very strongly, and I am not ready to spend the effort to convince you. I'd agree with Etienne, I think his proposal is the best so far, but if Stephen and Per don't like it at all, let it be UnsupportedOperationException. I'd like to keep the 'please contribute to Classpath if this missing functionality' message though, so let's mandate using throw new UnsupportedOperationException(not yet implemented: + reason + gnu.classpath.Recruiting.CONTRIBUTE_PLEASE_MESSAGE); if that's o.k. with everyone. cheers, dalibor topic ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NotYetImplementedError [Was: NYIException]
Just a little note: On Mon, Sep 29, 2003 at 02:32:49PM +1000, Stephen Crawley wrote: I cannot see for the life of me where you are got this different semantics idea from. The documentation for the exception defines its semantics as: The semantic difference comes from the inheritance hierarchy. java.lang.Exception is documented as: The class Exception and its subclasses are a form of Throwable that indicates conditions that a reasonable application might want to catch. A reasonable application should not expect a standard method not to be yet implemented, IMHO. Etienne -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
Hi, I believe the functionality of @unimplemented would be adequately replaced by @since and throw new UnsupportedOperationException. To find out what methods of, e.g., JDK1.2 are unsupported, you can simply search for methods that have @since 1.2 and throw UnsupportedOperationException from their body. I don't see how @unimplemented or NotYetImplementedException would give extra information. The reason for not implementing the method could be explained in normal Javadoc comments, and this avoids generated documentation missing out this information, as would happen if one ran Sun Javadoc over a method with an @unimplemented tag, as far as I know. Regards, Ricky. On Fri, Sep 26, 2003 at 02:38:30PM +0200, Sascha Brawer wrote: What would you say about defining a special Javadoc tag, such as the following? /** * @unimplemented 1.4 Here comes some explanation. */ [class|method|field] It would not be too difficult to write a special doclet for the purpose of generating a document that summarizes the implementation status. Plus, it would be possible to document what exactly is not implemented, the reason, etc. The explanation text would also go into the generated documentation files. -- Sascha Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [really patch] Re: HashMap putAll/putAllInternal bug
Bryce McKinlay wrote:
size() is used here because, obviously, it is generally more efficient
to call it once rather than calling hasNext() many times. I believe that
the current implementation is within spec according to the collections
documentation. If your collections are returning an inaccurate size()
then I'd argue they are not valid implementations of Map.
Sure: as I noted, my argument is that Sun's implementation can handle
such invalid implementations of Map, so people might rely on it, as I did.
I could fix up my implementation of Map to guarantee that size() is
correct, but that would make this operation much *slower* than using
hasNext() would. To get an accurate size() out of my data structure
would require iterating across it fully every time size() is called.
Furthermore, I'd argue that the very existence of a hasNext() method
suggests that Sun didn't intend people to make this optimization. If
they expected that calling size() and maintaining your own counter would
always be more efficient, why didn't they just leave hasNext() out and
recommend coding that way?
Note too that our current implementations leave the collections in an
invalid state if next() causes a ConcurrentModificationException (or
other RuntimeException) part way through, because they set the size
variable in advance without waiting to ensure that all those elements
could in fact be added. It would be possible to fix this problem without
using hasNext(), and even if my patch isn't accepted I still think we
should at least fix that.
Of course, if there are real applications out there that rely on the way
Sun implements it, then we may have to change to using hasNext(). But we
should consider this carefully. If we must change it, then the
addAll/putAll implementations should change throughout the collections
classes for consistency - not just HashMap/Hashtable. As you noticed, in
some cases this could make things significantly less efficient.
Firstly, there is at least one real application that relies on this :)
If I could see a viable workaround, I'd modify nrdo to provide accurate
size() information so that Classpath wouldn't need to change (although I
still think that it's important to be bug-for-bug compatible with Sun's
implementation, so I'd still be in favor of this change even if I wasn't
personally relying on it). But in the case of my particular data
structure it's impossible to do that without slowing everything down,
and that isn't acceptable for my application.
I think it's perfectly possible to implement all our collections to give
the correct behavior without making things less efficient in the case
where size() is correct - at least, the only difference should be the
cost of repeated calls to hasNext() versus a single call to size(), and
the cost of hasNext() should *always* be small enough that that
difference falls into the realm of micro-optimization.
The example I gave was ArrayList: the optimization is to pre-allocate
space for size() worth of elements using ensureCapacity(), and then copy
elements directly into the backing array. It would be perfectly possible
to implement it something like this, which optimizes for when size() is
correct but is robust if it's not:
int csize = c.size();
ensureCapacity(size() + csize);
for (Iterator i = c.iterator(); csize-- 0 i.hasNext(); ) {
// put i.next() directly into the array and increment size,
// exactly as it's done now.
}
while (i.hasNext()) {
add(i.next()); // use the standard add method which will
// grow the array further if needed.
}
In this version, the for() loop checks i.hasNext() as well as csize so
that it's robust against the actual size being smaller than csize. The
while() loop uses a slower path for extra elements in case the actual
size is larger than csize(). And the only additional cost of this
algorithm is extra calls to hasNext(), which should always be cheap.
I don't think there are any ways where size() could be used as an
optimization that aren't susceptible to a similar approach - optimize
for the case where size() is correct, but still be prepared in case it's
not.
Stuart.
--
Stuart Ballard, Senior Web Developer
FASTNET - Web Solutions
(215) 283-2300, ext. 126
www.fast.net
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
NYIException
Hi all,
a surprising lot of emails have been sent about that matter. It seems that we
all agree on that throwing *something* would be better than what we have
currently. The attached class is a summary of what as far I understood from
the emails most people here wanted.
Personally, I had preferred some standardised information about the JDK
version that demands for the missing feature, but I didn't get the impression
that many of you support that idea.
Is there anybody who can't live with the attached proposal?
Cheers,
Andy.
--
aicas GmbH
Haid-und-Neu-Straße 18 * 76131 Karlsruhe
http://www.aicas.com
Tel: +49-721-663 968-24; Fax: +49-721-663 968-94
/* NotYetImplementedError.java -- Error signaling not yet implemented methods
Copyright (C) 2003 Free Software Foundation
This file is part of GNU Classpath.
GNU Classpath is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version.
GNU Classpath is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received a copy of the GNU General Public License
along with GNU Classpath; see the file COPYING. If not, write to the
Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307 USA.
Linking this library statically or dynamically with other modules is
making a combined work based on this library. Thus, the terms and
conditions of the GNU General Public License cover the whole
combination.
As a special exception, the copyright holders of this library give you
permission to link this library with independent modules to produce an
executable, regardless of the license terms of these independent
modules, and to copy and distribute the resulting executable under
terms of your choice, provided that you also meet, for each linked
independent module, the terms and conditions of the license of that
module. An independent module is a module which is not derived from
or based on this library. If you modify this library, you may extend
this exception to your version of the library, but you are not
obligated to do so. If you do not wish to do so, delete this
exception statement from your version. */
package gnu.classpath;
/**
* This Exception is used to signal that a particular method has not
* been implemented yet. The use of a specific exception throught the
* complete source code will help to localize and implement missing
* functionality.p
* Usage:
* codepre
* public notYetImplementeMethod()
*{
*throw new gnu.classpath.NotYetImplementedError();
*}
* /pre/code
*
*/
public class NotYetImplementedError extends Error
{
private static final String NYI =
This method has not yet been implemented in GNU Classpath.\n\n
+ The GNU Classpath project would appreciate receiving
+ an implementation for it.\n
+ If you intend to contribute, please take a look at
+ http://www.gnu.org/software/classpath/docs/hacking.html and
+ get in touch with other developers on [EMAIL PROTECTED];
/**
* Create new NotYetImplementedError.
*/
public NotYetImplementedError()
{
super(NYI);
}
/**
* Create new NotYetImplementedError with detailed message.
* @param message more detailed description.
*/
public NotYetImplementedError(String message)
{
super(message + \n + NYI);
}
}
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
RE: NYIException
Andrew Haley wrote: Andy Walter writes: a surprising lot of emails have been sent about that matter. It seems that we all agree on that throwing *something* would be better than what we have currently. The attached class is a summary of what as far I understood from the emails most people here wanted. I'm utterly baffled why you think that the attached class is appropriate. There was a disagreement as to whether a subclass of Error or of Exception is required. Last I heard, the promoters of Error threw in the towel. Howver, your class says Exception in the comments but Error in the code. I'm certainly not throwing in the towel ;-) I think it should be an error, but I can live with NYIException being an Exception, what I cannot accept is (ab)using UnsupportedOperationException. Regards, Jeroen ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: NYIException
Jeroen Frijters writes: Andrew Haley wrote: Andy Walter writes: a surprising lot of emails have been sent about that matter. It seems that we all agree on that throwing *something* would be better than what we have currently. The attached class is a summary of what as far I understood from the emails most people here wanted. I'm utterly baffled why you think that the attached class is appropriate. There was a disagreement as to whether a subclass of Error or of Exception is required. Last I heard, the promoters of Error threw in the towel. Howver, your class says Exception in the comments but Error in the code. I'm certainly not throwing in the towel ;-) I think it should be an error, but I can live with NYIException being an Exception, what I cannot accept is (ab)using UnsupportedOperationException. Out of interest (and please forgive me if this has already been discussed at length) why have dummy methods at all? Wouldn't it be better to have a compile time failure for unimplemented methods? Andrew. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: NYIException
Andrew Haley wrote: Out of interest (and please forgive me if this has already been discussed at length) why have dummy methods at all? Wouldn't it be better to have a compile time failure for unimplemented methods? I think so, but sometimes (e.g. when implementing interfaces or extending abstract classes), you're required to provide the methods, but I agree that not having the unimplemented method is the cleanest solution. Regards, Jeroen ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
Andrew Haley wrote: Out of interest (and please forgive me if this has already been discussed at length) why have dummy methods at all? Wouldn't it be better to have a compile time failure for unimplemented methods? One reason is that it makes it possible to compile code against Classpath that includes references to methods that Classpath hasn't yet implemented. This code might run just fine for the purpose you need it, because the unimplemented calls are in a codepath that you aren't taking. Another reason to have NYIError[1] is that in some cases a method may be implemented for some cases and not others, depending on its arguments. For example, a method might not have the correct behavior implemented as fallback for when one of its arguments is null, or might only work for particular subclasses of the class it's supposed to take as an argument. In that case, throwing the Error can be done conditionally, which is something that couldn't be replicated at compile time. Stuart. [1] yes, I vote for Error, FWIW, but I could live with anything that's a distinct class - ie not 'new RuntimeException(NYI)' - wherever it's placed in the Exception hierarchy. -- Stuart Ballard, Senior Web Developer FASTNET - Web Solutions (215) 283-2300, ext. 126 www.fast.net ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
Jeroen Frijters wrote: Andrew Haley wrote: Out of interest (and please forgive me if this has already been discussed at length) why have dummy methods at all? Wouldn't it be better to have a compile time failure for unimplemented methods? I think so, but sometimes (e.g. when implementing interfaces or extending abstract classes), you're required to provide the methods, but I agree that not having the unimplemented method is the cleanest solution. On the other hand, you can start writing the docs 'prototypes' for a class without having to fully implement everything. Depends on the point of view, I guess. And of course, there is the 'you can at least compile it using classpath, even if you can't run it' aspect, that plays a big role for debian and similar 'free software buildable by free tools' efforts, afaik. cheers, dalibor topic ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
Hi Andrew, On Monday 29 September 2003 19:40, Andrew Haley wrote: Throwing an appropriate message will help, of course, but one of the advantages of gcj is that you can pre-link and you know you won't get runtime linkage errors -- the linker has resolved everything. Having dummy implementations loses this gcj advantage. Dummy implementations that do nothing are a really bad thing, I agree. But a dummy implementation that either returns with the correct result or throws a NYIException makes it clear to the user what had happened. Currently, we have those dummy methods anyway - and can't get rid of them, because some methods are partly, but not completely, implemented. With a new Exception class, the gcj linker could stop with an error message when such a method is instantiated and thrown. If we abuse any existing JDK Exeption for it, this would not be possible. Cheers, Andy. -- aicas GmbH Haid-und-Neu-Straße 18 * 76131 Karlsruhe http://www.aicas.com Tel: +49-721-663 968-24; Fax: +49-721-663 968-94 ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: NYIException
Emile Snyder writes: On Mon, 2003-09-29 at 09:25, Andrew Haley wrote: Out of interest (and please forgive me if this has already been discussed at length) why have dummy methods at all? Wouldn't it be better to have a compile time failure for unimplemented methods? If you go this route what happens when code which was compiled elsewhere is run using the classpath libraries? I guess you'd get a LinkageError? Andrew. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
Andy Walter writes: Hi Andrew, On Monday 29 September 2003 19:40, Andrew Haley wrote: Throwing an appropriate message will help, of course, but one of the advantages of gcj is that you can pre-link and you know you won't get runtime linkage errors -- the linker has resolved everything. Having dummy implementations loses this gcj advantage. Dummy implementations that do nothing are a really bad thing, I agree. But a dummy implementation that either returns with the correct result or throws a NYIException makes it clear to the user what had happened. Currently, we have those dummy methods anyway - and can't get rid of them, because some methods are partly, but not completely, implemented. With a new Exception class, the gcj linker could stop with an error message when such a method is instantiated and thrown. Err, no. Linking happens at link time; throwing happens at runtime! But this gives me an idea. I can parse the class at compile time, and if I see any references to a method that throws such an exception I can warn the user about it. That would be *much* better. It wouldn't be complete because there might be partly implemented subclasses that aren't directly referenced, but it would be better than nothing. If we abuse any existing JDK Exeption for it, this would not be possible. True. Andrew. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: NYIException
On Mon, 2003-09-29 at 09:25, Andrew Haley wrote: Out of interest (and please forgive me if this has already been discussed at length) why have dummy methods at all? Wouldn't it be better to have a compile time failure for unimplemented methods? If you go this route what happens when code which was compiled elsewhere is run using the classpath libraries? lurkingly yours, -emile Andrew. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
Jeroen Frijters wrote: I'm certainly not throwing in the towel ;-) I think it should be an error, but I can live with NYIException being an Exception, what I cannot accept is (ab)using UnsupportedOperationException. I still don't see any real problem with UnsupportedOperationException, but I don't care that much. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
About stub methods
Hi, Please Stop arguing about how the framework for handling unimplemented classes and stub methods should work. I know it is the ideal What color should the Bike Shed have discussion (*), but stub methods are a bad thing to have and should just be treated as grave bugs. Having those method because they allow people to compile against GNU Classpath but not run against it really doesn't make much sense. Let people fix either their code or help us implement the missing functionality. If you find such a method in the source please just remove it and file a bug report about it (possibly with as bug message the partial implementation). Or better just implement it! If there really is a strong reason to have that particular method as a stub method then we should do that in the simplest possible way that makes it easy to quickly find those methods in the source. That means that it should be some standard string that people can easily grep for all on one line. Note that as said above making things compile, but not run with GNU Classpath is not a strong reason. So you should really be able to point to a free software program written in java that would just need one little stub method to be completely usable with GNU Classpath to justify having something as a stub method. The first person to actually volunteer to go through more then a handful of classes to remove (silent) stub methods gets to decide what the actual Not Implemented line says (and whether it is an Exception or an Error, an existing class or a new class). Who actually want to do this work? And if whole classes or packages are stubby then we are better off just removing them or at least add them to the lib/standard.omit file so they won't appear in our release till we can offer real functionality for them. Thanks, Mark (*) http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
About stub methods
Mark Wielaard writes: stub methods are a bad thing to have and should just be treated as grave bugs. Having those method because they allow people to compile against GNU Classpath but not run against it really doesn't make much sense. Let people fix either their code or help us implement the missing functionality. If you find such a method in the source please just remove it and file a bug report about it (possibly with as bug message the partial implementation). Hey, hey. I could not agree more. I thought this would be a hard thing for me to push, but it looks like I'd be pushing at an open door. No more stub methods! A pox on them! Andrew. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: About stub methods
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Montag, 29. September 2003 22:43 schrieb Andrew Haley: Mark Wielaard writes: stub methods are a bad thing to have and should just be treated as grave bugs. Having those method because they allow people to compile against GNU Classpath but not run against it really doesn't make much sense. Let people fix either their code or help us implement the missing functionality. If you find such a method in the source please just remove it and file a bug report about it (possibly with as bug message the partial implementation). Hey, hey. I could not agree more. I thought this would be a hard thing for me to push, but it looks like I'd be pushing at an open door. No more stub methods! A pox on them! Wow, I would have never thought that somebody could share my thoughts. In my beginnings of classpath and libgcj hacking I was a big fan of stubbed methods. But now I see that much methods can be stubbed easily and tools like japitools have a hard time to tell if the method is implemented or just a stub. I vote for no more stubs too. Michael - -- Homepage: http://www.worldforge.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/eKXVWSOgCCdjSDsRAkCJAJ9OXs27uAjFuiHfe+ojSETDd+WwPwCdEIeI muRpbxM4xz5UKVMjOZE5Cg8= =XRyM -END PGP SIGNATURE- ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
Jeroen Frijters wrote: I'm certainly not throwing in the towel ;-) I think it should be an error, but I can live with NYIException being an Exception, what I cannot accept is (ab)using UnsupportedOperationException. I still don't see any real problem with UnsupportedOperationException, but I don't care that much. I also can't see anything wrong with using UnsupportedOperationException. Could someone who thinks this would be abuse, please explain WHY they think so ... preferably with supporting evidence from the Sun javadocs. -- Steve ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
Jeroen Frijters wrote: I'm certainly not throwing in the towel ;-) I think it should be an error, but I can live with NYIException being an Exception, what I cannot accept is (ab)using UnsupportedOperationException. I still don't see any real problem with UnsupportedOperationException, but I don't care that much. I also can't see anything wrong with using UnsupportedOperationException. Could someone who thinks this would be abuse, please explain WHY they think so ... preferably with supporting evidence from the Sun javadocs. Please forget I wrote this. I'm happy for the discussion to die ... as per Mark's email. -- Steve ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: About stub methods
Mark Wielaard [EMAIL PROTECTED] writes: If you find such a method in the source please just remove it and file a bug report about it (possibly with as bug message the partial implementation). Please leave the stub methods in java.awt.peer.*/gnu.java.awt/peer.*, thanks. Feel free to make them do whatever you'd like. :) Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
