[cp-patches] FYI: Proxy based RMI stub replacents implemented.
This patch adds the 1.5 feature to replace the missing RMI stub classes
by the dynamically created proxy stubs. Our Proxy is working great with
jamvm.
The stub classes that were previously generated by the RMIC compiler,
are no longer required, unless for research stubs or backward
compatibility.
Removing the need to generate and compile the RMI stubs reduces the
build time. This is important for the large projects that extensively
use RMI.
The proxy stubs are created (and work) with the several RMI applications
I have. The proxy stub usage may be forced by setting
java.rmi.server.ignoreStubClasses=true (except bootstrap classes).
2006-02-20 Audrius Meskauskas [EMAIL PROTECTED]
* gnu/java/rmi/server/RMIObjectInputStream.java (resolveProxyClass):
Expect that proxy interfaces may have different class loaders.
* gnu/java/rmi/server/UnicastServerRef.java: Rewritten.
* java/rmi/registry/Registry.java,
* java/rmi/server/UnicastRemoteObject.java:
Documented about proxy stubs.
* gnu/java/rmi/server/CombinedClassLoader.java,
java/rmi/server/RemoteObjectInvocationHandler.java: New files.
* NEWS: Added entry.
Index: NEWS
===
RCS file: /sources/classpath/classpath/NEWS,v
retrieving revision 1.112
diff -u -r1.112 NEWS
--- NEWS 16 Feb 2006 23:22:53 - 1.112
+++ NEWS 20 Feb 2006 08:13:14 -
@@ -7,9 +7,7 @@
`java.security.' `javax.crypto,' and `javax.net.ssl' packages, and
are service providers implementing the underlying algorithms.
-* The new folder tools now contains GIOP and RMI tools, providing necessary
- support for development using org.omg.*, javax.rmi.CORBA.* and java.rmi.*
- packages. The toll set includes GIOP and RMI stub and tie source code
+* The new folder tools includes GIOP and RMI stub and tie source code
generators, IOR parser and both transient and persistent GIOP naming services.
* RELAX NG pluggable XML schema datatype library API and an implementation
@@ -17,6 +15,10 @@
* JTable columns are rearrangeable and resizeable with mouse.
+* Added experimental support for dynamic creation of the RMI stubs using proxy
+ classes. The rmic compiler is no longer required (unless for research
+ and specific stubs).
+
New in release 0.20 (Jan 13, 2006)
* New StAX pull parser and SAX-over-StAX driver. Lots of DOM, SAX/StAX,
Index: gnu/java/rmi/server/RMIObjectInputStream.java
===
RCS file: /sources/classpath/classpath/gnu/java/rmi/server/RMIObjectInputStream.java,v
retrieving revision 1.9
diff -u -r1.9 RMIObjectInputStream.java
--- gnu/java/rmi/server/RMIObjectInputStream.java 14 Sep 2005 16:52:07 - 1.9
+++ gnu/java/rmi/server/RMIObjectInputStream.java 20 Feb 2006 08:13:20 -
@@ -46,6 +46,7 @@
import java.lang.reflect.Proxy;
import java.net.MalformedURLException;
import java.rmi.server.RMIClassLoader;
+import java.util.ArrayList;
public class RMIObjectInputStream
extends ObjectInputStream {
@@ -76,28 +77,51 @@
return readObject();
}
-protected Class resolveProxyClass(String intfs[])
-throws IOException, ClassNotFoundException
-{
-String annotation = (String)getAnnotation();
-
+
+ protected Class resolveProxyClass(String intfs[]) throws IOException,
+ ClassNotFoundException
+ {
+String annotation = (String) getAnnotation();
+
Class clss[] = new Class[intfs.length];
-if(annotation == null)
-clss[0] = RMIClassLoader.loadClass(intfs[0]);
-else
-clss[0] = RMIClassLoader.loadClass(annotation, intfs[0]);
-
-//assume all interfaces can be loaded by the same classloader
-ClassLoader loader = clss[0].getClassLoader();
+
for (int i = 0; i intfs.length; i++)
-clss[i] = Class.forName(intfs[i], false, loader);
-
-try {
-return Proxy.getProxyClass(loader, clss);
- } catch (IllegalArgumentException e) {
- throw new ClassNotFoundException(null, e);
- }
-}
+ {
+if (annotation == null)
+ clss[i] = RMIClassLoader.loadClass(intfs[i]);
+else
+ clss[i] = RMIClassLoader.loadClass(annotation, intfs[i]);
+ }
+
+ClassLoader loader;
+
+if (clss.length 0)
+ {
+// Chain all class loaders (they may differ).
+ArrayList loaders = new ArrayList(intfs.length);
+ClassLoader cx;
+for (int i = 0; i clss.length; i++)
+ {
+cx = clss[i].getClassLoader();
+if (!loaders.contains(cx))
+ {
+loaders.add(0, cx);
+ }
+ }
+loader = new CombinedClassLoader(loaders);
+ }
+else
+ loader = ClassLoader.getSystemClassLoader();
+
+try
+ {
+return Proxy.getProxyClass(loader, clss);
+ }
+catch (IllegalArgumentException e)
+ {
+throw new ClassNotFoundException(null, e);
+ }
+ }
protected
Re: [cp-patches] FYI: fix for PR 26354
The attached patch file was empty. Here is the correct one.
cya
Robert
Robert Schuster wrote:
Hi,
this patch contains my already approved fix for GapContent and another small
change that fixes the remaining issue I was seeing.
While the GapContent fix makes it possible to remove the 'd' in this document
correctly:
abc
def
The change of the order of operations in AbstractDocument.remove makes it
possible to remove the 'c' from the same document.
What was wrong before the patch is that the content was already changed when
PlainDocument.removeUpdate is invoked. In the example above that method calls
getElementIndex() for offset 3 which was initially on the first line but since
the content is already modified it returns that offset 3 is on the second
line.
This in turn leads the algorithm to the assumption that a line-spanning
removal
has taken place and that the Elements representing these lines have to be
joined.
Both defects lead to the problems mentioned in PR 26354 which are now solved.
The patch was approved by Roman on IRC.
2006-02-20 Robert Schuster [EMAIL PROTECTED]
* javax/swing/text/GapContent.java:
(shiftGapEndUp): Corrected new mark value.
* javax/swing/text/AbstractDocument.java:
(remove): Changed order of operations.
cya
Robert
Index: javax/swing/text/AbstractDocument.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/text/AbstractDocument.java,v
retrieving revision 1.49
diff -u -r1.49 AbstractDocument.java
--- javax/swing/text/AbstractDocument.java 20 Feb 2006 12:02:33 - 1.49
+++ javax/swing/text/AbstractDocument.java 20 Feb 2006 12:05:47 -
@@ -690,8 +690,11 @@
try
{
writeLock();
-UndoableEdit temp = content.remove(offset, length);
+
+// The order of the operations below is critical!
removeUpdate(event);
+UndoableEdit temp = content.remove(offset, length);
+
postRemoveUpdate(event);
fireRemoveUpdate(event);
}
Index: javax/swing/text/GapContent.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/text/GapContent.java,v
retrieving revision 1.38
diff -u -r1.38 GapContent.java
--- javax/swing/text/GapContent.java 20 Feb 2006 12:02:33 - 1.38
+++ javax/swing/text/GapContent.java 20 Feb 2006 12:05:47 -
@@ -557,7 +557,7 @@
assert newGapEnd gapEnd : The new gap end must be greater than the
+ old gap end.;
-setPositionsInRange(gapEnd, newGapEnd - gapEnd, newGapEnd + 1);
+setPositionsInRange(gapEnd, newGapEnd - gapEnd, newGapEnd);
gapEnd = newGapEnd;
}
signature.asc
Description: OpenPGP digital signature
[cp-patches] FYI: BasicTextUI.damageRange
I implemented the stubbed method BasicTextUI.damageRange().
2006-02-20 Roman Kennke [EMAIL PROTECTED]
* javax/swing/plaf/basic/BasicTextUI.java
(damageRange): Implemented this method.
/Roman
Index: javax/swing/plaf/basic/BasicTextUI.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/plaf/basic/BasicTextUI.java,v
retrieving revision 1.68
diff -u -r1.68 BasicTextUI.java
--- javax/swing/plaf/basic/BasicTextUI.java 16 Feb 2006 14:32:56 - 1.68
+++ javax/swing/plaf/basic/BasicTextUI.java 20 Feb 2006 12:39:36 -
@@ -943,7 +943,18 @@
public void damageRange(JTextComponent t, int p0, int p1,
Position.Bias firstBias, Position.Bias secondBias)
{
-// TODO: Implement me.
+try
+ {
+Rectangle l1 = modelToView(t, p0, firstBias);
+Rectangle l2 = modelToView(t, p1, secondBias);
+t.repaint(l1.union(l2));
+ }
+catch (BadLocationException ex)
+ {
+AssertionError err = new AssertionError(Unexpected bad location);
+err.initCause(ex);
+throw err;
+ }
}
/**
Re: [cp-patches] FYI: fix for PR 26354
Nice work Robert, especially the Mauve tests that back up your change!
Regards,
Dave
Robert Schuster wrote:
The attached patch file was empty. Here is the correct one.
cya
Robert
Robert Schuster wrote:
Hi,
this patch contains my already approved fix for GapContent and another small
change that fixes the remaining issue I was seeing.
While the GapContent fix makes it possible to remove the 'd' in this document
correctly:
abc
def
The change of the order of operations in AbstractDocument.remove makes it
possible to remove the 'c' from the same document.
What was wrong before the patch is that the content was already changed when
PlainDocument.removeUpdate is invoked. In the example above that method calls
getElementIndex() for offset 3 which was initially on the first line but since
the content is already modified it returns that offset 3 is on the second line.
This in turn leads the algorithm to the assumption that a line-spanning removal
has taken place and that the Elements representing these lines have to be
joined.
Both defects lead to the problems mentioned in PR 26354 which are now solved.
The patch was approved by Roman on IRC.
2006-02-20 Robert Schuster [EMAIL PROTECTED]
* javax/swing/text/GapContent.java:
(shiftGapEndUp): Corrected new mark value.
* javax/swing/text/AbstractDocument.java:
(remove): Changed order of operations.
cya
Robert
Index: javax/swing/text/AbstractDocument.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/text/AbstractDocument.java,v
retrieving revision 1.49
diff -u -r1.49 AbstractDocument.java
--- javax/swing/text/AbstractDocument.java 20 Feb 2006 12:02:33 -
1.49
+++ javax/swing/text/AbstractDocument.java 20 Feb 2006 12:05:47 -
@@ -690,8 +690,11 @@
try
{
writeLock();
-UndoableEdit temp = content.remove(offset, length);
+
+// The order of the operations below is critical!
removeUpdate(event);
+UndoableEdit temp = content.remove(offset, length);
+
postRemoveUpdate(event);
fireRemoveUpdate(event);
}
Index: javax/swing/text/GapContent.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/text/GapContent.java,v
retrieving revision 1.38
diff -u -r1.38 GapContent.java
--- javax/swing/text/GapContent.java20 Feb 2006 12:02:33 - 1.38
+++ javax/swing/text/GapContent.java20 Feb 2006 12:05:47 -
@@ -557,7 +557,7 @@
assert newGapEnd gapEnd : The new gap end must be greater than the
+ old gap end.;
-setPositionsInRange(gapEnd, newGapEnd - gapEnd, newGapEnd + 1);
+setPositionsInRange(gapEnd, newGapEnd - gapEnd, newGapEnd);
gapEnd = newGapEnd;
}
Re: [cp-patches] RFC: fix in proxy creation of interfaces redefining toString, equals or hashCode
Re all, Mark Wielaard wrote: I just submitted a mauve testlet to stress this point and here is the proposition of fix in Proxy.java (for non native Proxy implementations, that's it). When iterating over the methods to be added to the proxy, if any is matching an Object one (by its name and parameter types only), it is skipped. Since we're already adding them automatically, it is not missing of the resulting proxy and the declaring class remains Object.class 2006-02-19 Olivier Jolly olivier.jolly * java/lang/reflect/Proxy.java (ProxyData.getProxyData): Skipped overriding of core methods. (ProxyData.isCoreObjectMethod): New method. Instead of adding a new method, could you just check ProxySignature.coreMethods.contains(sig)? Not that it matters a lot since I don't think the set in ProxySignature.coreMethods and what is checked in ProxyData.isCoreObjectMethod() will ever get out of sync. First I wanted to implement it with a contains, but unfortunately, contains relies on equals, which will check that the declaring class are the same before saying that two methods are equals. In this case, we know we have the same methods expected that the declaring class are differents, that's the whole point of the fix, hence this little method which acts like a contains with a very specific equals. If we had a contains(Object, Comparator) on collections, I would have use it. Please feel free to commit it either as is or by checking coreMethods.contains(). The logic seems fine to me either way. Okey, I'll commit later today with this method if nobody comes out with a better solution by then... I have not yet passed the integrality of mauve tests to ensure regression, but I will by the time this patch is accepted :) Yeah. Mauve is getting a bit big. You can run a subset by defining KEYS (see the README). The autobuilder on builder.classpath.org will run all tests. I meant mauve is already a monster with KEYS=classpath :) Cheers, Take care Mark Olivier
Re: [cp-patches] Patch: layout/validating fix
On Fri, 2006-02-17 at 14:34 -0500, Lillian Angel wrote:
2006-02-17 Lillian Angel [EMAIL PROTECTED]
* gnu/java/awt/peer/gtk/GtkComponentPeer.java
(setBounds): Removed check. Coordinates should always be changed
to incorporate the parent's coordinates.
* gnu/java/awt/peer/gtk/GtkFramePeer.java
(setMenuBar): Added checks. Don't validate component if it has
not been validated yet, it will be validated later. Only
validate if it has already been validated, in that case it
needs to be revalidated.
* java/awt/Window.java
(show): Added check. If the window is visible, then bring it to
the front. Otherwise, iterate through all its children windows
and show them. No need to do both.
A change I made in Window.show() caused some problems. I fixed this.
2006-02-20 Lillian Angel [EMAIL PROTECTED]
* java/swt/Window.java
(show): Calling show() on the owned windows caused problems.
Changed back to get the peer and call setVisible.
Index: java/awt/Window.java
===
RCS file: /sources/classpath/classpath/java/awt/Window.java,v
retrieving revision 1.64
diff -u -r1.64 Window.java
--- java/awt/Window.java 17 Feb 2006 19:24:53 - 1.64
+++ java/awt/Window.java 20 Feb 2006 14:38:21 -
@@ -299,7 +299,10 @@
{
Window w = (Window) (((Reference) e.next()).get());
if (w != null)
- w.show();
+ {
+if (w.isVisible())
+ w.getPeer().setVisible(true);
+ }
else
// Remove null weak reference from ownedWindows.
// Unfortunately this can't be done in the Window's
Re: [cp-patches] RFC: fix in proxy creation of interfaces redefining toString, equals or hashCode
Archie Cobbs wrote:
Olivier Jolly wrote:
I bumped into a major problem with spring and easymock which boiled
down to being a subtle definition of a Proxy. In the case of the
creation of a proxy which defines the same method as Object (which is
non final and public), the method in the interface must be so that
getDeclaringClass is Object.class and not the actual interface.
Just curious.. are you sure this is a Classpath issue and not
a VM issue?
yes, as far as the VM isn't handling natively the creation of
java.lang.reflect.Proxy. In the Proxy.java source file of classpath
we're (incorrectly) building the proxy with methods that shouldn't be there.
What does the failure look like?
Within an InvocationHandler, the method instance which is given as
parameter is not equals to Object.class.getDeclaredMethod(..., ...) if
the interface the proxy is built on redefines one of the core Object
methods. Easymock is correctly expecting to catch all equals call with
Object.class.getDeclaredMethod(equals, new Class[]
{Object.class}).equals(method) which is not the case without my patch.
Also (very minor) would isCoreObjectMethod() be more simply implemented
using Object.class.getDeclaringMethod().. ?
Not at all, because the equality you would then use will prevent the
checked method (defined in an interface) from matching anything declared
in Object.class (because of the getDeclaringClass() difference).
Thanks for the feedback
-Archie
Olivier
[cp-patches] FYI: HTML Option
I implemented the Option class in javax.swing.text.html, which is needed
for the HTML Renderer as a value class for lists.
2006-02-20 Roman Kennke [EMAIL PROTECTED]
* javax/swing/text/html/Option.java: New class.
/Roman
Index: javax/swing/text/html/Option.java
===
RCS file: javax/swing/text/html/Option.java
diff -N javax/swing/text/html/Option.java
--- /dev/null 1 Jan 1970 00:00:00 -
+++ javax/swing/text/html/Option.java 20 Feb 2006 15:52:21 -
@@ -0,0 +1,157 @@
+/* Option.java -- Value class for option list model elements
+ Copyright (C) 2006 Free Software Foundation, Inc.
+
+This file is part of GNU Classpath.
+
+GNU Classpath is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU Classpath is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU Classpath; see the file COPYING. If not, write to the
+Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+02110-1301 USA.
+
+Linking this library statically or dynamically with other modules is
+making a combined work based on this library. Thus, the terms and
+conditions of the GNU General Public License cover the whole
+combination.
+
+As a special exception, the copyright holders of this library give you
+permission to link this library with independent modules to produce an
+executable, regardless of the license terms of these independent
+modules, and to copy and distribute the resulting executable under
+terms of your choice, provided that you also meet, for each linked
+independent module, the terms and conditions of the license of that
+module. An independent module is a module which is not derived from
+or based on this library. If you modify this library, you may extend
+this exception to your version of the library, but you are not
+obligated to do so. If you do not wish to do so, delete this
+exception statement from your version. */
+
+
+package javax.swing.text.html;
+
+import javax.swing.text.AttributeSet;
+
+/**
+ * Value class for the combobox model that renders codelt;optiongt;/code
+ * elements.
+ *
+ * @author Roman Kennke ([EMAIL PROTECTED])
+ */
+public class Option
+{
+
+ /**
+ * The attributes of the option tag.
+ */
+ private AttributeSet attributes;
+
+ /**
+ * The label.
+ */
+ private String label;
+
+ /**
+ * The selected state of this label.
+ */
+ private boolean selected;
+
+ /**
+ * Creates a new codeOption/code instance that uses the specified
+ * tag attributes.
+ *
+ * @param attr the attributes to use
+ */
+ public Option(AttributeSet attr)
+ {
+attributes = attr;
+label = null;
+selected = false;
+// FIXME: Probably initialize something using the attributes.
+ }
+
+ /**
+ * Sets the label to use for this codelt;optiongt;/code tag.
+ *
+ * @param l the label to set
+ */
+ public void setLabel(String l)
+ {
+label = l;
+ }
+
+ /**
+ * Returns the label of this codelt;optiongt;/code tag.
+ *
+ * @return the label of this codelt;optiongt;/code tag
+ */
+ public String getLabel()
+ {
+return label;
+ }
+
+ /**
+ * Returns the attributes used to render this codelt;optiongt;/code
+ * tag.
+ *
+ * @return the attributes used to render this codelt;optiongt;/code tag
+ */
+ public AttributeSet getAttributes()
+ {
+return attributes;
+ }
+
+ /**
+ * Returns a string representation of this codelt;optiongt;/code tag.
+ * This returns the codelabel/code property.
+ *
+ * @return a string representation of this codelt;optiongt;/code tag
+ */
+ public String toString()
+ {
+return label;
+ }
+
+ /**
+ * Sets the selected state of this codelt;optiongt;/code tag.
+ *
+ * @param s the selected state to set
+ */
+ protected void setSelection(boolean s)
+ {
+selected = s;
+ }
+
+ /**
+ * Returns codetrue/code when this option is selected, codefalse/code
+ * otherwise.
+ *
+ * @return codetrue/code when this option is selected, codefalse/code
+ * otherwise
+ */
+ public boolean isSelected()
+ {
+return selected;
+ }
+
+ /**
+ * Returns the string associated with the codevalue/code attribute or
+ * the label, if no such attribute is specified.
+ *
+ * @return the string associated with the codevalue/code attribute or
+ * the label, if no such attribute is specified
+ */
+ public String getValue()
+ {
+// FIXME: Return some attribute here if specified.
+return label;
+ }
+}
Re: [cp-patches] RFC: fix in proxy creation of interfaces redefining toString, equals or hashCode
Olivier Jolly wrote:
I bumped into a major problem with spring and easymock which boiled
down to being a subtle definition of a Proxy. In the case of the
creation of a proxy which defines the same method as Object (which is
non final and public), the method in the interface must be so that
getDeclaringClass is Object.class and not the actual interface.
Just curious.. are you sure this is a Classpath issue and not
a VM issue?
yes, as far as the VM isn't handling natively the creation of
java.lang.reflect.Proxy. In the Proxy.java source file of classpath
we're (incorrectly) building the proxy with methods that shouldn't be
there.
What does the failure look like?
Within an InvocationHandler, the method instance which is given as
parameter is not equals to Object.class.getDeclaredMethod(..., ...) if
the interface the proxy is built on redefines one of the core Object
methods. Easymock is correctly expecting to catch all equals call with
Object.class.getDeclaredMethod(equals, new Class[]
{Object.class}).equals(method) which is not the case without my patch.
Still curious.. :-)
It's not an error for an interface to declare a method that matches
an Object method (such as equals), and then for some bytecode somewhere
to INVOKEINTERFACE that method, even though INVOKEVIRTUAL would make
more sense. E.g. code somewhere in Eclipse does this.
So isn't this an easymock bug? In such a case, wouldn't easymock fail
to catch a valid equals() invocation?
-Archie
__
Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [cp-patches] RFC: fix in proxy creation of interfaces redefining toString, equals or hashCode
Archie Cobbs wrote:
Olivier Jolly wrote:
[...]
What does the failure look like?
Within an InvocationHandler, the method instance which is given as
parameter is not equals to Object.class.getDeclaredMethod(..., ...)
if the interface the proxy is built on redefines one of the core
Object methods. Easymock is correctly expecting to catch all equals
call with Object.class.getDeclaredMethod(equals, new Class[]
{Object.class}).equals(method) which is not the case without my patch.
Still curious.. :-)
It's not an error for an interface to declare a method that matches
an Object method (such as equals), and then for some bytecode somewhere
to INVOKEINTERFACE that method, even though INVOKEVIRTUAL would make
more sense. E.g. code somewhere in Eclipse does this.
No, it's not an error and it actually mostly works just like everyone
expects it to. Excepted that Sun stated special cases in the javadoc of
Proxy :
An invocation of the hashCode, equals, or toString methods declared in
java.lang.Object on a proxy instance will be encoded and dispatched to
the invocation handler's invoke method in the same manner as interface
method invocations are encoded and dispatched, as described above. The
declaring class of the Method object passed to invoke will be
java.lang.Object.
So isn't this an easymock bug? In such a case, wouldn't easymock fail
to catch a valid equals() invocation?
Seen the javadoc, I think that easymock devs did the right thing and
maybe that Java designers did this on that very purpose : catching all
core methods in an InvocationHandler is easy
-Archie
Olivier
Re: [cp-patches] RFC: fix in proxy creation of interfaces redefining toString, equals or hashCode
Olivier Jolly wrote: It's not an error for an interface to declare a method that matches an Object method (such as equals), and then for some bytecode somewhere to INVOKEINTERFACE that method, even though INVOKEVIRTUAL would make more sense. E.g. code somewhere in Eclipse does this. No, it's not an error and it actually mostly works just like everyone expects it to. Excepted that Sun stated special cases in the javadoc of Proxy : An invocation of the hashCode, equals, or toString methods declared in java.lang.Object on a proxy instance will be encoded and dispatched to the invocation handler's invoke method in the same manner as interface method invocations are encoded and dispatched, as described above. The declaring class of the Method object passed to invoke will be java.lang.Object. Ah, thanks... I knew there had to be a kludge in there somewhere :-) -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [cp-patches] RFC: fix in proxy creation of interfaces redefining toString, equals or hashCode
Hi Olivier, On Mon, 2006-02-20 at 14:23 +0100, Olivier Jolly wrote: First I wanted to implement it with a contains, but unfortunately, contains relies on equals, which will check that the declaring class are the same before saying that two methods are equals. In this case, we know we have the same methods expected that the declaring class are differents, that's the whole point of the fix [...] Doh. Right. So much for the insightful peer review... Please do add a little comment for the isCoreObjectMethod() method saying this. Just for people like me that might want to be clever and update the code to be more efficient. Although your new Mauve patches will now catch them if they try this :) Thanks, Mark signature.asc Description: This is a digitally signed message part
[cp-patches] Zip patch, perhaps
Embarrassingly, I can't actually get classpath to build - all of the
compilers I've tried get upset in ways I so far haven't been able to
diagnose. So this patch is untested to the point that I don't even
know it compiles, let alone works and doesn't introduce regressions. I
think it's pretty straightforward though.
The patch is to fix the values in ZipConstants that are declared as
ints in Classpath but longs in the JDK - newly caught by Japi's
ability to find public things in non-public superclasses. Why they're
longs is completely inexplicable since all of them are within the
range of int, and in fact we had the right values already. None of
them are even negative so there's no possibility of any sign-related
weirdness in their bit patterns when extended to longs.
If someone could compile and mauve this and, if it passes, check it
in, that would be much appreciated.
2006-02-20 Stuart Ballard [EMAIL PROTECTED]
* java/util/zip/ZipConstants.java
(LOCSIG): Change type to long.
(EXTSIG): Likewise.
(CENSIG): Likewise.
(ENDSIG): Likewise.
* javax/swing/undo/StateEditable.java
(writeLeInt): New overload with parameter as long.
--
http://sab39.dev.netreach.com/
? classpath-swing-undo.patch
? classpath-zip-patch.diff
Index: java/util/zip/ZipConstants.java
===
RCS file: /sources/classpath/classpath/java/util/zip/ZipConstants.java,v
retrieving revision 1.6
diff -u -r1.6 ZipConstants.java
--- java/util/zip/ZipConstants.java 2 Jul 2005 20:32:44 - 1.6
+++ java/util/zip/ZipConstants.java 20 Feb 2006 18:34:47 -
@@ -41,7 +41,7 @@
{
/* The local file header */
int LOCHDR = 30;
- int LOCSIG = 'P'|('K'8)|(316)|(424);
+ long LOCSIG = 'P'|('K'8)|(316)|(424);
int LOCVER = 4;
int LOCFLG = 6;
@@ -54,7 +54,7 @@
int LOCEXT = 28;
/* The Data descriptor */
- int EXTSIG = 'P'|('K'8)|(716)|(824);
+ long EXTSIG = 'P'|('K'8)|(716)|(824);
int EXTHDR = 16;
int EXTCRC = 4;
@@ -62,7 +62,7 @@
int EXTLEN = 12;
/* The central directory file header */
- int CENSIG = 'P'|('K'8)|(116)|(224);
+ long CENSIG = 'P'|('K'8)|(116)|(224);
int CENHDR = 46;
int CENVEM = 4;
@@ -82,7 +82,7 @@
int CENOFF = 42;
/* The entries in the end of central directory */
- int ENDSIG = 'P'|('K'8)|(516)|(624);
+ long ENDSIG = 'P'|('K'8)|(516)|(624);
int ENDHDR = 22;
/* The following two fields are missing in SUN JDK */
Index: java/util/zip/ZipOutputStream.java
===
RCS file: /sources/classpath/classpath/java/util/zip/ZipOutputStream.java,v
retrieving revision 1.11
diff -u -r1.11 ZipOutputStream.java
--- java/util/zip/ZipOutputStream.java 30 Aug 2005 21:47:44 - 1.11
+++ java/util/zip/ZipOutputStream.java 20 Feb 2006 18:34:47 -
@@ -159,6 +159,15 @@
writeLeShort(value);
writeLeShort(value 16);
}
+ /**
+ * Write a long value as an int. Some of the zip constants
+ * are declared as longs even though they fit perfectly well
+ * into integers.
+ */
+ private void writeLeInt(long value) throws IOException
+ {
+writeLeInt((int) value);
+ }
/**
* Starts a new Zip entry. It automatically closes the previous
[cp-patches] Re: Zip patch, perhaps
D'oh, screwed up the changelog (can you tell I copy and pasted it from my previous patch?) Obviously should have been: 2006-02-20 Stuart Ballard [EMAIL PROTECTED] * java/util/zip/ZipConstants.java (LOCSIG): Change type to long. (EXTSIG): Likewise. (CENSIG): Likewise. (ENDSIG): Likewise. * java/util/zip/ZipOutputStream.java (writeLeInt): New overload with parameter as long. -- http://sab39.dev.netreach.com/
[cp-patches] FYI: Make gnu charset Provider constructor package private
Hi,
Small patch to make the gnu charset Provider constructor package
private. This prevents adding a new accessor when provider() creates a
PrivilegedAction to create one. And helps with gcj 4.0.x which didn't
create the accessor constructor at all.
2006-02-20 Mark Wielaard [EMAIL PROTECTED]
* gnu/java/nio/charset/Provider.java (Provider): Package private.
Committed,
Mark
diff -u -r1.8 Provider.java
--- gnu/java/nio/charset/Provider.java 13 Jan 2006 07:42:48 - 1.8
+++ gnu/java/nio/charset/Provider.java 20 Feb 2006 19:15:49 -
@@ -81,7 +81,8 @@
*/
private boolean extendedLoaded;
- private Provider ()
+ // Package private to avoid an accessor method in PrivilegedAction below.
+ Provider ()
{
extendedLoaded = false;
canonicalNames = new HashMap ();
signature.asc
Description: This is a digitally signed message part
[cp-patches] [generics] RFC: new Enum java.math.RoundingMode
This is RFC because it's my first commit to the generics branch and I
just want to make sure there aren't any special procedures I forgot.
2006-02-20 Anthony Balkissoon [EMAIL PROTECTED]
* java/math/RoundingMode: New Enum.
--Tony
? include/gnu_java_net_PlainDatagramSocketImpl.h
? include/gnu_java_net_PlainSocketImpl.h
Index: java/math/RoundingMode.java
===
RCS file: java/math/RoundingMode.java
diff -N java/math/RoundingMode.java
--- /dev/null 1 Jan 1970 00:00:00 -
+++ java/math/RoundingMode.java 20 Feb 2006 20:07:39 -
@@ -0,0 +1,40 @@
+package java.math;
+
+public enum RoundingMode
+{
+ UP, DOWN, CEILING, FLOOR, HALF_UP, HALF_DOWN, HALF_EVEN, UNNECESSARY;
+
+ /**
+ * Returns the RoundingMode object corresponding to the legacy rounding modes
+ * in BigDecimal.
+ * @param rm the legacy rounding mode
+ * @return the corresponding RoundingMode
+ */
+ public static RoundingMode valueOf(int rm)
+ {
+switch (rm)
+ {
+ case BigDecimal.ROUND_CEILING:
+return CEILING;
+ case BigDecimal.ROUND_FLOOR:
+return FLOOR;
+ case BigDecimal.ROUND_DOWN:
+return DOWN;
+ case BigDecimal.ROUND_UP:
+return UP;
+ case BigDecimal.ROUND_HALF_UP:
+return HALF_UP;
+ case BigDecimal.ROUND_HALF_DOWN:
+return HALF_DOWN;
+ case BigDecimal.ROUND_HALF_EVEN:
+return HALF_EVEN;
+ case BigDecimal.ROUND_UNNECESSARY:
+return UNNECESSARY;
+ default:
+throw new
+ IllegalArgumentException(invalid argument: + rm +
+ . Argument should be one of the +
+ rounding modes defined in BigDecimal.);
+ }
+ }
+}
Re: [cp-patches] RFC: fix in proxy creation of interfaces redefining toString, equals or hashCode
Mark Wielaard a écrit :
Please do add a little comment for the isCoreObjectMethod() method
saying this. Just for people like me that might want to be clever and
update the code to be more efficient. Although your new Mauve patches
will now catch them if they try this :)
Ok, commited with an extra comment for this method
2006-02-20 Olivier Jolly [EMAIL PROTECTED]
* java/lang/reflect/Proxy.java
(ProxyData.getProxyData): Skipped overriding of core methods.
(ProxyData.isCoreObjectMethod): New method.
Thanks,
Mark
Olivier
Index: Proxy.java
===
RCS file: /sources/classpath/classpath/java/lang/reflect/Proxy.java,v
retrieving revision 1.25
diff -u -r1.25 Proxy.java
--- Proxy.java 21 Oct 2005 00:30:28 - 1.25
+++ Proxy.java 20 Feb 2006 20:16:42 -
@@ -1,5 +1,5 @@
/* Proxy.java -- build a proxy class that implements reflected interfaces
- Copyright (C) 2001, 2002, 2003, 2004, 2005 Free Software Foundation, Inc.
+ Copyright (C) 2001, 2002, 2003, 2004, 2005, 2006 Free Software Foundation, Inc.
This file is part of GNU Classpath.
@@ -42,6 +42,7 @@
import java.io.Serializable;
import java.security.ProtectionDomain;
+import java.util.Arrays;
import java.util.HashMap;
import java.util.HashSet;
import java.util.Iterator;
@@ -732,6 +733,12 @@
int j = methods.length;
while (--j = 0)
{
+ if (isCoreObjectMethod(methods[j]))
+{
+ // In the case of an attempt to redefine a public non-final
+ // method of Object, we must skip it
+ continue;
+}
ProxySignature sig = new ProxySignature(methods[j]);
ProxySignature old = (ProxySignature) method_set.put(sig, sig);
if (old != null)
@@ -752,6 +759,41 @@
}
return data;
}
+
+/**
+ * Checks whether the method is similar to a public non-final method of
+ * Object or not (i.e. with the same name and parameter types). Note that we
+ * can't rely, directly or indirectly (via Collection.contains) on
+ * Method.equals as it would also check the declaring class, what we do not
+ * want. We only want to check that the given method have the same signature
+ * as a core method (same name and parameter types)
+ *
+ * @param method the method to check
+ * @return whether the method has the same name and parameter types as
+ * Object.equals, Object.hashCode or Object.toString
+ * @see java.lang.Object#equals(Object)
+ * @see java.lang.Object#hashCode()
+ * @see java.lang.Object#toString()
+ */
+private static boolean isCoreObjectMethod(Method method)
+{
+ String methodName = method.getName();
+ if (methodName.equals(equals))
+{
+ return Arrays.equals(method.getParameterTypes(),
+ new Class[] { Object.class });
+}
+ if (methodName.equals(hashCode))
+{
+ return method.getParameterTypes().length == 0;
+}
+ if (methodName.equals(toString))
+{
+ return method.getParameterTypes().length == 0;
+}
+ return false;
+}
+
} // class ProxyData
/**
Re: [cp-patches] [generics] RFC: new Enum java.math.RoundingMode
On Mon, 2006-02-20 at 15:09 -0500, Anthony Balkissoon wrote:
This is RFC because it's my first commit to the generics branch and I
just want to make sure there aren't any special procedures I forgot.
2006-02-20 Anthony Balkissoon [EMAIL PROTECTED]
* java/math/RoundingMode: New Enum.
--Tony
This is replaced by:
2006-02-20 Anthony Balkissoon [EMAIL PROTECTED]
* java/math/MathContext.java: New class.
* java/math/RoundingMode: New Enum.
Also, I forgot to put the GNU Classpath header in RoundingMode, but this
patch includes it. Comments are still appreciated. I'll commit this
tomorrow if no one objects.
--Tony
Index: java/math/MathContext.java
===
RCS file: java/math/MathContext.java
diff -N java/math/MathContext.java
--- /dev/null 1 Jan 1970 00:00:00 -
+++ java/math/MathContext.java 20 Feb 2006 22:30:02 -
@@ -0,0 +1,195 @@
+/* MathContext.java --
+ Copyright (C) 1999, 2000, 2002, 2004, 2005 Free Software Foundation, Inc.
+
+This file is part of GNU Classpath.
+
+GNU Classpath is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU Classpath is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU Classpath; see the file COPYING. If not, write to the
+Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+02110-1301 USA.
+
+Linking this library statically or dynamically with other modules is
+making a combined work based on this library. Thus, the terms and
+conditions of the GNU General Public License cover the whole
+combination.
+
+As a special exception, the copyright holders of this library give you
+permission to link this library with independent modules to produce an
+executable, regardless of the license terms of these independent
+modules, and to copy and distribute the resulting executable under
+terms of your choice, provided that you also meet, for each linked
+independent module, the terms and conditions of the license of that
+module. An independent module is a module which is not derived from
+or based on this library. If you modify this library, you may extend
+this exception to your version of the library, but you are not
+obligated to do so. If you do not wish to do so, delete this
+exception statement from your version. */
+
+
+package java.math;
+
+import java.io.Serializable;
+
+/**
+ * Immutable objects describing settings such as rounding mode and digit
+ * precision for numerical operations such as those in the BigDecimal class.
+ * @author Anthony Balkissoon abalkiss at redhat dot com
+ *
+ */
+public final class MathContext implements Serializable
+{
+ /** A MathContext for unlimited precision arithmetic * */
+ public static final MathContext UNLIMITED =
+new MathContext(0, RoundingMode.HALF_UP);
+
+ /**
+ * A MathContext for the IEEE 754R Decimal32 format - 7 digit preicision and
+ * HALF_EVEN rounding.
+ */
+ public static final MathContext DECIMAL32 =
+new MathContext(7, RoundingMode.HALF_EVEN);
+
+ /**
+ * A MathContext for the IEEE 754R Decimal64 format - 16 digit preicision and
+ * HALF_EVEN rounding.
+ */
+ public static final MathContext DECIMAL64 =
+new MathContext(16, RoundingMode.HALF_EVEN);
+
+ /**
+ * A MathContext for the IEEE 754R Decimal128 format - 34 digit preicision and
+ * HALF_EVEN rounding.
+ */
+ public static final MathContext DECIMAL128 =
+new MathContext(34, RoundingMode.HALF_EVEN);
+
+ /**
+ * This is the serialVersionUID reported here:
+ * java.sun.com/j2se/1.5.0/docs/api/serialized-form.html#java.math.MathContext
+ */
+ private static final long serialVersionUID = 5579720004786848255L;
+
+ private int precision;
+
+ private RoundingMode roundMode;
+
+ /**
+ * Constructs a new MathContext with the specified precision and with HALF_UP
+ * rounding.
+ * @param setPrecision the precision for the new MathContext
+ *
+ * @throws IllegalArgumentException if precision is 0.
+ */
+ public MathContext(int setPrecision)
+ {
+this(setPrecision, RoundingMode.HALF_UP);
+ }
+
+ /**
+ * Constructs a new MathContext with the specified precision and rounding
+ * mode.
+ * @param setPrecision the precision
+ * @param setRoundingMode the rounding mode
+ *
+ * @throws IllegalArgumentException if precision is 0.
+ */
+ public MathContext(int setPrecision, RoundingMode setRoundingMode)
+ {
+if (setPrecision 0)
+ throw new IllegalArgumentException(Precision cannot be less than zero.);
+precision =
[cp-patches] Re: RFC: Some cairo error reporting help
On Sat, 2006-02-18 at 17:20 +0100, Mark Wielaard wrote: Hi, We currently just crash and burn when we have trouble with cairo. This doesn't really help the user. The following make sure we output a stack trace and reset the cairo status after a failed drawing operation. Which will hopefully help the user determine how to work around things. 2006-02-18 Mark Wielaard [EMAIL PROTECTED] * native/jni/gtk-peer/gnu_java_awt_peer_gtk_GdkGraphics2D.c (begin_drawing_operation): Output stacktrace and return on bad cairo status. (end_drawing_operation): Likewise. And reset cairo_t. Does this seem useful? Yes, please commit. Thanks, Tom Sample output: java.lang.InternalError: out of memory at gnu.java.awt.peer.gtk.GdkGraphics2D.cairoFill (Native Method) at gnu.java.awt.peer.gtk.GdkGraphics2D.fillRect (GdkGraphics2D.java:1076) at com.jgoodies.plaf.plastic.PlasticUtils.add3DEffekt (PlasticUtils.java:257) at com.jgoodies.plaf.plastic.PlasticUtils.addLight3DEffekt (PlasticUtils.java:285) at com.jgoodies.plaf.plastic.PlasticToolBarUI.update (PlasticToolBarUI.java:164) [...] I don't know the status of the Graphics2D rewrite that Tom was working on. Maybe that makes this hack unnecessary. If it interferes with that please yell and scream. I haven't actually found and fixed any real problems with this patch yet. Cheers, Mark
[cp-patches] RFC: Scrollbar fixes for old Events and setting value
Hi,
The GtkScrollbarPeer wasn't setting the new value on the Scrollbar
component. And Component didn't handle translation of the
AdjustmentEvents to old style Events for use in handleEvent(). My test
application was using old style Events. It ignored the actual value in
the Event. And tried to use the Scrollbar.getValue() result to adjust
some properties. With this patch this all works now.
2006-02-20 Mark Wielaard [EMAIL PROTECTED]
* java/awt/Component.java (translateEvent): Translate
AdjustmentEvents to 1.0 Events.
* gnu/java/awt/peer/gtk/GtkScrollbarPeer.java (changing): New field.
(setValues): Check whether we are currently changing and being called
back from the Scrollbar component.
(setBarValues): New native method.
(postAdjustmentEvent): Set new Scrollbar value.
* native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkScrollbarPeer.c
(Java_gnu_java_awt_peer_gtk_GtkScrollbarPeer_setValues): Renamed to
Java_gnu_java_awt_peer_gtk_GtkScrollbarPeer_setBarValue
* include/gnu_java_awt_peer_gtk_GtkScrollbarPeer.h: Regenerated.
My main question is whether the loopback protection is correct. I got
the idea from GtkCheckboxPeer.
All vte tests using Scrollbars also still work.
Cheers,
Mark
Index: java/awt/Component.java
===
RCS file: /cvsroot/classpath/classpath/java/awt/Component.java,v
retrieving revision 1.100
diff -u -r1.100 Component.java
--- java/awt/Component.java 15 Feb 2006 20:55:07 - 1.100
+++ java/awt/Component.java 20 Feb 2006 22:31:13 -
@@ -1,5 +1,6 @@
/* Component.java -- a graphics component
- Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004 Free Software Foundation
+ Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2006
+ Free Software Foundation
This file is part of GNU Classpath.
@@ -40,6 +41,7 @@
import java.awt.dnd.DropTarget;
import java.awt.event.ActionEvent;
+import java.awt.event.AdjustmentEvent;
import java.awt.event.ComponentEvent;
import java.awt.event.ComponentListener;
import java.awt.event.FocusEvent;
@@ -4876,6 +4878,25 @@
0, 0, oldKey, oldMods);
}
}
+else if (e instanceof AdjustmentEvent)
+ {
+ AdjustmentEvent ae = (AdjustmentEvent) e;
+ int type = ae.getAdjustmentType();
+ int oldType;
+ if (type == AdjustmentEvent.BLOCK_DECREMENT)
+ oldType = Event.SCROLL_PAGE_UP;
+ else if (type == AdjustmentEvent.BLOCK_INCREMENT)
+ oldType = Event.SCROLL_PAGE_DOWN;
+ else if (type == AdjustmentEvent.TRACK)
+ oldType = Event.SCROLL_ABSOLUTE;
+ else if (type == AdjustmentEvent.UNIT_DECREMENT)
+ oldType = Event.SCROLL_LINE_UP;
+ else if (type == AdjustmentEvent.UNIT_INCREMENT)
+ oldType = Event.SCROLL_LINE_DOWN;
+ else
+ oldType = type;
+ translated = new Event(target, oldType, new Integer(ae.getValue()));
+ }
else if (e instanceof ActionEvent)
translated = new Event (target, Event.ACTION_EVENT,
((ActionEvent) e).getActionCommand ());
Index: gnu/java/awt/peer/gtk/GtkScrollbarPeer.java
===
RCS file: /cvsroot/classpath/classpath/gnu/java/awt/peer/gtk/GtkScrollbarPeer.java,v
retrieving revision 1.19
diff -u -r1.19 GtkScrollbarPeer.java
--- gnu/java/awt/peer/gtk/GtkScrollbarPeer.java 2 Jul 2005 20:32:12 - 1.19
+++ gnu/java/awt/peer/gtk/GtkScrollbarPeer.java 20 Feb 2006 22:31:13 -
@@ -1,5 +1,5 @@
/* GtkScrollbarPeer.java -- Implements ScrollbarPeer with GTK+
- Copyright (C) 1998, 1999, 2005 Free Software Foundation, Inc.
+ Copyright (C) 1998, 1999, 2005, 2006 Free Software Foundation, Inc.
This file is part of GNU Classpath.
@@ -46,6 +46,10 @@
public class GtkScrollbarPeer extends GtkComponentPeer
implements ScrollbarPeer
{
+ // Set to true if we are just setting the new value.
+ // Prevents looping between component and peer setValue() calls.
+ private boolean changing;
+
void create ()
{
Scrollbar sb = (Scrollbar) awtComponent;
@@ -69,11 +73,30 @@
public native void setLineIncrement(int amount);
public native void setPageIncrement(int amount);
- public native void setValues(int value, int visible, int min, int max);
+ public void setValues(int value, int visible, int min, int max)
+ {
+// If we were the one just setting a new value, don't set it again.
+if (changing Thread.currentThread() == GtkToolkit.mainThread)
+ {
+changing = false;
+return;
+ }
+setBarValues(value, visible, min, max);
+ }
+
+ private native void setBarValues(int value, int visible, int min, int max);
+
+ /**
+ * Called from the native site when the scrollbar changed.
+ * Notifies the Scrollbar component and posts an event.
+ */
protected void postAdjustmentEvent (int type, int value)
{
-q().postEvent (new AdjustmentEvent ((Adjustable)awtComponent,
+Scrollbar bar = (Scrollbar) awtComponent;
+
[cp-patches] Re: RFC: Scrollbar fixes for old Events and setting value
On Mon, 2006-02-20 at 23:31 +0100, Mark Wielaard wrote: Hi, The GtkScrollbarPeer wasn't setting the new value on the Scrollbar component. And Component didn't handle translation of the AdjustmentEvents to old style Events for use in handleEvent(). My test application was using old style Events. It ignored the actual value in the Event. And tried to use the Scrollbar.getValue() result to adjust some properties. With this patch this all works now. 2006-02-20 Mark Wielaard [EMAIL PROTECTED] * java/awt/Component.java (translateEvent): Translate AdjustmentEvents to 1.0 Events. * gnu/java/awt/peer/gtk/GtkScrollbarPeer.java (changing): New field. (setValues): Check whether we are currently changing and being called back from the Scrollbar component. (setBarValues): New native method. (postAdjustmentEvent): Set new Scrollbar value. * native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkScrollbarPeer.c (Java_gnu_java_awt_peer_gtk_GtkScrollbarPeer_setValues): Renamed to Java_gnu_java_awt_peer_gtk_GtkScrollbarPeer_setBarValue * include/gnu_java_awt_peer_gtk_GtkScrollbarPeer.h: Regenerated. My main question is whether the loopback protection is correct. I got the idea from GtkCheckboxPeer. I think there is a deadlock risk with this patch and with GtkCheckboxPeer. postAdjustmentEvent is called with the GDK lock held and calls the synchronized method Scrollbar.setValues. Scrollbar.setValues calls GtkScrollbarPeer.setValues which acquires the GDK lock. So there's the potential for mutual embrace if a thread other than the GTK main thread calls Scrollbar.setValues at the right time. Why not just set the new value upon receiving the posted AdjustmentEvent in Scrollbar.processAdjustmentEvent rather than directly in GtkScrollbarPeer.postAdjustmentEvent? Tom
[cp-patches] FYI: fixed backward selection
Hi,
in one of my former patches that added or modified the selection actions I
introduced a problem where it was not possible to select the first entry in a
document.
This is fixed by this patch.
2006-02-20 Robert Schuster [EMAIL PROTECTED]
* javax/swing/text/DefaultEditorKit.java: Fixed comparison
in backward selection action.
cya
Robert
Index: javax/swing/text/DefaultEditorKit.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/text/DefaultEditorKit.java,v
retrieving revision 1.29
diff -u -r1.29 DefaultEditorKit.java
--- javax/swing/text/DefaultEditorKit.java 16 Feb 2006 08:45:28 - 1.29
+++ javax/swing/text/DefaultEditorKit.java 20 Feb 2006 21:16:38 -
@@ -908,7 +908,7 @@
{
int offs = t.getCaretPosition() - 1;
-if(offs 0)
+if(offs = 0)
{
Caret c = t.getCaret();
c.moveDot(offs);
signature.asc
Description: OpenPGP digital signature
[cp-patches] RFC: fixed implemented highlighting
Hi,
I am surprised myself but I really got this working. :)
What I fixed here are mainly drawing problems. The underlying representation of
the highlighted area was mostly correct. There are some small glitches in the
behavior which I am going to fix next.
Please comment the patch.
The ChangeLog:
2006-02-21 Robert Schuster [EMAIL PROTECTED]
* javax/swing/plaf/basic/BasicTextUI.java:
(paint): Remove unneccessary part of the if-expression.
(damageRange): Added case where the range spans multiple lines.
* javax/swing/text/DefaultCaret.java:
(clearHighlight): New method.
(handleHighlight): Removed unneccessary part of the if-expression.
(setDot): Use clearHighlight method.
* javax/swing/text/DefaultHighlighter.java: Use ArrayList instead
of Vector.
(paint): Prevented calling size() on every loop iteration, fixed
calculation of allocation area bounds.
(getHighlights): Implemented.
(removeHighlight): Mark damaged area in textcomponent.
(addHighlight): Mark damaged area in textcomponent.
(changeHighlight): Mark damaged area in textcomponent.
(DefaultHighlighter.HighlightEntry): Made it a real
Highlighter.Highlight implementation.
(DefaultHighlighter.DefaultHighlightPainter.paint): Fixed
calculations.
cya
Robert
Index: javax/swing/text/DefaultCaret.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/text/DefaultCaret.java,v
retrieving revision 1.30
diff -u -r1.30 DefaultCaret.java
--- javax/swing/text/DefaultCaret.java 9 Feb 2006 17:15:33 - 1.30
+++ javax/swing/text/DefaultCaret.java 20 Feb 2006 23:28:47 -
@@ -577,7 +577,39 @@
{
return mark;
}
-
+
+ private void clearHighlight()
+ {
+Highlighter highlighter = textComponent.getHighlighter();
+
+if (highlighter == null)
+ return;
+
+if (selectionVisible)
+ {
+try
+ {
+if (highlightEntry == null)
+ highlightEntry = highlighter.addHighlight(0, 0, getSelectionPainter());
+else
+ highlighter.changeHighlight(highlightEntry, 0, 0);
+ }
+catch (BadLocationException e)
+ {
+// This should never happen.
+throw new InternalError();
+ }
+ }
+else
+ {
+if (highlightEntry != null)
+ {
+highlighter.removeHighlight(highlightEntry);
+highlightEntry = null;
+ }
+ }
+ }
+
private void handleHighlight()
{
Highlighter highlighter = textComponent.getHighlighter();
@@ -588,7 +620,7 @@
int p0 = Math.min(dot, mark);
int p1 = Math.max(dot, mark);
-if (selectionVisible p0 != p1)
+if (selectionVisible)
{
try
{
@@ -818,6 +850,7 @@
if (doc != null)
this.dot = Math.min(dot, doc.getLength());
this.dot = Math.max(this.dot, 0);
+
handleHighlight();
adjustVisibility(this);
appear();
@@ -842,7 +875,8 @@
this.dot = Math.min(dot, doc.getLength());
this.dot = Math.max(this.dot, 0);
this.mark = this.dot;
-handleHighlight();
+
+clearHighlight();
adjustVisibility(this);
appear();
}
Index: javax/swing/text/DefaultHighlighter.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/text/DefaultHighlighter.java,v
retrieving revision 1.6
diff -u -r1.6 DefaultHighlighter.java
--- javax/swing/text/DefaultHighlighter.java 19 Oct 2005 14:57:30 - 1.6
+++ javax/swing/text/DefaultHighlighter.java 20 Feb 2006 23:28:47 -
@@ -40,9 +40,10 @@
import java.awt.Color;
import java.awt.Graphics;
+import java.awt.Insets;
import java.awt.Rectangle;
import java.awt.Shape;
-import java.util.Vector;
+import java.util.ArrayList;
public class DefaultHighlighter extends LayeredHighlighter
{
@@ -84,7 +85,7 @@
// This should never occur.
return;
}
-
+
if (r0 == null || r1 == null)
return;
@@ -100,7 +101,7 @@
paintHighlight(g, r0);
return;
}
-
+
// First line, from p0 to end-of-line.
r0.width = rect.x + rect.width - r0.x;
paintHighlight(g, r0);
@@ -109,15 +110,17 @@
// have the same height -- not a good assumption with JEditorPane/JTextPane).
r0.y += r0.height;
r0.x = rect.x;
-
+ r0.width = rect.width;
+
while (r0.y r1.y)
{
paintHighlight(g, r0);
r0.y += r0.height;
}
- // Last line, from beginnin-of-line to p1.
- paintHighlight(g, r1);
+ // Last line, from beginning-of-line to p1.
+ r0.width = r1.x + r1.width;
+ paintHighlight(g, r0);
}
public Shape paintLayer(Graphics g, int p0, int p1, Shape bounds,
@@ -127,7 +130,7 @@
}
}
- private class HighlightEntry
+ private class HighlightEntry
