Re: [cp-patches] FYI: major DefaultStyledDocument.ElementBuffer improvements
Hi Tony, On Tue, 2006-01-10 at 16:49 -0500, Anthony Balkissoon wrote: Work still needs to be done, the ElementBuffer.insertUpdate rewrite is not perfect yet, and DefaultStyledDocument.insertUpdate is correct (to my knowledge) but incomplete. 2006-01-10 Anthony Balkissoon [EMAIL PROTECTED] * javax/swing/text/DefaultStyledDocument.java: (ElementBuffer.insertUpdate): Rewritten to properly handle start and end tags. (ElementBuffer.insertFracture): New method. (ElementBuffer.insertContentTag): Removed unnecessary case for JoinFractureDirection - this only applies to start tags, not content tags. (insertUpdate): Corrected conditions for setting direction to JoinNextDirection. You have probably already seen this, but the autobuilder points out the following Mauve result changes after this patch. Baseline from: Tue Jan 10 21:03:00 UTC 2006 Regressions: FAIL: gnu.testlet.javax.swing.text.DefaultStyledDocument.ElementBuffer.ElementStructure4 (number 6) FAIL: gnu.testlet.javax.swing.text.DefaultStyledDocument.ElementBuffer.ElementStructure4 (number 8) FAIL: gnu.testlet.javax.swing.text.DefaultStyledDocument.ElementBuffer.ElementStructure6 (number 5) FAIL: gnu.testlet.javax.swing.text.DefaultStyledDocument.ElementBuffer.ElementStructure6 (number 6) FAIL: gnu.testlet.javax.swing.text.DefaultStyledDocument.ElementBuffer.insert: testEndTag3 (number 7) FAIL: gnu.testlet.javax.swing.text.DefaultStyledDocument.ElementBuffer.insert: testEndTag4 (number 12) Improvements: PASS: gnu.testlet.javax.swing.text.DefaultStyledDocument.ElementBuffer.ElementStructure6 (number 4) New fails: Totals: PASS: 25681 XPASS: 0 FAIL: 286 XFAIL: 0 signature.asc Description: This is a digitally signed message part ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] RFC: Hashtable cleanup
Roman == Roman Kennke [EMAIL PROTECTED] writes: Roman So, should I check this in? Yes, but... Roman +if (idx = 0) /* added this test to avoid Roman + * ArrayIndexOutOfBounds when Hashtable is Roman + * modified concurrently, return null in this Roman + * case. see test Roman + * com.aicas.jamaica.testlet.bugdb.JB00310.EnumerateAndModify Roman + * --Fridi. Roman + */ A few nits about this: we don't usually use long end-of-line comments, it would be better to have an inline comment before the test. Also we don't ordinarily mention people's names or reference test cases which aren't in Mauve. Could you put that test case in Mauve? That would be best since it would be run by the regular regression tester. Roman + * appear in the enumeration. The spec says nothing about this, but Roman + * the Java Class Libraries book infers that modifications to the This should be 'implies', not 'infers'. This occurs in a couple places. Tom ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] RFC: Hashtable cleanup
Hi Tom, Am Mittwoch, den 11.01.2006, 11:19 -0700 schrieb Tom Tromey: Roman == Roman Kennke [EMAIL PROTECTED] writes: Roman So, should I check this in? Yes, but... Roman + if (idx = 0) /* added this test to avoid Roman + * ArrayIndexOutOfBounds when Hashtable is Roman + * modified concurrently, return null in this Roman + * case. see test Roman + * com.aicas.jamaica.testlet.bugdb.JB00310.EnumerateAndModify Roman + * --Fridi. Roman + */ A few nits about this: we don't usually use long end-of-line comments, it would be better to have an inline comment before the test. Also we don't ordinarily mention people's names or reference test cases which aren't in Mauve. Whoops, this must have sneaked in somehow. In my actual sources I already removed these lines... Could you put that test case in Mauve? That would be best since it would be run by the regular regression tester. Sure. Roman + * appear in the enumeration. The spec says nothing about this, but Roman + * the Java Class Libraries book infers that modifications to the This should be 'implies', not 'infers'. This occurs in a couple places. Thank you for pointing this out. I'll adjust that. /Roman signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] Patch: DefaultStyledDocument fixlet
This fixes the ElementSpec Tag Type problem. Since the resolve parent
was being set; the attribute sets between ElementSpecs were not being
compared properly.
2006-01-11 Lillian Angel [EMAIL PROTECTED]
* javax/swing/text/DefaultStyledDocument.java
(toString): Shouldn't append the '' character here.
(createDefaultRoot): Should not set the resolve parent. This
causes problems when comparing attribute sets.
Index: javax/swing/text/DefaultStyledDocument.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/text/DefaultStyledDocument.java,v
retrieving revision 1.28
diff -u -r1.28 DefaultStyledDocument.java
--- javax/swing/text/DefaultStyledDocument.java 10 Jan 2006 21:47:14 - 1.28
+++ javax/swing/text/DefaultStyledDocument.java 11 Jan 2006 19:21:26 -
@@ -367,7 +367,6 @@
public String toString()
{
StringBuilder b = new StringBuilder();
- b.append('');
switch (type)
{
case StartTagType:
@@ -1342,7 +1341,6 @@
SectionElement section = new SectionElement();
BranchElement paragraph = new BranchElement(section, null);
-paragraph.setResolveParent(getStyle(StyleContext.DEFAULT_STYLE));
tmp = new Element[1];
tmp[0] = paragraph;
section.replace(0, 0, tmp);
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] RFC: gnu.regexp fix to allow ([(])
Hi Tom, On Tue, 2006-01-10 at 13:14 -0700, Tom Tromey wrote: Anyway, last night I was wondering whether there are regex test suites that we could reuse... like maybe from perl or Henry Spencer or something like that. There is the prce test-suite (. And Ziga turned that into a Mauve test. See gnu.testlet.java.util.regex.Pattern.pcrematches. It contains: It consists of three test suites, adapted from PCRE: - testdata1: tests that are currently passed by classpath - testdata2: tests that currently fail (disabled since they probably need to be reviewed) - testdata3: tests that use quoting constructs Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] RFC: gnu.regexp fix to allow ([(])
Mark == Mark Wielaard [EMAIL PROTECTED] writes: Mark There is the prce test-suite (. And Ziga turned that into a Mauve test. Sigh. I didn't even think to look first. Thanks. Tom ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] RFC: Hashtable cleanup
Hi Tom, I applied your suggested changes and committed the attached patch. I am going to commit the mentioned mauve test now. 2006-01-11 Roman Kennke [EMAIL PROTECTED] Reported by: Fridjof Siebert [EMAIL PROTECTED] * java/util/Hashtable.java (KEYS): Removed unneeded field. (VALUES): Removed unneeded field. (ENTRIES): Removed unneeded field. (keys): Return a KeyEnumerator instance. (elements): Returns a ValueEnumerator instance. (toString): Use an EntryIterator instance. (keySet): Return a KeyIterator instance. (values): Return a ValueIterator instance. (entrySet): Return an EntryIterator instance. (hashCode): Use EntryIterator instance. (rehash): Changed this loop to avoid redundant reads and make it obvious that null checking is not needed. (writeObject): Use EntryIterator instance. (HashIterator): Removed class. (Enumerator): Removed class. (EntryIterator): New class. (KeyIterator): New class. (ValueIterator): New class. (EntryEnumerator): New class. (KeyEnumerator): New class. (ValueEnumerator): New class. /Roman Am Mittwoch, den 11.01.2006, 11:19 -0700 schrieb Tom Tromey: Roman == Roman Kennke [EMAIL PROTECTED] writes: Roman So, should I check this in? Yes, but... Roman + if (idx = 0) /* added this test to avoid Roman + * ArrayIndexOutOfBounds when Hashtable is Roman + * modified concurrently, return null in this Roman + * case. see test Roman + * com.aicas.jamaica.testlet.bugdb.JB00310.EnumerateAndModify Roman + * --Fridi. Roman + */ A few nits about this: we don't usually use long end-of-line comments, it would be better to have an inline comment before the test. Also we don't ordinarily mention people's names or reference test cases which aren't in Mauve. Could you put that test case in Mauve? That would be best since it would be run by the regular regression tester. Roman + * appear in the enumeration. The spec says nothing about this, but Roman + * the Java Class Libraries book infers that modifications to the This should be 'implies', not 'infers'. This occurs in a couple places. Tom signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] FYI: More DefaultStyledDocument ElementBuffer fixes
This patch fixes more issues with the ElementBuffer.
2006-01-11 Anthony Balkissoon [EMAIL PROTECTED]
* javax/swing/text/DefaultStyledDocument.java:
(ElementBuffer.insertUpdate): Properly recreate Elements if the first
tag is an end tag. Avoid NPE by pushing the proper Element on to the
elementStack when there is a start tag with JoinNextDirection.
--Tony
Index: javax/swing/text/DefaultStyledDocument.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/text/DefaultStyledDocument.java,v
retrieving revision 1.29
diff -u -r1.29 DefaultStyledDocument.java
--- javax/swing/text/DefaultStyledDocument.java 11 Jan 2006 19:25:57 - 1.29
+++ javax/swing/text/DefaultStyledDocument.java 11 Jan 2006 20:04:00 -
@@ -785,18 +785,31 @@
if (data[0].getType() == ElementSpec.EndTagType)
{
// fracture deepest child here
- Element curr = getDefaultRootElement();
+ BranchElement paragraph = (BranchElement) elementStack.peek();
+ Element curr = paragraph.getParentElement();
int index = curr.getElementIndex(offset);
while (!curr.isLeaf())
{
index = curr.getElementIndex(offset);
curr = curr.getElement(index);
}
-
- Element newEl1 = createLeafElement(curr.getParentElement(),
+ Element parent = curr.getParentElement();
+ Element newEl1 = createLeafElement(parent,
curr.getAttributes(),
curr.getStartOffset(), offset);
- ((BranchElement) curr.getParentElement()).
+ Element grandParent = parent.getParentElement();
+ BranchElement nextBranch = (BranchElement) grandParent.getElement(grandParent.getElementIndex(parent.getEndOffset()));
+ Element firstLeaf = nextBranch.getElement(0);
+ while (!firstLeaf.isLeaf())
+{
+ firstLeaf = firstLeaf.getElement(0);
+}
+ BranchElement parent2 = (BranchElement) firstLeaf.getParentElement();
+ Element newEl2 = createLeafElement(parent2, firstLeaf.getAttributes(), offset, firstLeaf.getEndOffset());
+ parent2.replace(0, 1, new Element[] { newEl2 });
+
+
+ ((BranchElement) parent).
replace(index, 1, new Element[] { newEl1 });
}
@@ -812,9 +825,8 @@
insertFracture(data[i]);
break;
case ElementSpec.JoinNextDirection:
- Element parent = paragraph.getParentElement();
- int index = parent.getElementIndex(offset);
- elementStack.push(parent.getElement(index + 1));
+ int index = paragraph.getElementIndex(offset);
+ elementStack.push(paragraph.getElement(index));
break;
case ElementSpec.OriginateDirection:
Element current = (Element) elementStack.peek();
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] FYI: Another DefaultStyledDocument ElementBuffer fix
These changes to DefaultStyledDocument make all the local tests I have
here pass. I will commit these tests to Mauve now. The number one
outstanding problem with DefaultStyledDocument and ElementBuffer is the
way DocumentEvents are handled and marked up. Lillian is working on
that right now, hopefully we can have it sorted out before too long.
2006-01-11 Anthony Balkissoon [EMAIL PROTECTED]
* javax/swing/text/DefaultStyledDocument.java:
(ElementBuffer.insertContentTag): Don't adjust the structure here.
This will have been taken care of in insertFracture. Added a comment
explaining that we need to add edits to the DocumentEvent and that
this may be the place to do it.
--Tony
Index: javax/swing/text/DefaultStyledDocument.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/text/DefaultStyledDocument.java,v
retrieving revision 1.30
diff -u -r1.30 DefaultStyledDocument.java
--- javax/swing/text/DefaultStyledDocument.java 11 Jan 2006 20:07:24 - 1.30
+++ javax/swing/text/DefaultStyledDocument.java 11 Jan 2006 20:34:36 -
@@ -798,14 +798,19 @@
curr.getAttributes(),
curr.getStartOffset(), offset);
Element grandParent = parent.getParentElement();
- BranchElement nextBranch = (BranchElement) grandParent.getElement(grandParent.getElementIndex(parent.getEndOffset()));
+ BranchElement nextBranch =
+(BranchElement) grandParent.getElement
+ (grandParent.getElementIndex(parent.getEndOffset()));
Element firstLeaf = nextBranch.getElement(0);
while (!firstLeaf.isLeaf())
{
firstLeaf = firstLeaf.getElement(0);
}
BranchElement parent2 = (BranchElement) firstLeaf.getParentElement();
- Element newEl2 = createLeafElement(parent2, firstLeaf.getAttributes(), offset, firstLeaf.getEndOffset());
+ Element newEl2 =
+createLeafElement(parent2,
+ firstLeaf.getAttributes(),
+ offset, firstLeaf.getEndOffset());
parent2.replace(0, 1, new Element[] { newEl2 });
@@ -941,6 +946,9 @@
*/
private void insertFracture(ElementSpec tag)
{
+ System.out.println (BEFORE FRACTURE:);
+ printElements(getDefaultRootElement(), 0);
+
// This is the parent of the paragraph about to be fractured. We will
// create a new child of this parent.
BranchElement parent = (BranchElement) elementStack.peek();
@@ -1007,6 +1015,9 @@
parent.replace(parentIndex + 1, 0, new Element[] { newBranch });
// FIXME: Add the edits to the DocumentEvent via the addEdit method.
+
+ System.out.println (AFTER FRACTURE:);
+ printElements(getDefaultRootElement(), 0);
}
/**
@@ -1029,28 +1040,10 @@
}
else if (dir == ElementSpec.JoinNextDirection)
{
- BranchElement paragraph = (BranchElement) elementStack.peek();
- int currentIndex = paragraph.getElementIndex(offset);
- Element current = paragraph.getElement(currentIndex);
- Element next = paragraph.getElement(currentIndex + 1);
-
- if (next == null)
-return;
-
- Element newEl1 = createLeafElement(paragraph,
- current.getAttributes(),
- current.getStartOffset(),
- offset);
- Element newEl2 = createLeafElement(paragraph,
- current.getAttributes(),
- offset,
- next.getEndOffset());
-
- Element[] add = new Element[] { newEl1, newEl2 };
- Element[] remove = new Element[] { current, next };
- paragraph.replace(currentIndex, 2, add);
- // Add this action to the document event.
- addEdit(paragraph, currentIndex, remove, add);
+ // Doing nothing here gives us the proper structure.
+ // However, edits must be added to the document event.
+ // It is possible these should happen here, or also possible that
+ // they should happen in insertFracture.
}
else if (dir == ElementSpec.OriginateDirection)
{
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] DefaultStyledDocument insertFracture fix
Added the addEdit calls in insertFracture. Now, this correctly updates
the document structure when a fracture is inserted.
2006-01-11 Lillian Angel [EMAIL PROTECTED]
* javax/swing/text/DefaultStyledDocument.java
(insertFracture): Added calls to addEdit for each time a
structure is changed. addEdit is called on the newBranch,
previous, and parent structures.
Index: javax/swing/text/DefaultStyledDocument.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/text/DefaultStyledDocument.java,v
retrieving revision 1.31
diff -u -r1.31 DefaultStyledDocument.java
--- javax/swing/text/DefaultStyledDocument.java 11 Jan 2006 20:36:57 - 1.31
+++ javax/swing/text/DefaultStyledDocument.java 11 Jan 2006 20:46:43 -
@@ -997,21 +997,25 @@
Element[] newLeaves = new Element[numReplaced];
newLeaves[0] = firstLeafInNewBranch;
for (int i = 1; i numReplaced; i++)
-{
- newLeaves[i] = previous.getElement(previousIndex + i);
-}
+newLeaves[i] = previous.getElement(previousIndex + i);
newBranch.replace(0, 0, newLeaves);
-
+ addEdit(newBranch, 0, null, newLeaves);
+
// Now we remove the children after the offset from the previous
// paragraph. (Step 3).
- previous.replace(previousIndex,
- previous.getElementCount() - previousIndex,
- new Element[] { newPreviousLeaf });
+ int removeSize = previous.getElementCount() - previousIndex;
+ Element[] add = new Element[] { newPreviousLeaf };
+ Element[] remove = new Element[removeSize];
+ for (int j = 0; j removeSize; j++)
+remove[j] = previous.getElement(previousIndex + j);
+ previous.replace(previousIndex, removeIndex, add);
+ addEdit(previous, previousIndex, remove, add);
// Finally we add the new paragraph to the parent. (Step 5).
- parent.replace(parentIndex + 1, 0, new Element[] { newBranch });
-
- // FIXME: Add the edits to the DocumentEvent via the addEdit method.
+ Element[] nb = new Element[] { newBranch };
+ int index = parentIndex + 1;
+ parent.replace(index, 0, nb);
+ addEdit(parent, index, null, nb);
}
/**
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] Patch: RFC: remove InetAddress caching
I'm not checking this in yet -- I would like comments first.
I happened to run across the caching code in java.net.InetAddress
today. We had a couple discussions about this already in the past,
e.g. one is here:
http://gcc.gnu.org/ml/java/2000-04/msg00106.html
I still think this code is incorrect, as it doesn't respect TTL
properly. I would like to remove it, which is what this patch does.
Comments?
Tom
2006-01-11 Tom Tromey [EMAIL PROTECTED]
* java/net/InetAddress.java (DEFAULT_CACHE_SIZE): Removed.
(DEFAULT_CACHE_PERIOD, DEFAULT_CACHE_PURGE_PCT): Likewise.
(cache_size, cache_period, cache_purge_pct, cache): Likewise.
(static initializer): Removed cache code.
(checkCacheFor, addToCache): Removed.
(getAllByName): Removed cache code.
(lookup_time): Removed.
(InetAddress): Updated.
Index: java/net/InetAddress.java
===
RCS file: /cvsroot/classpath/classpath/java/net/InetAddress.java,v
retrieving revision 1.44
diff -u -r1.44 InetAddress.java
--- java/net/InetAddress.java 9 Jan 2006 18:39:22 - 1.44
+++ java/net/InetAddress.java 11 Jan 2006 21:08:17 -
@@ -43,7 +43,6 @@
import java.io.ObjectOutputStream;
import java.io.ObjectStreamException;
import java.io.Serializable;
-import java.util.HashMap;
import java.util.StringTokenizer;
/**
@@ -66,22 +65,6 @@
private static final long serialVersionUID = 3286316764910316507L;
/**
- * The default DNS hash table size,
- * Use a prime number happy with hash table.
- */
- private static final int DEFAULT_CACHE_SIZE = 89;
-
- /**
- * The default caching period in minutes.
- */
- private static final int DEFAULT_CACHE_PERIOD = 4 * 60;
-
- /**
- * Percentage of cache entries to purge when the table gets full.
- */
- private static final int DEFAULT_CACHE_PURGE_PCT = 30;
-
- /**
* The special IP address INADDR_ANY.
*/
private static InetAddress inaddr_any;
@@ -96,50 +79,8 @@
*/
static InetAddress LOCALHOST;
- /**
- * The size of the cache.
- */
- private static int cache_size = 0;
-
- /**
- * The length of time we will continue to read the address from cache
- * before forcing another lookup.
- */
- private static int cache_period = 0;
-
- /**
- * What percentage of the cache we will purge if it gets full.
- */
- private static int cache_purge_pct = 0;
-
- /**
- * HashMap to use as DNS lookup cache.
- * Use HashMap because all accesses to cache are already synchronized.
- */
- private static HashMap cache;
-
static
{
-// Look for properties that override default caching behavior
-cache_size =
- Integer.getInteger(gnu.java.net.dns_cache_size, DEFAULT_CACHE_SIZE)
- .intValue();
-cache_period =
- Integer.getInteger(gnu.java.net.dns_cache_period,
- DEFAULT_CACHE_PERIOD * 60 * 1000).intValue();
-
-cache_purge_pct =
- Integer.getInteger(gnu.java.net.dns_cache_purge_pct,
- DEFAULT_CACHE_PURGE_PCT).intValue();
-
-// Fallback to defaults if necessary
-if ((cache_purge_pct 1) || (cache_purge_pct 100))
- cache_purge_pct = DEFAULT_CACHE_PURGE_PCT;
-
-// Create the cache
-if (cache_size != 0)
- cache = new HashMap(cache_size);
-
// precompute the ANY_IF address
try
{
@@ -174,11 +115,6 @@
String hostName;
/**
- * The time this address was looked up.
- */
- transient long lookup_time;
-
- /**
* The field 'family' seems to be the AF_ value.
* FIXME: Much of the code in the other java.net classes does not make
* use of this family field. A better implementation would be to make
@@ -200,8 +136,6 @@
addr = (null == ipaddr) ? null : (byte[]) ipaddr.clone();
hostName = hostname;
-lookup_time = System.currentTimeMillis();
-
family = 2; /* AF_INET */
}
@@ -660,12 +594,6 @@
return addresses;
}
-// Check the cache for this host before doing a lookup
-addresses = checkCacheFor(hostname);
-
-if (addresses != null)
- return addresses;
-
// Not in cache, try the lookup
byte[][] iplist = VMInetAddress.getHostByName(hostname);
@@ -682,71 +610,10 @@
addresses[i] = new Inet4Address(iplist[i], hostname);
}
-addToCache(hostname, addresses);
return addresses;
}
/**
- * This method checks the DNS cache to see if we have looked this hostname
- * up before. If so, we return the cached addresses unless it has been in the
- * cache too long.
- *
- * @param hostname The hostname to check for
- *
- * @return The InetAddress for this hostname or null if not available
- */
- private static synchronized InetAddress[] checkCacheFor(String hostname)
- {
-InetAddress[] addresses = null;
-
-if (cache_size == 0)
- return null;
-
-Object obj = cache.get(hostname);
-if (obj ==
Re: [cp-patches] Patch: RFC: remove InetAddress caching
Tom Tromey wrote: I'm not checking this in yet -- I would like comments first. I happened to run across the caching code in java.net.InetAddress today. We had a couple discussions about this already in the past, e.g. one is here: http://gcc.gnu.org/ml/java/2000-04/msg00106.html I still think this code is incorrect, as it doesn't respect TTL properly. I would like to remove it, which is what this patch does. Sounds good to me. Let the upstream DNS server do the caching, that's what it's there for. Or, at least, this reverts to doing the correct and conservative thing while the correct and optimized thing is being worked on. What we have now is incorrect and optimized :-) -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Patch: RFC: remove InetAddress caching
Tom Tromey wrote: I'm not checking this in yet -- I would like comments first. I happened to run across the caching code in java.net.InetAddress today. We had a couple discussions about this already in the past, e.g. one is here: http://gcc.gnu.org/ml/java/2000-04/msg00106.html I still think this code is incorrect, as it doesn't respect TTL properly. I would like to remove it, which is what this patch does. Comments? I agree. The standard C library takes care of DNS caching (via nscd) on most systems, so this extra cache would have no added benefit. David Daney. ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-testresults] FAIL: ecj built with native-ecj on Wed Jan 11 11:38:55 UTC 2006
xargs: ../ecj-gcj-build/ecj: No such file or directory ___ Classpath-testresults mailing list Classpath-testresults@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-testresults
[cp-testresults] Japi diffs for classpath-generics
Japi diff jdk12 vs classpath-generics: Full results: http://www.kaffe.org/~stuart/japi/htmlout/h-jdk12-classpath-generics.html Changes since last run: -Comparison run at Tue Jan 10 10:48:51 2006 GMT -jdk12 API scanned at 2006/01/10 05:19:58 EST -classpath-generics API scanned at 2006/01/10 05:36:22 GMT +Comparison run at Wed Jan 11 10:56:02 2006 GMT +jdk12 API scanned at 2006/01/11 05:22:48 EST +classpath-generics API scanned at 2006/01/11 06:12:07 GMT -javax.swing.plaf.metal: 99.33% good, 0.33% minor, 0.04% bad +javax.swing.plaf.metal: 99.38% good, 0.33% minor -javax.swing.text: 91.76% good, 0.02% minor, 7.69% missing -javax.swing.text.html: 37.62% good, 0.11% minor, 62.15% missing +javax.swing.text: 99.24% good, 0.02% minor, 0.21% missing +javax.swing.text.html: 67.39% good, 0.39% minor, 32.04% missing -Total: 97.6% good, 0.1% minor, 0% bad, 1.83% missing +Total: 98.69% good, 0.11% minor, 0% bad, 0.74% missing -Classes: 84 minor, 1 bad, 31 missing. +Classes: 89 minor, 9 missing. -Methods: 21 missing. -Constructors: 1 bad, 2 missing. +Methods: 11 missing. -class javax.swing.JTable.AccessibleJTable: SerialVersionUID=-6365751089784223338 in jdk12, but SerialVersionUID=5523611364255989512 in classpath-generics +class javax.swing.JTable.AccessibleJTable: SerialVersionUID=-6365751089784223338 in jdk12, but SerialVersionUID=2188082834587403049 in classpath-generics -Bad -class javax.swing.plaf.metal.MetalSplitPaneDivider.MetalDividerLayout: public in jdk12, but protected in classpath-generics -constructor javax.swing.plaf.metal.MetalSplitPaneDivider.MetalDividerLayout(): public in jdk12, but protected in classpath-generics -class javax.swing.text.TableView: missing in classpath-generics -class javax.swing.text.TableView.TableCell: missing in classpath-generics -class javax.swing.text.TableView.TableRow: missing in classpath-generics -method javax.swing.text.DefaultStyledDocument.ElementBuffer.remove(int, int, javax.swing.text.AbstractDocument.DefaultDocumentEvent): missing in classpath-generics -method javax.swing.text.DefaultStyledDocument.ElementBuffer.removeUpdate(): missing in classpath-generics -class javax.swing.text.html.HTMLDocument: SerialVersionUID=-1076860967958940390 in jdk12, but SerialVersionUID=612900659574529278 in classpath-generics +class javax.swing.text.html.HTMLDocument: SerialVersionUID=-1076860967958940390 in jdk12, but SerialVersionUID=-6789066012759312188 in classpath-generics +class javax.swing.text.html.HTMLEditorKit.InsertHTMLTextAction: SerialVersionUID=-9158204689171292745 in jdk12, but SerialVersionUID=8491442471493677377 in classpath-generics +class javax.swing.text.html.HTMLEditorKit.LinkController: SerialVersionUID=5550751845809381313 in jdk12, but SerialVersionUID=-3834885387784676386 in classpath-generics +class javax.swing.text.html.StyleSheet: SerialVersionUID=-7781614701489262374 in jdk12, but SerialVersionUID=4099695163189825191 in classpath-generics +class javax.swing.text.html.StyleSheet.BoxPainter: SerialVersionUID=-2341273814353368961 in jdk12, but SerialVersionUID=6448105512189632446 in classpath-generics +class javax.swing.text.html.StyleSheet.ListPainter: SerialVersionUID=-6734326331044992547 in jdk12, but SerialVersionUID=4520374085019142534 in classpath-generics -class javax.swing.text.html.BlockView: missing in classpath-generics -class javax.swing.text.html.HTMLDocument.HTMLReader: missing in classpath-generics -class javax.swing.text.html.HTMLDocument.HTMLReader.BlockAction: missing in classpath-generics -class javax.swing.text.html.HTMLDocument.HTMLReader.CharacterAction: missing in classpath-generics -class javax.swing.text.html.HTMLDocument.HTMLReader.FormAction: missing in classpath-generics -class javax.swing.text.html.HTMLDocument.HTMLReader.HiddenAction: missing in classpath-generics -class javax.swing.text.html.HTMLDocument.HTMLReader.IsindexAction: missing in classpath-generics -class javax.swing.text.html.HTMLDocument.HTMLReader.ParagraphAction: missing in classpath-generics -class javax.swing.text.html.HTMLDocument.HTMLReader.PreAction: missing in classpath-generics -class javax.swing.text.html.HTMLDocument.HTMLReader.SpecialAction: missing in classpath-generics -class javax.swing.text.html.HTMLDocument.HTMLReader.TagAction: missing in classpath-generics -class javax.swing.text.html.HTMLDocument.RunElement: missing in classpath-generics -class javax.swing.text.html.HTMLEditorKit.HTMLFactory: missing in classpath-generics -class javax.swing.text.html.HTMLEditorKit.HTMLTextAction: missing in classpath-generics -class javax.swing.text.html.HTMLEditorKit.InsertHTMLTextAction: missing in classpath-generics -class javax.swing.text.html.HTMLEditorKit.LinkController: missing in classpath-generics -class javax.swing.text.html.StyleSheet: missing in classpath-generics -class javax.swing.text.html.StyleSheet.BoxPainter: missing in classpath-generics -class javax.swing.text.html.StyleSheet.ListPainter: missing in
[cp-testresults] FAIL: regressions for mauve-jamvm on Wed Jan 11 18:14:08 UTC 2006
Baseline from: Tue Jan 10 21:03:00 UTC 2006 Regressions: FAIL: gnu.testlet.javax.swing.text.DefaultStyledDocument.ElementBuffer.ElementStructure4 (number 6) FAIL: gnu.testlet.javax.swing.text.DefaultStyledDocument.ElementBuffer.ElementStructure4 (number 8) FAIL: gnu.testlet.javax.swing.text.DefaultStyledDocument.ElementBuffer.ElementStructure6 (number 5) FAIL: gnu.testlet.javax.swing.text.DefaultStyledDocument.ElementBuffer.ElementStructure6 (number 6) FAIL: gnu.testlet.javax.swing.text.DefaultStyledDocument.ElementBuffer.insert: testEndTag3 (number 7) FAIL: gnu.testlet.javax.swing.text.DefaultStyledDocument.ElementBuffer.insert: testEndTag4 (number 12) Improvements: PASS: gnu.testlet.javax.swing.text.DefaultStyledDocument.ElementBuffer.ElementStructure6 (number 4) New fails: Totals: PASS: 25681 XPASS: 0 FAIL: 286 XFAIL: 0 ___ Classpath-testresults mailing list Classpath-testresults@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-testresults
Re: SecurityManager troubles
Guilhem Lavaux wrote: I have stumbled across a bug probably shared by all VMs using GNU Classpath. In Apache Ant a SecurityManager is installed to be able to execute java application without forking the VM. Thanks to the SM exiting a VM is forbidden and so ant is protected from the applications using System.exit(). However it causes us some troubles for the cases where we have not pre-loaded some core classes such as java.security.Permission/java.security.Security (and probably some other). I have attached with this email a testcase which summarises quite well the situation. I found the same problem in Mauve. This is the thread: http://lists.gnu.org/archive/html/classpath/2005-12/msg00034.html My workaround was basically the same as yours: http://sources.redhat.com/ml/mauve-patches/2006/msg4.html 3) One solution of the problem is to load some core classes. But it will appear quite soon that some other classes may also be loaded for really wicked applications. It is a limitative solution and I would not support it. Yes. Exactly which classes need loading depends on exactly what your custom checkPermission is doing. We can, of course, make sure we have the classes we need for the default checkPermission, but that doesn't seem complete somehow. 4) Another solution is to make a special case for selected core packages. In that case the class loader will bypass security verifications. This is a variant of 3 but less limitative and it does not force us to preload classes. I have a suspicion that the proprietary JVMs must do something like this... Cheers, Gary ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RE: SecurityManager troubles
On Wed, 2006-01-11 at 08:45 +0100, Jeroen Frijters wrote: After fixing some IKVM specific bugs, I was able to run the testcase succesfully with only the attached GNU Classpath fix. Can you please see if this patch improves things for you as well? No, same StackOverFlow with jamvm or cacao. TWISTI ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RE: SecurityManager troubles
Gary Benson wrote: Guilhem Lavaux wrote: 3) One solution of the problem is to load some core classes. But it will appear quite soon that some other classes may also be loaded for really wicked applications. It is a limitative solution and I would not support it. Yes. Exactly which classes need loading depends on exactly what your custom checkPermission is doing. We can, of course, make sure we have the classes we need for the default checkPermission, but that doesn't seem complete somehow. I must say that I don't understand this problem. Shouldn't the boot class loader be able to load classes regardless of the SecurityManager? It would seem to me that VMs that can't do that are broken and that this is not a Classpath problem. Regards, Jeroen ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RMI and java.rmi.server.hostname
Hello everyone,
I've been experimenting a little with RMI and GNU Classpath and ran into
troubles when client and server were running on different machines. In
my setup the client hercules is trying to access a UnicastRemoteObject
on the server galahad. The client is able to receive the corresponding
stub, but it is misconfigured so that it tries to access the remote
object on localhost instead of the real server. Using Sun's JRE on the
server I could solve the problem by setting the system property
java.rmi.server.hostname to galahad. Unfortunately this failed when
using GNU Classpath and Kaffe or JamVM on the server. The stubs were
still trying to access localhost.
Currently I meet the problem by modifying the static constructor of
gnu.java.rmi.server.UnicastConnectionManager, so that the static field
localhost is initialized with the value of the
java.rmi.server.hostname property, i.e. I replaced the line
localhost = InetAddress.getLocalHost().getHostAddress();
with the following code:
localhost = System.getProperty( java.rmi.server.hostname);
if ( localhost == null) {
localhost = InetAddress.getLocalHost().getHostAddress();
}
Now I can properly access the GNU Classpath based RMI server from a
remote client, but I don't have a clue if this patch is valid by any
means (as my knowledge on both RMI and Classpath can be described as
shallow at best).
Any advice is welcome!
Lorenz Witte
[EMAIL PROTECTED]
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
[Bug awt/24566] ClassCastException in ImageIO.read( File )
--- Comment #2 from matighet at bbn dot com 2006-01-11 14:28 --- I'm having the same problem, and it is a show stopper for the use of classpath in our project: java.lang.ClassCastException at gnu.java.awt.peer.gtk.GdkPixbufDecoder$GdkPixbufReader.setInput (GdkPixbufDecoder.java:633) at javax.imageio.ImageReader.setInput (ImageReader.java:457) at javax.imageio.ImageIO.read (ImageIO.java:866) at javax.imageio.ImageIO.read (ImageIO.java:930) Who originally wrote this implementation ? -- matighet at bbn dot com changed: What|Removed |Added CC||matighet at bbn dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24566 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
RE: SecurityManager troubles
Hi Jeroen, On Wed, 2006-01-11 at 08:45 +0100, Jeroen Frijters wrote: After fixing some IKVM specific bugs, I was able to run the testcase succesfully with only the attached GNU Classpath fix. That patch is obviously correct. Please do check this in even if other runtimes are still broken :) Thanks, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
[Bug awt/24566] ClassCastException in ImageIO.read( File )
--- Comment #3 from mark at gcc dot gnu dot org 2006-01-11 19:14 --- This has been fixed in CVS and should work in the next developer snapshot release. -- mark at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |0.20 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24566 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Some Mauve regressions builder missed
Hi all, Seems builder.classpath.org misses some regressions. builder can only accurately report when a PASS turns into a FAIL with the exact same message. It deliberately doesn't report new FAILs (since those could be from newly added tests). Since we sometimes use different messages when something PASSes and when something FAILs the auto-builder cannot currently detect those regressions. A special case are tests that crash a VM, then the message is replaced with CRASHED. Which is incorrectly interpreted as a new FAIL, but is obviously a regression. A workaround is to create a new test harness that ignores checkpoint names and PASS/FAIL messages. Such a harness should just use the test classname as message plus a counter. I'll implement that after 0.20. So here are the Mauve tests with regressions that builder missed: - gnu.testlet.java.math.BigDecimal.DiagBigDecimal This is the assert issue in mprec.c. - gnu.testlet.java.net.DatagramPacket.DatagramPacketOffset - gnu.testlet.java.net.DatagramPacket.DatagramPacketReceive - gnu.testlet.java.net.DatagramPacket.DatagramPacketReceive2 - gnu.testlet.java.net.DatagramSocket.DatagramSocketTest - gnu.testlet.java.net.DatagramSocket.DatagramSocketTest2 - gnu.testlet.java.net.InetAddress.getAllByName - gnu.testlet.java.net.MulticastSocket.MulticastSocketTest - gnu.testlet.java.net.ServerSocket.ServerSocketTest - gnu.testlet.java.net.Socket.SocketTest These are mostly the same issue (also an assert). I am working on a patch. - gnu.testlet.javax.swing.text.BoxView.spans I am unclear why the results changed between 0.19 an 0.20pre without the builder noticing. Maybe we accidentally reset the tester. Not investigated yet. - gnu.testlet.javax.swing.JTextField.createDefaultModel - gnu.testlet.javax.swing.JTextField.CopyPaste - gnu.testlet.javax.swing.BoxLayout.simplehorizontal - gnu.testlet.javax.swing.BoxLayout.simplevertical - gnu.testlet.javax.swing.AbstractButton.setRolloverEnabled - gnu.testlet.javax.swing.JEditorPane.ConstructorsAndTypes Not investigated yet. If people have time please do investigate the above Mauve tests so we can have a nice regression free release Friday. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: RMI and java.rmi.server.hostname
Lorenz == Lorenz Witte [EMAIL PROTECTED] writes: Lorenz Currently I meet the problem by modifying the static constructor of Lorenz gnu.java.rmi.server.UnicastConnectionManager, so that the static field Lorenz localhost is initialized with the value of the Lorenz java.rmi.server.hostname property It looks like we have a few bugs in this area. I found this page informative: http://java.sun.com/j2se/1.4.2/docs/guide/rmi/javarmiproperties.html Your patch looks like it would help, but it doesn't address all the issues. It seems reasonable to use it as an interim solution though. It sounds like by default we're using 127.0.0.1 -- does this happen with the JDK as well? I filed a PR: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25754 I would have linked to your message but, weirdly, it isn't in the list archives yet. Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: SecurityManager troubles
Jeroen Frijters wrote: Gary Benson wrote: Guilhem Lavaux wrote: 3) One solution of the problem is to load some core classes. But it will appear quite soon that some other classes may also be loaded for really wicked applications. It is a limitative solution and I would not support it. Yes. Exactly which classes need loading depends on exactly what your custom checkPermission is doing. We can, of course, make sure we have the classes we need for the default checkPermission, but that doesn't seem complete somehow. I must say that I don't understand this problem. Shouldn't the boot class loader be able to load classes regardless of the SecurityManager? It would seem to me that VMs that can't do that are broken and that this is not a Classpath problem. Regards, Jeroen Hi Jeroen, I do not think it is strictly linked to the VM. I have produced an artificial stack trace by tweaking kaffe's VM. Normally this stack trace is hidden by the VM and replaced by a NoClassDefFoundError. Here I removed the class preloading from my test. You can see there is a loop in CharsetProvider at least. Maybe it's VM related but it would be really weird. This block is the loop: at testSM$MySM.checkPermission (testSM.java:17) at java.lang.SecurityManager.checkSecurityAccess (SecurityManager.java:1011) at java.security.Security.getProperty (Security.java:396) at java.lang.SecurityManager$1.run (SecurityManager.java:1055) at java.security.AccessController.doPrivileged (AccessController.java:96) at java.lang.SecurityManager.checkPackageList (SecurityManager.java:1051) at java.lang.SecurityManager.checkPackageAccess (SecurityManager.java:920) at java.lang.ClassLoader$1.loadClass (ClassLoader.java:1108) at java.lang.ClassLoader.loadClass (ClassLoader.java:294) The last loadClass is already loading java/security/Permission and checkPermission needs to load java/security/Permission too. Maybe it is also a SystemProperties trouble ? Cheers, Guilhem. java/security/Permission at testSM$MySM.checkPermission (testSM.java:17) at java.lang.SecurityManager.checkSecurityAccess (SecurityManager.java:1011) at java.security.Security.getProperty (Security.java:396) at java.lang.SecurityManager$1.run (SecurityManager.java:1055) at java.security.AccessController.doPrivileged (AccessController.java:96) at java.lang.SecurityManager.checkPackageList (SecurityManager.java:1051) at java.lang.SecurityManager.checkPackageAccess (SecurityManager.java:920) at java.lang.ClassLoader$1.loadClass (ClassLoader.java:1108) at java.lang.ClassLoader.loadClass (ClassLoader.java:294) at java.nio.charset.spi.CharsetProvider.init (CharsetProvider.java:72) at gnu.java.nio.charset.Provider.init (Provider.java:88) at gnu.java.nio.charset.Provider.init (Provider.java:87) at gnu.java.nio.charset.Provider$1.run (Provider.java:244) at java.security.AccessController.doPrivileged (AccessController.java:96) at gnu.java.nio.charset.Provider.provider (Provider.java:239) at java.nio.charset.Charset.provider (Charset.java:252) at java.nio.charset.Charset.charsetForName (Charset.java:208) at java.nio.charset.Charset.forName (Charset.java:188) at java.lang.String.init (String.java:158) at gnu.java.net.protocol.file.Connection.unquote (Connection.java:168) at gnu.java.net.protocol.file.Connection.connect (Connection.java:186) at gnu.java.net.protocol.file.Connection.getInputStream (Connection.java:251) at java.net.URL.openStream (URL.java:683) at java.security.Security.loadProviders (Security.java:124) at java.security.Security.clinit (Security.java:78) at java.lang.SecurityManager$1.run (SecurityManager.java:1055) at java.security.AccessController.doPrivileged (AccessController.java:96) at java.lang.SecurityManager.checkPackageList (SecurityManager.java:1051) at java.lang.SecurityManager.checkPackageAccess (SecurityManager.java:920) at java.lang.ClassLoader$1.loadClass (ClassLoader.java:1108) at java.lang.ClassLoader.loadClass (ClassLoader.java:294) at testSM.main (testSM.java:38) ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: SecurityManager troubles
Guilhem Lavaux wrote: I must say that I don't understand this problem. Me neither... I do not think it is strictly linked to the VM. I have produced an artificial stack trace by tweaking kaffe's VM. Normally this stack trace is hidden by the VM and replaced by a NoClassDefFoundError. Here I removed the class preloading from my test. You can see there is a loop in CharsetProvider at least. Maybe it's VM related but it would be really weird. It doesn't happen with JCVM.. but see below.. This block is the loop: at testSM$MySM.checkPermission (testSM.java:17) at java.lang.SecurityManager.checkSecurityAccess (SecurityManager.java:1011) at java.security.Security.getProperty (Security.java:396) at java.lang.SecurityManager$1.run (SecurityManager.java:1055) at java.security.AccessController.doPrivileged (AccessController.java:96) at java.lang.SecurityManager.checkPackageList (SecurityManager.java:1051) at java.lang.SecurityManager.checkPackageAccess (SecurityManager.java:920) at java.lang.ClassLoader$1.loadClass (ClassLoader.java:1108) at java.lang.ClassLoader.loadClass (ClassLoader.java:294) The last loadClass is already loading java/security/Permission and checkPermission needs to load java/security/Permission too. Maybe it is also a SystemProperties trouble ? OK, so this requires that the VM be lazily resolving classes, i.e., java.security.Permission, as referenced by testSM$MySM, is not resolved until checkPermission() is about to be invoked. JCVM resolves classes all at once, so it doesn't have this problem. Having said that, still not sure what the solution is. Seems likely that any class used as a security manager needs to be fully resolved before being used. Perhaps System.setSecurityManager(s) can always invoke Class.forName(s.getClass().getName, true, s.getClass().getClassLoader()). Right now I can't remember if class initialization implies (complete) class resolution. I think it does.. but if not then the above trick wouldn't necessarily work. Clearly it does NOT in kaffe, otherwise the above example couldn't happen. Hmm, maybe System.setSecurityManager() can do a phony invocation of s.checkPermission() to ensure that it's resolved... -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
NIO (Non-block Scatter/Gather)
Hi,
My name is Mike Barker. I am interesting in contributing to the GNU
Classpath project. As a start I have looked the NIO implemenation with
regards to Channels (specifically SocketChannel).
Attached to this mail is a patch that adds support for configuring a
socket to be non-blocking and uses readv and writev system calls to
support native scatter/gather operations. Native access is through a
VMChannel.java class. This class could also be added to other Channel
types to implement native scatter/gather I/O across the board.
The patch is not quite complete. It passes the Mauve tests, but
requires a more comprehensive set of tests (e.g. testing readv/writev
and different types of ByteBuffer, direct mapped). However if what I
doing looks reasonably sane, I can continue in order to provide a more
complete patch. Comments, criticism, etc. is welcome.
Quick question:
I understand the info on the Wiki around developer tainting, which is OK
as I have not studied the Java sources. What about black-box testing of
the functionality of the JVM? Does doing this taint the developer?
Regards,
Mike Barker.
Index: .settings/org.eclipse.jdt.core.prefs
===
RCS file: /cvsroot/classpath/classpath/.settings/org.eclipse.jdt.core.prefs,v
retrieving revision 1.5
diff -u -r1.5 org.eclipse.jdt.core.prefs
--- .settings/org.eclipse.jdt.core.prefs 14 Sep 2005 01:33:27 - 1.5
+++ .settings/org.eclipse.jdt.core.prefs 11 Jan 2006 22:09:39 -
@@ -1,4 +1,4 @@
-#Tue Sep 13 16:15:04 MDT 2005
+#Thu Dec 22 16:04:11 GMT 2005
eclipse.preferences.version=1
org.eclipse.jdt.core.compiler.codegen.inlineJsrBytecode=enabled
org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.4
@@ -15,7 +15,7 @@
org.eclipse.jdt.core.compiler.problem.deprecationInDeprecatedCode=disabled
org.eclipse.jdt.core.compiler.problem.deprecationWhenOverridingDeprecatedMethod=disabled
org.eclipse.jdt.core.compiler.problem.emptyStatement=ignore
-org.eclipse.jdt.core.compiler.problem.enumIdentifier=error
+org.eclipse.jdt.core.compiler.problem.enumIdentifier=warning
org.eclipse.jdt.core.compiler.problem.fieldHiding=ignore
org.eclipse.jdt.core.compiler.problem.finalParameterBound=warning
org.eclipse.jdt.core.compiler.problem.finallyBlockNotCompletingNormally=warning
@@ -72,6 +72,7 @@
org.eclipse.jdt.core.formatter.alignment_for_binary_expression=18
org.eclipse.jdt.core.formatter.alignment_for_compact_if=16
org.eclipse.jdt.core.formatter.alignment_for_conditional_expression=82
+org.eclipse.jdt.core.formatter.alignment_for_enum_constants=0
org.eclipse.jdt.core.formatter.alignment_for_expressions_in_array_initializer=18
org.eclipse.jdt.core.formatter.alignment_for_multiple_fields=16
org.eclipse.jdt.core.formatter.alignment_for_parameters_in_constructor_declaration=18
@@ -302,3 +303,4 @@
org.eclipse.jdt.core.formatter.put_empty_statement_on_new_line=true
org.eclipse.jdt.core.formatter.tabulation.char=space
org.eclipse.jdt.core.formatter.tabulation.size=2
+org.eclipse.jdt.core.formatter.use_tabs_only_for_leading_indentations=false
Index: .settings/org.eclipse.jdt.ui.prefs
===
RCS file: /cvsroot/classpath/classpath/.settings/org.eclipse.jdt.ui.prefs,v
retrieving revision 1.4
diff -u -r1.4 org.eclipse.jdt.ui.prefs
--- .settings/org.eclipse.jdt.ui.prefs 18 Sep 2005 04:19:36 - 1.4
+++ .settings/org.eclipse.jdt.ui.prefs 11 Jan 2006 22:09:39 -
@@ -1,4 +1,4 @@
-#Sat Sep 17 22:04:29 MDT 2005
+#Thu Dec 22 16:04:10 GMT 2005
eclipse.preferences.version=1
formatter_settings_version=8
internal.default.compliance=user
Index: gnu/java/nio/SelectorImpl.java
===
RCS file: /cvsroot/classpath/classpath/gnu/java/nio/SelectorImpl.java,v
retrieving revision 1.21
diff -u -r1.21 SelectorImpl.java
--- gnu/java/nio/SelectorImpl.java 27 Dec 2005 08:32:12 - 1.21
+++ gnu/java/nio/SelectorImpl.java 11 Jan 2006 22:09:41 -
@@ -379,6 +379,8 @@
result = new DatagramChannelSelectionKey (ch, this);
else if (ch instanceof ServerSocketChannelImpl)
result = new ServerSocketChannelSelectionKey (ch, this);
+else if (ch instanceof gnu.java.nio.channels.SocketChannelImpl)
+ result = new gnu.java.nio.channels.SocketChannelSelectionKeyImpl((gnu.java.nio.channels.SocketChannelImpl)ch, this);
else
throw new InternalError (No known channel type);
Index: gnu/java/nio/SelectorProviderImpl.java
===
RCS file: /cvsroot/classpath/classpath/gnu/java/nio/SelectorProviderImpl.java,v
retrieving revision 1.8
diff -u -r1.8 SelectorProviderImpl.java
--- gnu/java/nio/SelectorProviderImpl.java 2 Jul 2005 20:32:13 - 1.8
+++ gnu/java/nio/SelectorProviderImpl.java 11 Jan 2006 22:09:41 -
@@ -78,6 +78,7 @@
public SocketChannel openSocketChannel ()
throws IOException
{
-return
[commit-cp] classpath ./ChangeLog javax/swing/text/DefaultS...
CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Lillian Angel [EMAIL PROTECTED] 06/01/11 19:25:57 Modified files: . : ChangeLog javax/swing/text: DefaultStyledDocument.java Log message: 2006-01-11 Lillian Angel [EMAIL PROTECTED] * javax/swing/text/DefaultStyledDocument.java (toString): Shouldn't append the '' character here. (createDefaultRoot): Should not set the resolve parent. This causes problems when comparing attribute sets. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.6012tr2=1.6013r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/javax/swing/text/DefaultStyledDocument.java.diff?tr1=1.28tr2=1.29r1=textr2=text
[commit-cp] classpath ./ChangeLog java/util/Hashtable.java
CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Roman Kennke [EMAIL PROTECTED]06/01/11 20:01:54 Modified files: . : ChangeLog java/util : Hashtable.java Log message: 2006-01-11 Roman Kennke [EMAIL PROTECTED] Reported by: Fridjof Siebert [EMAIL PROTECTED] * java/util/Hashtable.java (KEYS): Removed unneeded field. (VALUES): Removed unneeded field. (ENTRIES): Removed unneeded field. (keys): Return a KeyEnumerator instance. (elements): Returns a ValueEnumerator instance. (toString): Use an EntryIterator instance. (keySet): Return a KeyIterator instance. (values): Return a ValueIterator instance. (entrySet): Return an EntryIterator instance. (hashCode): Use EntryIterator instance. (rehash): Changed this loop to avoid redundant reads and make it obvious that null checking is not needed. (writeObject): Use EntryIterator instance. (HashIterator): Removed class. (Enumerator): Removed class. (EntryIterator): New class. (KeyIterator): New class. (ValueIterator): New class. (EntryEnumerator): New class. (KeyEnumerator): New class. (ValueEnumerator): New class. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.6013tr2=1.6014r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/java/util/Hashtable.java.diff?tr1=1.36tr2=1.37r1=textr2=text
[commit-cp] classpath ./ChangeLog javax/swing/text/DefaultS...
CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Anthony Balkissoon [EMAIL PROTECTED] 06/01/11 20:07:24 Modified files: . : ChangeLog javax/swing/text: DefaultStyledDocument.java Log message: 2006-01-11 Anthony Balkissoon [EMAIL PROTECTED] * javax/swing/text/DefaultStyledDocument.java: (ElementBuffer.insertUpdate): Properly recreate Elements if the first tag is an end tag. Avoid NPE by pushing the proper Element on to the elementStack when there is a start tag with JoinNextDirection. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.6014tr2=1.6015r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/javax/swing/text/DefaultStyledDocument.java.diff?tr1=1.29tr2=1.30r1=textr2=text
[commit-cp] classpath ./ChangeLog gnu/xml/transform/Attribu...
CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Chris Burdess [EMAIL PROTECTED] 06/01/11 22:05:45 Modified files: . : ChangeLog gnu/xml/transform: AttributeNode.java ElementNode.java LiteralNode.java StreamSerializer.java Stylesheet.java TransformerFactoryImpl.java TransformerImpl.java ValueOfNode.java gnu/xml/xpath : Expr.java LocalNameFunction.java NameFunction.java NameTest.java NamespaceUriFunction.java NodeTypeTest.java SubstringFunction.java javax/xml/namespace: QName.java Added files: gnu/xml/transform: StrippingInstruction.java Log message: 2006-01-11 Chris Burdess [EMAIL PROTECTED] * gnu/xml/transform/AttributeNode.java, gnu/xml/transform/ElementNode.java, gnu/xml/transform/LiteralNode.java, gnu/xml/transform/StreamSerializer.java, gnu/xml/transform/StrippingInstruction.java, gnu/xml/transform/Stylesheet.java, gnu/xml/transform/TransformerImpl.java, gnu/xml/transform/ValueOfNode.java, gnu/xml/xpath/Expr.java, gnu/xml/xpath/LocalNameFunction.java, gnu/xml/xpath/NameFunction.java, gnu/xml/xpath/NameTest.java, gnu/xml/xpath/NamespaceUriFunction.java, gnu/xml/xpath/NodeTypeTest.java, gnu/xml/xpath/SubstringFunction.java, javax/xml/namespace/QName.java: don't determine element namespace from namespace aliases when specified; better namespace handling when serializing elements; don't create HTML meta element unless head element exists; correct encoding of CDATA sections containing ']]'; encode HTML character entity references; use ISO-Latin-1 as default encoding for HTML output; rewrite of XSLT strip-space/preserve-space handling; correct doctype-public and doctype-system output attributes; insert generated doctype before document element; fixed result tree whitespace stripping algorithm; fixed semantics of XPath name, local-name, and namespace-uri functions; name tests handle XML/XMLNS namespaces correctly; fixed semantics of processing-instruction node test. * gnu/xml/transform/TransformerFactoryImpl.java: Add main method to aid debugging. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.6017tr2=1.6018r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/gnu/xml/transform/AttributeNode.java.diff?tr1=1.4tr2=1.5r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/gnu/xml/transform/ElementNode.java.diff?tr1=1.4tr2=1.5r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/gnu/xml/transform/LiteralNode.java.diff?tr1=1.3tr2=1.4r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/gnu/xml/transform/StreamSerializer.java.diff?tr1=1.9tr2=1.10r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/gnu/xml/transform/StrippingInstruction.java?rev=1.1 http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/gnu/xml/transform/Stylesheet.java.diff?tr1=1.6tr2=1.7r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/gnu/xml/transform/TransformerFactoryImpl.java.diff?tr1=1.2tr2=1.3r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/gnu/xml/transform/TransformerImpl.java.diff?tr1=1.7tr2=1.8r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/gnu/xml/transform/ValueOfNode.java.diff?tr1=1.5tr2=1.6r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/gnu/xml/xpath/Expr.java.diff?tr1=1.4tr2=1.5r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/gnu/xml/xpath/LocalNameFunction.java.diff?tr1=1.3tr2=1.4r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/gnu/xml/xpath/NameFunction.java.diff?tr1=1.3tr2=1.4r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/gnu/xml/xpath/NameTest.java.diff?tr1=1.4tr2=1.5r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/gnu/xml/xpath/NamespaceUriFunction.java.diff?tr1=1.3tr2=1.4r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/gnu/xml/xpath/NodeTypeTest.java.diff?tr1=1.3tr2=1.4r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/gnu/xml/xpath/SubstringFunction.java.diff?tr1=1.3tr2=1.4r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/javax/xml/namespace/QName.java.diff?tr1=1.8tr2=1.9r1=textr2=text
