[cp-patches] FYI: RepaintManager optimization
I once more optimized the Swing RepaintManager to limit the amount of
painting work that is carried out by Swing. While observing painting
behaviour I noticed that sometimes (especially with overlapping
components) the painting is carried out in a 2-step manner, which
results in strange artifacts visible for a short time. This was caused
by an unfortunate ordering of the paint jobs. I adjusted this class in
the following way:
- Removed the use of working copies for invalidComponents and
dirtyComponents. Before, when the RepaintWorker job was dequeued from
the EventQueue, it swapped over the working copies with the real one,
itself working on the copies and allowing other threads to queue new
work requests in the empty working copies (which were then processed by
the next RepaintWorker). This is now implemented so that all threads
access the real structures and fine tuned synchronization.
- The ordering of the paint jobs is now done based on the sizes of the
damaged regions. Before it was ordered by the depth of the component in
the component hierarchy, which is similar but has different results when
rendering multiple-layered containers (see above -> 'two step
rendering'). Bigger damaged regions are painted first. This makes it
quite likely that all the smaller regions are painted with this request,
thus increasing overall performance. Imagine the smaller regions would
be painted first, and then the bigger regions that enclose the smaller
ones, this would result in the small regions painted twice or more often.
- The RepaintWorker has been marked 'dead' when it begins its work.
This had the bad effect that there could be more than one RepaintWorker
active on the EventQueue. This is not desired, I moved the
setLive(false) call to after the RepaintWorker finished it's job and
wrapped it up in a try{} finally{} clause to make sure it cleans up when
something in between fails.
2006-02-02 Roman Kennke <[EMAIL PROTECTED]>
* javax/swing/RepaintManager.java
Made fields private.
(RepaintWorker.run): Enclosed work stuff in try finally block in
order to clean up correctly if invalidation or painting fails,
otherwise we would get no more RepaintWorkers onto the EventQueue.
Also, now the RepaintWorker is marked 'dead' only after it has
finished its work, avoid more than one RepaintWorker on the queue.
(ComponentComparator.compareTo): Compare dirty rectangle sizes
instead of hierarchy depths.
(workDirtyComponents): Removed unused field.
(repaintOrder): Removed unused field.
(workRepaintOrder): Removed unused field.
(workInvalidComponents): Removed unused field.
(RepaintManager()): Removed initialization of removed fields.
(addInvalidComponent): Fine tuned synchronization.
(removeInvalidComponent): Fine tune synchronization.
(addDirtyRegion): Short circuit invalid dirty regions. Fine tuned
synchronization. Don't manager repaintOrder here.
(insertRepaintOrder): Removed method.
(markCompletelyClean): Fine tuned synchronization.
(validateInvalidComponents): Dont use a working copy of the
invalidComponents list, instead fine tuned synchronization on this
list. Also, don't search validateRoot, this is already done in
addInvalidComponent().
(paintDirtyRegions): Compute repaint order here, based on size of
damaged regions. Fine tuned synchronization. Avoid use of working
copies of dirtyComponent.
/Roman
Index: javax/swing/RepaintManager.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/RepaintManager.java,v
retrieving revision 1.22
diff -u -r1.22 RepaintManager.java
--- javax/swing/RepaintManager.java 27 Jan 2006 10:10:00 - 1.22
+++ javax/swing/RepaintManager.java 2 Feb 2006 21:13:26 -
@@ -62,6 +62,7 @@
* href="http://java.sun.com/products/jfc/tsc/articles/painting/index.html";>this
* document for more details.
*
+ * @author Roman Kennke ([EMAIL PROTECTED])
* @author Graydon Hoare ([EMAIL PROTECTED])
*/
public class RepaintManager
@@ -107,12 +108,18 @@
public void run()
{
- ThreadGroup threadGroup = Thread.currentThread().getThreadGroup();
- RepaintManager rm =
-(RepaintManager) currentRepaintManagers.get(threadGroup);
- setLive(false);
- rm.validateInvalidComponents();
- rm.paintDirtyRegions();
+ try
+{
+ ThreadGroup threadGroup = Thread.currentThread().getThreadGroup();
+ RepaintManager rm =
+(RepaintManager) currentRepaintManagers.get(threadGroup);
+ rm.validateInvalidComponents();
+ rm.paintDirtyRegions();
+}
+ finally
+{
+ setLive(false);
+}
}
}
@@ -135,41 +142,23 @@
* @param o1 the first component
* @param o2 the second component
*
- * @ret
Re: [cp-patches] java/security/KeyPairGenerator.java
On Thu, 2006-02-02 at 21:41 +1100, Raif S. Naffah wrote: > Currently KeyPairGenerator extends KeyPairGeneratorSpi, but the if > statement was testing for instanceof KeyPairGeneratorSpi before > KeyPairGenerator, and handling them differently (in terms of wrapper > classes). the patch corrects the test order. > > 2006-02-02 Raif S. Naffah <[EMAIL PROTECTED]> > > * java/security/KeyPairGenerator.java (getInstance): Test for > instanceof KeyPairGenerator before KeyPairGeneratorSpi. > > > ok to commit? Yes please. This looks like a obvious correct patch to me. Cheers. Mark signature.asc Description: This is a digitally signed message part
[cp-patches] Patch: DefaultStyledDocument
Another small fix. DefaultStyledDocument.ElementBuffer is working a
whole lot better now. There is two cases that still need to be fixed. I
hope to be done this by the weekend!!!
2006-02-02 Lillian Angel <[EMAIL PROTECTED]>
* javax/swing/text/DefaultStyledDocument.java
(insertUpdate): JoinNextDirection should push the
'next' paragraph on the stack.
Index: javax/swing/text/DefaultStyledDocument.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/text/DefaultStyledDocument.java,v
retrieving revision 1.56
diff -u -r1.56 DefaultStyledDocument.java
--- javax/swing/text/DefaultStyledDocument.java 2 Feb 2006 18:51:36 - 1.56
+++ javax/swing/text/DefaultStyledDocument.java 2 Feb 2006 19:28:11 -
@@ -727,7 +727,6 @@
createFracture(data);
i = 0;
}
-
// Handle each ElementSpec individually.
for (; i < data.length; i++)
{
@@ -753,7 +752,7 @@
case ElementSpec.JoinNextDirection:
// Push the next paragraph element onto the stack so
// future insertions are added to it.
- int ix = paragraph.getElementIndex(offset);
+ int ix = paragraph.getElementIndex(pos) + 1;
elementStack.push(paragraph.getElement(ix));
break;
default:
@@ -766,11 +765,11 @@
br = (BranchElement) createBranchElement(paragraph,
data[i].getAttributes());
e.added.add(br);
+ elementStack.push(br);
}
else
// need to add leaves to paragraph now
br = insertParagraph(paragraph, pos);
- elementStack.push(br);
break;
}
break;
[cp-patches] Patch: DefaultStyledDocument
Another fix for DefaultStyledDocument. These functions still need more
work.
2006-02-02 Lillian Angel <[EMAIL PROTECTED]>
* javax/swing/text/DefaultStyledDocument.java
(insertUpdate): Rewrote code for Originate. This prevents
leaves being created multiple times. If it is on the last
ElementSpec, the leaves need to be created right then;
otherwise, only a branch is created.
(insertContentTag): Rewrote to add new leaf directly if
this is a branch with no children. Otherwise, it
recreates the remainder of the tree as before.
Index: javax/swing/text/DefaultStyledDocument.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/text/DefaultStyledDocument.java,v
retrieving revision 1.55
diff -u -r1.55 DefaultStyledDocument.java
--- javax/swing/text/DefaultStyledDocument.java 1 Feb 2006 21:29:24 - 1.55
+++ javax/swing/text/DefaultStyledDocument.java 2 Feb 2006 18:48:42 -
@@ -757,9 +757,20 @@
elementStack.push(paragraph.getElement(ix));
break;
default:
- // Create a new paragraph and push it onto the stack.
- Element newParagraph = insertParagraph(paragraph, offset);
- elementStack.push(newParagraph);
+ Element br = null;
+ if (data.length > i + 1)
+{
+ // leaves will be added to paragraph later
+ int x = paragraph.getElementIndex(pos) + 1;
+ Edit e = getEditForParagraphAndIndex(paragraph, x);
+ br = (BranchElement) createBranchElement(paragraph,
+ data[i].getAttributes());
+ e.added.add(br);
+}
+ else
+// need to add leaves to paragraph now
+br = insertParagraph(paragraph, pos);
+ elementStack.push(br);
break;
}
break;
@@ -919,12 +932,13 @@
int len = tag.getLength();
int dir = tag.getDirection();
AttributeSet tagAtts = tag.getAttributes();
- int index = paragraph.getElementIndex(pos);
- Element target = paragraph.getElement(index);
- Edit edit = getEditForParagraphAndIndex(paragraph, index);
if (dir == ElementSpec.JoinNextDirection)
{
+ int index = paragraph.getElementIndex(pos);
+ Element target = paragraph.getElement(index);
+ Edit edit = getEditForParagraphAndIndex(paragraph, index);
+
if (paragraph.getStartOffset() > pos)
{
Element first = paragraph.getElement(0);
@@ -962,31 +976,42 @@
}
}
}
- else
+ else
{
int end = pos + len;
- Element leaf = createLeafElement(paragraph, tag.getAttributes(), pos,
- end);
- boolean onlyContent = true;
- BranchElement toRec = paragraph;
- if (!target.isLeaf())
-{
- onlyContent = false;
- toRec = (BranchElement) target;
-}
-
- if (pos > target.getStartOffset())
-index++;
+ Element leaf = createLeafElement(paragraph, tag.getAttributes(), pos, end);
- edit = getEditForParagraphAndIndex(paragraph, index);
- edit.addAddedElement(leaf);
-
- if (end != toRec.getEndOffset())
-recreateLeaves(end, toRec, onlyContent);
+ // Check for overlap with other leaves/branches
+ if (paragraph.getElementCount() > 0)
+{
+ int index = paragraph.getElementIndex(pos);
+ Element target = paragraph.getElement(index);
+ boolean onlyContent = target.isLeaf();
+
+ BranchElement toRec = paragraph;
+ if (!onlyContent)
+toRec = (BranchElement) target;
+
+ // Check if we should place the leaf before or after target
+ if (pos > target.getStartOffset())
+index++;
- // FIXME: this is not fully correct
- if (target.isLeaf())
-edit.addRemovedElement(target);
+ Edit edit = getEditForParagraphAndIndex(paragraph, index);
+ edit.addAddedElement(leaf);
+
+ if (end != toRec.getEndOffset())
+{
+ recreateLeaves(end, toRec, onlyContent);
+
+ if (onlyContent)
+edit.addRemovedElement(target);
+}
+}
+ else
+{
+ Edit edit = getEditForParagraphAndIndex(paragraph, paragraph.getElementCount());
+ edit.addA
[cp-patches] RFC: gnu.regexp.RETokenNamedProperty: Unicode block supported
ChangeLog
2006-02-02 Ito Kazumitsu <[EMAIL PROTECTED]>
* gnu/regexp/RETokenNamedProperty.java(getHandler): Check for
a Unicode block if the name starts with "In".
(UnicodeBlockHandler): New inner class.
Index: classpath/gnu/regexp/RETokenNamedProperty.java
===
RCS file: /cvsroot/classpath/classpath/gnu/regexp/RETokenNamedProperty.java,v
retrieving revision 1.2
diff -u -r1.2 RETokenNamedProperty.java
--- classpath/gnu/regexp/RETokenNamedProperty.java 1 Feb 2006 22:49:34
- 1.2
+++ classpath/gnu/regexp/RETokenNamedProperty.java 2 Feb 2006 16:28:58
-
@@ -148,7 +148,14 @@
return new POSIXHandler(name);
}
if (name.startsWith("In")) {
- throw new REException("Unicode block is not supported yet",
REException.REG_ESCAPE, 0);
+ try {
+ name = name.substring(2);
+ Character.UnicodeBlock block =
Character.UnicodeBlock.forName(name);
+ return new UnicodeBlockHandler(block);
+ }
+ catch (IllegalArgumentException e) {
+ throw new REException("Invalid Unicode block name: " + name,
REException.REG_ESCAPE, 0);
+ }
}
if (name.startsWith("Is")) {
name = name.substring(2);
@@ -275,4 +282,16 @@
return false;
}
}
+
+ private static class UnicodeBlockHandler extends Handler {
+ public UnicodeBlockHandler(Character.UnicodeBlock block) {
+ this.block = block;
+ }
+ private Character.UnicodeBlock block;
+ public boolean includes(char c) {
+ Character.UnicodeBlock cblock = Character.UnicodeBlock.of(c);
+ return (cblock != null && cblock.equals(block));
+ }
+ }
+
}
Re: [cp-patches] RFC: Datatypes library
Mark Wielaard wrote: This patch adds the RELAX NG pluggable datatypes library to Classpath. This API, and an implementation of it, will be used by the W3C XML Schema and RELAX NG JAXP validators currently in development. Please let me know how you feel about this. Could you explain a bit more how this will be used. I see javax.xml.validation.SchemaFactory.newInstance() has a big TODO and I assume you are working on an implementation of this. For which schema languages? I am personally working on a RELAX NG validator. I'm also in contact with someone else who is working on an XML Schema validator, but they haven't signed papers yet (and I haven't seen any code). And how does using this datatypes library fit into that implementation? The validators will use the datatypes library interface in order to look up datatypes by name. The datatype implementation will be responsible for validating just the datatype part of the overall schema. I have a datatype library implementation in development. It is currently based on the relaxngDatatype API. We would expose this package (indirectly) which is why I am a bit hesitant to say "great, go ahead". We could do like kaffe does in case it merges an external library and rename it to gnu.xml.org.relaxng.datatype, on the other hand this package has been stable for years so it is unlikely that a user wants to replace it with another version. Arguably, if we change the name we lose any benefit of being able to plug in a 3rd party datatype library implementation. It would be trivial to duplicate just the part of the API we need in a private namespace and use that for our own providers, but we would only be able to use our own implementation. My primary reason for including this API is that it is the current standard API. I believe that much as with JAXP itself, free software benefits by being able to interface with alternate implementations, to provide more choice and facilitate testing. I saw you already notified FSF legal of this and they checked the license to be compatible for inclusion. And adding it to external is the right thing to do. The only other thing needed would be to update the top-level LICENSE file when we decide to include this. Sure -- 犬 Chris Burdess "They that can give up essential liberty to obtain a little safety deserve neither liberty nor safety." - Benjamin Franklin PGP.sig Description: This is a digitally signed message part
[cp-patches] Re: RFC: gnu.regexp: Improved readability
From: Ito Kazumitsu <[EMAIL PROTECTED]>
Date: Wed, 01 Feb 2006 01:14:29 +0900 (JST)
> This change does not affect the functionality, but hopefully
> improves the readability of source codes.
>
> ChangeLog
> 2006-01-31 Ito Kazumitsu <[EMAIL PROTECTED]>
>
> * gnu/regexp/REMatch.java(REMatchList): New inner utility class
> for making a list of REMatch instances.
> * gnu/regexp/RETokenOneOf.java(match): Rewritten using REMatchList.
> * gnu/regexp/RETokenRepeated.java(findDoables): New method.
> (match): Rewritten using REMatchList.
> (matchRest): Rewritten using REMatchList.
Commited.
And this is the start of further work. My TODO list includes:
(1) Support Unicode character blocks in RETokenNamedProperty.
(2) Make the testcases of /^(b+?|a){1,2}?c/ and /(([a-c])b*?\2){3}/
in gnu/testlet/java/util/regex/Pattern/testdata2 pass.
This is really difficult.
(3) Support /(?<=X)/, /(?X)/
[cp-patches] java/security/KeyPairGenerator.java
hello there,
this small patch fixes a problem with the above.
Currently KeyPairGenerator extends KeyPairGeneratorSpi, but the if
statement was testing for instanceof KeyPairGeneratorSpi before
KeyPairGenerator, and handling them differently (in terms of wrapper
classes). the patch corrects the test order.
the ChangeLog entry follows:
2006-02-02 Raif S. Naffah <[EMAIL PROTECTED]>
* java/security/KeyPairGenerator.java (getInstance): Test for
instanceof KeyPairGenerator before KeyPairGeneratorSpi.
ok to commit?
cheers;
rsn
Index: KeyPairGenerator.java
===
RCS file: /cvsroot/classpath/classpath/java/security/KeyPairGenerator.java,v
retrieving revision 1.16
diff -u -r1.16 KeyPairGenerator.java
--- KeyPairGenerator.java 19 Jan 2006 09:51:53 - 1.16
+++ KeyPairGenerator.java 2 Feb 2006 09:39:11 -
@@ -173,15 +173,14 @@
}
KeyPairGenerator result = null;
-if (o instanceof KeyPairGeneratorSpi)
- {
- result = new DummyKeyPairGenerator((KeyPairGeneratorSpi) o, algorithm);
- }
-else if (o instanceof KeyPairGenerator)
+if (o instanceof KeyPairGenerator)
{
result = (KeyPairGenerator) o;
result.algorithm = algorithm;
}
+else if (o instanceof KeyPairGeneratorSpi)
+ result = new DummyKeyPairGenerator((KeyPairGeneratorSpi) o, algorithm);
+
result.provider = provider;
return result;
}
pgpyM3mGGEmnt.pgp
Description: PGP signature
[cp-patches] FYI: x5 game fix
During the recent changes the minor regression appeared in x5 game, but
from the analysis it seems that this is due removing one repaint that
should be redundant. The problem is fixed in the game itself, moving
repaint statement several lines below.
2006-02-02 Audrius Meskauskas <[EMAIL PROTECTED]>
* examples/gnu/classpath/examples/CORBA/swing/x5/PlayingDesk.java
(friendsMove):Call repaint() only after endOfGame is assigned.
Index: PlayingDesk.java
===
RCS file: /sources/classpath/classpath/examples/gnu/classpath/examples/CORBA/swing/x5/PlayingDesk.java,v
retrieving revision 1.1
diff -u -r1.1 PlayingDesk.java
--- PlayingDesk.java 15 Nov 2005 21:16:26 - 1.1
+++ PlayingDesk.java 2 Feb 2006 14:05:23 -
@@ -433,7 +433,6 @@
else
{
blacks.add(new Point(x, y));
-repaint();
if (victory != null)
{
@@ -447,7 +446,8 @@
frame.talk(Color.black, "Partner goes " + x + "-" + y
+ ". Your move?");
player.set_current_state(I_THINK);
- }
+ }
+repaint();
}
}
catch (RemoteException rex)
[cp-patches] default PRNG
hello there, this patch (except for gnu/java/security/key/dss/DSSKeyPairGenerator) replaces the new SecureRandom() occurrences with the use of an instance field (or in two cases where the class has only static methods, with a class field) set to an instance of a default PRNG (a seeded MDGenerator). Casey's concerns of using the PRNG Singleton originally used in GNU Crypto have been hopefully addressed by the use of local instances. the DSSKeyPairGenerator class in addition (i know it should have been a separate patch) adds a new (boolean) parameter to the generator used during its setup: STRICT_DEFAULTS. by default this is false, for backward compatibility. it's added to allow fulfilling a JCE requirement of throwing an exception when default parameters are requested but not available. the ChangeLog entry follows: 2006-02-02 Raif S. Naffah <[EMAIL PROTECTED]> * gnu/javax/crypto/sasl/srp/SRPServer.java (prng): New field. (getDefaultPRNG): New method. (parseO): Use method above. * gnu/javax/crypto/sasl/srp/SRPClient.java (prng): New field. (getDefaultPRNG): New method. (createO): Use method above. * gnu/javax/crypto/sasl/srp/KDF.java (prng): New class field. (nextByte): Use above field. * gnu/javax/crypto/pad/PKCS1_V1_5.java (selfTest): Use PRNG instance. * gnu/java/security/sig/rsa/RSA.java: New class field. (newR): Use above field * gnu/java/security/sig/rsa/EME_PKCS1_V1_5.java (prng): New field. (encode): Use field.above. * gnu/java/security/key/dss/FIPS186.java (prng): New field. (getDefaultPRNG): new method. (nextRandomBytes): Use above method. * gnu/java/security/key/rsa/RSAKeyPairGenerator.java: Likewise. * gnu/java/security/sig/BaseSignature.java: Likewise. * gnu/javax/crypto/key/dh/GnuDHKeyPairGenerator.java: Likewise. * gnu/javax/crypto/key/dh/RFC2631.java: Likewise. * gnu/javax/crypto/key/srp6/SRPKeyPairGenerator.java: Likewise. * gnu/javax/crypto/key/BaseKeyAgreementParty.java: Likewise. * gnu/java/security/key/dss/DSSKeyPairGenerator.java (prng): New field. (getDefaultPRNG): new method. (nextRandomBytes): Use above method. (STRICT_DEFAULTS): new class field. (USE_DEFAULTS): more documentation to clarify behavior. (setup): amended to handle new attribute. ok to commit? cheers; rsn Index: DSSKeyPairGenerator.java === RCS file: /cvsroot/classpath/classpath/gnu/java/security/key/dss/DSSKeyPairGenerator.java,v retrieving revision 1.1 diff -u -r1.1 DSSKeyPairGenerator.java --- DSSKeyPairGenerator.java 26 Jan 2006 02:25:10 - 1.1 +++ DSSKeyPairGenerator.java 2 Feb 2006 09:03:37 - @@ -41,6 +41,7 @@ import gnu.java.security.Registry; import gnu.java.security.hash.Sha160; import gnu.java.security.key.IKeyPairGenerator; +import gnu.java.security.util.PRNG; import java.io.PrintWriter; import java.math.BigInteger; @@ -88,10 +89,55 @@ /** Property name of the length (Integer) of the modulus (p) of a DSS key. */ public static final String MODULUS_LENGTH = "gnu.crypto.dss.L"; - /** Property name of the Boolean indicating wether or not to use defaults. */ + /** + * Property name of the Boolean indicating wether or not to use default pre- + * computed values of p, q and g for + * a given modulus length. The ultimate behaviour of this generator with + * regard to using pre-computed parameter sets will depend on the value of + * this property and of the following one [EMAIL PROTECTED] #STRICT_DEFAULTS}: + * + * + * If this property is [EMAIL PROTECTED] Boolean#FALSE} then this generator + * will accept being setup for generating parameters for any modulus length + * provided the modulus length is between 512 and + * 1024, and is of the form 512 + 64 * n. In + * addition, a new paramter set will always be generated; i.e. no pre- + * computed values are used. + * + * If this property is [EMAIL PROTECTED] Boolean#TRUE} and the value of + * [EMAIL PROTECTED] #STRICT_DEFAULTS} is also [EMAIL PROTECTED] Boolean#TRUE} then this generator + * will only accept being setup for generating parameters for modulus + * lengths of 512, 768 and 1024. Any + * other value, of the modulus length, even if between 512 and + * 1024, and of the form 512 + 64 * n, will cause + * an [EMAIL PROTECTED] IllegalArgumentException} to be thrown. When those modulus + * length (512, 768, and 1024) are + * specified, the paramter set is always the same. + * + * Finally, if this property is [EMAIL PROTECTED] Boolean#TRUE} and the value of + * [EMAIL PROTECTED] #STRICT_DEFAULTS} is [EMAIL PROTECTED] Boolean#FALSE} then this generator + * will behave as in point 1 above, except that it will use pre-computed + * values when possibl
Re: [cp-patches] RFC: Datatypes library
Hi Chris, On Tue, 2006-01-31 at 20:07 +, Chris Burdess wrote: > This patch adds the RELAX NG pluggable datatypes library to > Classpath. This API, and an implementation of it, will be used by the > W3C XML Schema and RELAX NG JAXP validators currently in development. > > Please let me know how you feel about this. Could you explain a bit more how this will be used. I see javax.xml.validation.SchemaFactory.newInstance() has a big TODO and I assume you are working on an implementation of this. For which schema languages? And how does using this datatypes library fit into that implementation? We would expose this package (indirectly) which is why I am a bit hesitant to say "great, go ahead". We could do like kaffe does in case it merges an external library and rename it to gnu.xml.org.relaxng.datatype, on the other hand this package has been stable for years so it is unlikely that a user wants to replace it with another version. I saw you already notified FSF legal of this and they checked the license to be compatible for inclusion. And adding it to external is the right thing to do. The only other thing needed would be to update the top-level LICENSE file when we decide to include this. Cheers, Mark signature.asc Description: This is a digitally signed message part
[cp-patches] FYI: Make AbstractCollection.toString() more robust
Hi,
This makes AbstractCollection.toString() more robust by only using the
Iterator (in case some subclass has a strange or expensive size()
implementation) and deals with collections directly containing
themselves.
2006-02-02 Mark Wielaard <[EMAIL PROTECTED]>
Fixes bug #25769 reported by Artemus Harper <[EMAIL PROTECTED]>
* java/util/AbstractCollection.java (toString): Only use Iterator,
check whether collection contains itself.
A Mauve test was added that passes with this patch.
Committed,
Mark
Index: java/util/AbstractCollection.java
===
RCS file: /cvsroot/classpath/classpath/java/util/AbstractCollection.java,v
retrieving revision 1.17
diff -u -r1.17 AbstractCollection.java
--- java/util/AbstractCollection.java 2 Jul 2005 20:32:41 - 1.17
+++ java/util/AbstractCollection.java 2 Feb 2006 13:23:56 -
@@ -423,7 +423,9 @@
* of the form "[a, b, ...]" where a and b etc are the results of calling
* toString on the elements of the collection. This implementation obtains an
* Iterator over the Collection and adds each element to a StringBuffer as it
- * is returned by the iterator.
+ * is returned by the iterator. "" is inserted when the collection
+ * contains itself (only works for direct containment, not for collections
+ * inside collections).
*
* @return a String representation of the Collection
*/
@@ -431,10 +433,16 @@
{
Iterator itr = iterator();
StringBuffer r = new StringBuffer("[");
-for (int pos = size(); pos > 0; pos--)
+boolean hasNext = itr.hasNext();
+while (hasNext)
{
-r.append(itr.next());
-if (pos > 1)
+Object o = itr.next();
+ if (o == this)
+ r.append("");
+ else
+ r.append(o);
+ hasNext = itr.hasNext();
+if (hasNext)
r.append(", ");
}
r.append("]");
signature.asc
Description: This is a digitally signed message part
Re: [cp-patches] Use gnu.java.security.jce.sig.DSSKeyPairGeneratorSpi for DSS/DSA
On Thursday 02 February 2006 02:42, Casey Marshall wrote: > On Jan 30, 2006, at 3:55 AM, Mark Wielaard wrote: > > Hi Raif, > > > > On Mon, 2006-01-30 at 19:57 +1100, Raif S. Naffah wrote: > >> this patch designates > >> gnu.java.security.jce.sig.DSSKeyPairGeneratorSpi > >> as the implementation of DSS (alias DSA), effectively crippling > >> gnu.java.security.provider.DSAKeyPairGenerator. > > > > I am not an expert on the different implementations of this > > algorithm. But if you and Casey agree on this and there are some > > test results that > > show no regressions then I would say go for it. > > One thing we should make sure of is that all keys returned by this > generator have `getEncoded' methods that return ASN.1 encoded data. > The key implementations already in GNU Classpath should all do this, > and IIRC, none of GNU Crypto's do. correct. none so far. cheers; rsn pgpZq6ZSJaRK0.pgp Description: PGP signature
Re: [cp-patches] RFC: Datatypes library
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Burdess wrote: > This patch adds the RELAX NG pluggable datatypes library to Classpath. > This API, and an implementation of it, will be used by the W3C XML > Schema and RELAX NG JAXP validators currently in development. [...] > Please let me know how you feel about this. I feel supergood :-D thanks Chris ;-) - -- Arnaud Vandyck ,= ,-_-. =. ((_/)o o(\_)) `-'(. .)`-' \_/ Java Trap: http://www.gnu.org/philosophy/java-trap.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD4gSA4vzFZu62tMIRAtTUAJ9BT4H9x/8vSdWcdT5nLr518vnVIwCgoXxm RC8lqdaJbxOjLyYAgnxFw/Y= =7ljt -END PGP SIGNATURE-
