Re: NYIException
Michael Koch wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Freitag, 26. September 2003 19:29 schrieb Per Bothner: We discussed this in March, and there was agreement that we should use use UnsupportedOperationException. See http://gcc.gnu.org/ml/java/2003-03/msg00016.html Its never too late to rethink something. But unless one is aware of previous discussion (and even if one is), much time may be wasted. So far I haven't seen any reason why we need to re-consider the previous consensus. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [really patch] Re: HashMap putAll/putAllInternal bug
On Friday, Sep 26, 2003, at 06:26 Pacific/Auckland, Stuart Ballard
wrote:
@@ -709,10 +708,10 @@
void putAllInternal(Map m)
{
Iterator itr = m.entrySet().iterator();
-int msize = m.size();
-size = msize;
-while (msize-- > 0)
+size = 0;
+while (itr.hasNext())
{
+size++;
Map.Entry e = (Map.Entry) itr.next();
Object key = e.getKey();
int idx = hash(key);
Hi Stuart,
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.
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.
Regards
Bryce.
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Freitag, 26. September 2003 19:29 schrieb Per Bothner: > We discussed this in March, and there was agreement that we > should use use UnsupportedOperationException. > > See http://gcc.gnu.org/ml/java/2003-03/msg00016.html Its never too late to rethink something. Michael - -- Homepage: http://www.worldforge.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/dJpeWSOgCCdjSDsRAisAAJ0T/kIYtwVwRPMPWTovHxw6o5LrggCeOaqE M42w9sa6cjnT3onk+2aNBrQ= =sB5D -END PGP SIGNATURE- ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
We discussed this in March, and there was agreement that we should use use UnsupportedOperationException. See http://gcc.gnu.org/ml/java/2003-03/msg00016.html -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: NYIException
There is a semantic difference between something not supported, and something not implemented. There are iterators where I purposely throw an UnsupportedOperationException() for remove() because it would be impossible to do. That is very different from a NotYetImplementedException which tells the programmer that they should be able to do this, but not quite yet. Perhaps the default message for the NotYetImplementedException should be "patches welcome." --Avery -Original Message- From: Sascha Brawer [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2003 11:34 AM To: GNU Classpath Subject: Re: NYIException Hi Andy, >> [NotYetImplementedException] > [JavaDoc tag] > >Do you mean additionally to the exception or instead? With a JavaDoc tag (or some other convention for comments), there would be no need to distinguish between NotYetImplementedException_1_3, NotYetImplementedException_1_4, etc. I agree that some exception should be thrown. But it might suffice to just throw java.lang.UnsupportedOperationException. Not that I would oppose a special NotYetImplementedException. Living in a neutral country, I don't have an explicit opinion about such matters. :-) -- 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: NYIException
Hi Michael, On Friday 26 September 2003 17:56, Michael Koch wrote: > I'm for UnsupportedOperationException too because it exists already > and dont have to invent something new. > > A reason against using it is that some methods return UOE by design in > some situations. That means that i may not be clear in any case if > the method throwns an exception because its unimplementd or because > of other reasons. How about NotYetImplementedException extends UnsupportedOperationException then to distinguish between the above cases? IMHO, it would be quite useful for the project being able to say "we are able to run any JDK 1.2 programme". A script that has to know about which method might throw UnsupportedOperationException and which shouldn't could never be really reliable. 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Freitag, 26. September 2003 17:33 schrieb Sascha Brawer: > Hi Andy, > > >> [NotYetImplementedException] > > > > [JavaDoc tag] > > > >Do you mean additionally to the exception or instead? > > With a JavaDoc tag (or some other convention for comments), there > would be no need to distinguish between > NotYetImplementedException_1_3, NotYetImplementedException_1_4, > etc. > > I agree that some exception should be thrown. But it might suffice > to just throw java.lang.UnsupportedOperationException. Not that I > would oppose a special NotYetImplementedException. Living in a > neutral country, I don't have an explicit opinion about such > matters. :-) I'm for UnsupportedOperationException too because it exists already and dont have to invent something new. A reason against using it is that some methods return UOE by design in some situations. That means that i may not be clear in any case if the method throwns an exception because its unimplementd or because of other reasons. Michael - -- Homepage: http://www.worldforge.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/dGGqWSOgCCdjSDsRAvuNAKCMksQtOJr8Ga6eNjFeJiVYotBPygCfZgey l0YjZDXcnpIWl1fgrdSJlwY= =WQ/V -END PGP SIGNATURE- ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
Hi Andy, >> [NotYetImplementedException] > [JavaDoc tag] > >Do you mean additionally to the exception or instead? With a JavaDoc tag (or some other convention for comments), there would be no need to distinguish between NotYetImplementedException_1_3, NotYetImplementedException_1_4, etc. I agree that some exception should be thrown. But it might suffice to just throw java.lang.UnsupportedOperationException. Not that I would oppose a special NotYetImplementedException. Living in a neutral country, I don't have an explicit opinion about such matters. :-) -- Sascha Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Workshop Oct. 14
Hi all, as announced, there will be workshop for GNU Classpath developers on October 14 in Saarbrücken/Germany. Does anyone wish to discuss a specific topic, in addition to graphics? I'd like to prepare an agenda for the afternoon, so we can make most of the time. Best regards, -- Sascha Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
Hi Sascha, On Friday 26 September 2003 14:38, Sascha Brawer wrote: > >> > [NotYetImplementedException] > > What would you say about defining a special Javadoc tag, such as the > following? > > /** > * @unimplemented 1.4 Here comes some explanation. > */ > [class|method|field] Do you mean additionally to the exception or instead? I like the idea of using something like that additionally to the exception, but to me, it doesn't replace an exception because somebody whose programme doesn't work because of something missing in Classpath for sure has less trouble finding it if the method raises an exception. However, an unimplemented tag for giving more details about the missing code is a good idea. 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: [patch] Re: HashMap putAll/putAllInternal bug
Brian Jones wrote:
Cool, don't want to hold you up on that too much. Wondering how Sun's
impl makes a copy of the given Collection while avoiding copying an
object being modified in another thread. Anyone know? I think the
Iterators are supposed to throw exceptions when this occurs too.
I don't think this is affected too much either way by my patch. If
another thread is actively modifying the collection being added at the
time we're trying to add it, and it's not a thread-safe collection, the
results are undefined. If it *is* a thread-safe collection, the most
that's guaranteed is that you'll get a ConcurrentModificationException
in the right place.
(Actually, my patch probably helps with that case too: by only
incrementing this.size as each item is actually added, the state of the
Map is closer to valid if a ConcurrentModificationException is thrown
part-way through the iteration. Perhaps it could be tweaked to be even
better in that regard by putting the "size++" *after* the call to next()).
My patch really only affects what happens if the value returned by
size() is incorrect for a particular Map. Without the patch, Classpath
blindly believes size() and attempts to add exactly that many elements,
throwing an exception if there are actually less and not adding all of
them if there are actually more. With the patch, it relies on the
iterator to determine how many items there actually are.
I have a map where it's prohibitively expensive[1] to calculate the
correct value of size(). It would be possible, but a LOT of
collections-using code assumes that size() is fast - the very code that
this patch changes is an example, where it was assumed that calling
size() was much faster than calling hasNext() for each element and
therefore treated as an optimization. So the best I could do was to
cache a "best guess" at the size and return that from size(), and have
iterator() give the canonical information. On Sun's JDK, or on Classpath
with the patch, this works. Without it, it doesn't.
Stuart.
[1] A correct implementation of size() for my map would actually look
something like this:
public int size() {
int size = 0;
for (Iterator i = iterator(); i.hasNext(); ) {
i.next();
size++;
}
return size;
}
--
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
Andy Walter <[EMAIL PROTECTED]> wrote on Fri, 26 Sep 2003 12:50:20 +0200: >> > [NotYetImplementedException] >> >> Not sure we even need the extra exception type, just finding all the >> spots to throw the UnsupportedOperationException and doing that would >> probably be more than enough. > >The motivation is that, while we currently cannot even tell what methods are >missing, with such a NotYetImplementedException and subclasses >NotYetImplementedException_1_2, NotYetImplementedException_1_3, and >NotYetImplementedException_1_4 we would be able to write a script similar to >JAPI tools that gives an overview about how complete Classpath is according >to a certain JDK specification. We'd like to go through the classes and >annotate what features are not yet implemented (completely). When we do it >this way, it is no additional effort to annotate the corresponding >specification version, which will be some really valueable information in the >future. 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
Re: NYIException
Hi Brian, On Friday 26 September 2003 00:43, Brian Jones wrote: > > [NotYetImplementedException] > > Not sure we even need the extra exception type, just finding all the > spots to throw the UnsupportedOperationException and doing that would > probably be more than enough. The motivation is that, while we currently cannot even tell what methods are missing, with such a NotYetImplementedException and subclasses NotYetImplementedException_1_2, NotYetImplementedException_1_3, and NotYetImplementedException_1_4 we would be able to write a script similar to JAPI tools that gives an overview about how complete Classpath is according to a certain JDK specification. We'd like to go through the classes and annotate what features are not yet implemented (completely). When we do it this way, it is no additional effort to annotate the corresponding specification version, which will be some really valueable information in the future. 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
