Re: [cp-patches] RFC: Class Loader patch to record class with initiating class loader
Hi, On Wed, 2005-07-27 at 13:18 +0200, Jeroen Frijters wrote: While digging around the class loading issues, I discovered that we didn't record a class with the initiating loader [1]. This is necessary to maintain type safety in the face of buggy or malicious class loaders (or even when the contents of the directories in the classpath change). With this patch I am not completely sure what the semantics of VMClassLoader.USE_VM_CACHE are. If it is set to true registerInitiatingLoader() is called everywhere, but not for ClassLoader.defineClass(). This seems to complicate the VM interface a bit since it looks like the runtime can do this optimization of registering the initiating class loader everywhere itself, not just with VMClassLoader.defineClass(). So can we make the changes mostly to the VMClass/VMClassLoader method contracts? And push the default registerInitiatingLoader() implementation into those classes where applicable. That makes it possible for the runtime to keep this table completely internal and then it doesn't have to rely on two callbacks from Class and ClassLoader on each defineClass/forName/loadClass call and we could get rid of loadedClasses field in ClassLoader completely. I've also attached a Mauve test case that checks for everything I could think of. Nice, thanks! 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] cvs head 64-bit build breakage (java_nio_MappedByteBufferImpl.c)
Hi, On Thu, 2005-07-28 at 09:55 +0200, Christian Thalinger wrote: Just a small typo. But it seems noone is testing with 64-bits ;-) 2005-7-28 Christian Thalinger [EMAIL PROTECTED] * native/jni/java-nio/java_nio_MappedByteBufferImpl.c (get_raw_values): Fixed typo for 64-bit case. Thanks. Committed. 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: Class Loader patch to record class withinitiating class loader
Hi Jeroen, On Thu, 2005-07-28 at 10:52 +0200, Jeroen Frijters wrote: I agree that the call to registerInitiatingLoader() in ClassLoader.defineClass() is a bit iffy. The reason I left it in there is to not break any VMs when I check in this patch. I was a bit surprised by the fact that two people complained that JamVM broke with cvs head after my changes (I wasn't surprised that it broke, but I was surprised that people actually ran into this without knowing how to solve it). So I tried to be more careful with this change. To be honest I was also a bit surprised. Since in this case the change was so small and obvious. I am afraid there is not much we can do to make that experience better if the change to the runtime is readily available. And it was not like people were completely locked out from doing any work for more then a few hours since the solution was posted quickly when people asked for it (and I told several people on irc how to add the one line and made them happy I hope). But for a larger change like this it is probably good to get a sign-off by Robert, Stephen, Archie or any other runtime implementor who you know uses pristine Class/ClassLoader classes from GNU Classpath to make sure they agree that they will keep on using them. Or hear from people like Tom, David or Dalibor that the new interfaces will make it easier for them to adopt the GNU Classpath versions. If you have one or two runtime developers with you that say that the change is good and they can/will provide it soon (or at least by the time we do a new snapshot release) then I don't really see a problem checking changes in. We do have to make breaking changes from time to time and people cannot really expect non-released versions to work flawlessly all the time (otherwise we would do a release every day!). It is already possible to keep the table completely in the VM (in fact, this is what IKVM does), but you cannot get rid of the call in Class.forName() because the VM is not involved in that process. It looks like that is also what gcj and jamvm do already. That is why I am surprised that we really need the double callbacks everywhere. Does that make the interface really more flexible? In the case of Class.forName() you mean that when we need to delegate to ClassLoader.loadClass() we need to register the initial class loader explicitly because that class loader could load the class through delegation to one of its parents? Even though there is that one exception I would make the VMClass.loadClass(), VMClass.loadArrayClass() and VMClassLoader.defineClass() (reference) methods do the registration themselves. That seems to me to make some things easier for the runtime implementers that already do these things internally. But since I don't actually implement a runtime myself maybe I am just imagining things. 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] Patch for Review: JViewport overrides JComponent scrollRectToVisible
this is committed. On Wed, 2005-07-27 at 15:38 -0400, Anthony Balkissoon wrote: JComponent's scrollRectToVisible method simply passes the call up to the Component's parent. Components that can handle the call should override scrollRectToVisible. This patch implements the method for JViewport. Patch is pending approval. Patch is attached. 2005-07-27 Anthony Balkissoon [EMAIL PROTECTED] * javax/swing/JViewport.java: (scrollRectToVisible): New method, overrides JComponent method as intended. - Tony ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] Re: RFC: Class Loader patch to record classwithinitiating class loader
Hi, Jeroen Frijters jeroen at sumatra.nl writes: Mark Wielaard wrote: On Wed, 2005-07-27 at 13:18 +0200, Jeroen Frijters wrote: While digging around the class loading issues, I discovered that we didn't record a class with the initiating loader [1]. This is necessary to maintain type safety in the face of buggy or malicious class loaders (or even when the contents of the directories in the classpath change). First of all, I've been up all night finishing off a release, I'm tired and my broken wrist is very sore, and I'm grouchy. I'm getting the excuses in early, because I'm really, really unhappy with this. Yes, I realised this problem over a year ago, and fixed JamVM then. While I was waiting for the VM interface to support it I overlayed ClassLoader, but stopped earlier this year because I was unable to support the latest snapshot and CVS head doing this (for various reasons I felt unable to propose a patch myself). With this patch I am not completely sure what the semantics of VMClassLoader.USE_VM_CACHE are. If it is set to true registerInitiatingLoader() is called everywhere, but not for ClassLoader.defineClass(). This seems to complicate the VM interface a bit since it looks like the runtime can do this optimization of registering the initiating class loader everywhere itself, not just with VMClassLoader.defineClass(). I agree with Mark here. I think the Class/VMClass/VMClassLoader interface is already too complex and this makes it worse. Class is trying to do too much, leading to lots of micro-methods: VMClassLoader.loadClass(...) VMClass.loadArrayClass(...) VMClass.initialize(...) VMClass.forName(str) and now: VMClassLoader.USE_VM_CACHE VMClassLoader.registerInitiatingLoader() All this for basically Class.forName(str, res, cl)! In my opinion, the logic for deciding whether to load via the bootstrap or via a classloader, whether to load an array or a normal class, initialization, and the managing of the cache is best done in the runtime for performance reasons. At the least the logic should be pushed into the VM reference classes, for VMs that want Classpath to do the work for them. At present, the runtime can't do it itself, without adding a measure of redundancy. It is already possible to keep the table completely in the VM (in fact, this is what IKVM does), but you cannot get rid of the call in Class.forName() because the VM is not involved in that process. And the reason you can't get rid of it is because the logic is in Class.forName (namely the call to classloader.loadClass()). Trying not to be partisan, in JamVM VMClassLoader.loadClass(...), VMClass.loadArrayClass(...) and VMClass.forName(str) all map down to the same native function (forName(s, r, cl)), which does the logic of Class.forName(s, r, cl) itself, and records initiating loaders. It was done this way before the VM interface matured, and I've preferred to keep it. It has the advantage that loadClass on a class loader will not be called if the VM can tell from its cache that the class loader has already defined the class, or is marked as an initiating loader for it. Flame away, Rob. Regards, Jeroen ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
RE: [cp-patches] RFC: Class Loader patch to record class withinitiating class loader
Archie Cobbs wrote: For what it's worth, JCVM maintains its own intiated types and defined types tables internally, so this patch does not make life better (or worse). I would have to disable this code. This raises the question, how many VMs are actually using the loadedClasses hashtable in ClassLoader? We know these aren't: JCVM, JamVM, gcj, IKVM It looks like JikesRVM is using it, others I don't know. Maybe we're better off leaving this up to the VM implementers? Regards, Jeroen ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] RFC: Class Loader patch to record class withinitiating class loader
Mark Wielaard wrote: But for a larger change like this it is probably good to get a sign-off by Robert, Stephen, Archie or any other runtime implementor who you know uses pristine Class/ClassLoader classes from GNU Classpath to make sure they agree that they will keep on using them. Or hear from people like Tom, David or Dalibor that the new interfaces will make it easier for them to adopt the GNU Classpath versions. If you have one or two runtime developers with you that say that the change is good and they can/will provide it soon (or at least by the time we do a new snapshot release) then I don't really see a problem checking changes in. We do have to make breaking changes from time to time and people cannot really expect non-released versions to work flawlessly all the time (otherwise we would do a release every day!). For what it's worth, JCVM maintains its own intiated types and defined types tables internally, so this patch does not make life better (or worse). I would have to disable this code. However the larger question of what is the right API is an interesting one... not sure I could venture an answer without a lot of review/study. One possibility I've considered is moving a lot more of the code out of the VM and into Java. This of course would require everyone agreeing on what that code should look like :-) But probably a bigger problem is what to do with the bootstrap loader, which must be usable before any classes are loaded. So in JCVM, the end result is like this: I have to do all the machinery in C anyway for the boot loader, so might as well re-use that same code for user-defined loaders... referring here to the code which e.g. checks whether the requested type is already in the initiated types tree, grabs mutexes, checks whether another thread is already loading the type, adds newly loaded types to the initiated types tree, etc. The net result is that a simpler API where the VM does most of the work is better in JCVM's case. In fact, the current code is more than JCVM needs -- it doesn't need the loadedClasses hash table (so the new USE_VM_CACHE flag is an improvement), nor most of the synchronization. But other VMs may be different of course. So this area is murky and highly VM specific which makes it hard to imagine what the best answer is. -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] RFC: Class Loader patch to record classwithinitiating class loader
Mark Wielaard wrote: It looks like that is also what gcj and jamvm do already. That is why I am surprised that we really need the double callbacks everywhere. Does that make the interface really more flexible? In the case of Class.forName() you mean that when we need to delegate to ClassLoader.loadClass() we need to register the initial class loader explicitly because that class loader could load the class through delegation to one of its parents? Exactly. Because of the broken design (really evolution) of ClassLoader it cannot be done there, so the hook in Class.forName() is definitely required (at least, I don't see any possible alternative). Even though there is that one exception I would make the VMClass.loadClass(), VMClass.loadArrayClass() and VMClassLoader.defineClass() (reference) methods do the registration themselves. Apart from VMClass.loadClass() (which doesn't actually exist), I would be fine with removing the additional registration calls and only doing that for the scenario where Class.forName() directly invokes ClassLoader.loadClass(). That seems to me to make some things easier for the runtime implementers that already do these things internally. I don't think it matters that much either way, because multiple registrations are harmless (other than that they're useless overhead of course), but a cleaner interface would ultimately be better. To sum up: Unless any of the VM implementers that rely on ClassLoader.loadedClasses speak up, I'm going to write a new version of my patch that is much simpler on the Classpath side and requires the VM to do the right thing. OK? Regards, Jeroen ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Re: RFC: Class Loader patch to record classwithinitiating class loader
Robert Lougher wrote: In my opinion, the logic for deciding whether to load via the bootstrap or via a classloader, whether to load an array or a normal class, initialization, and the managing of the cache is best done in the runtime for performance reasons. Most of what Robert said above is pretty much true in the same way for JCVM, so I agree :-) Perhaps there is some consensus to make this API simpler instead of more complicated. If we decide to keep it simple, what would definitely be helpful is comprehensive comments for these native methods sketching out what the VM should be doing (e.g., it's not immediately obvious when a type should be added to the initiated types tree, or even that a VM is required to maintain one). -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] RFC: Class Loader patch to record class withinitiating class loader
David Gilbert wrote: I hope when I mentioned that JamVM was broken, it didn't sound like a complaint, because that wasn't what I intended. Not at all. I was just a bit surprised that it is possible to live on the bleeding edge of development and still maintain the notion: how VMs work...as far as I'm concerned, they work by magic. :-) Mind you, I think that's actually a very good thing! Regards, Jeroen ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] FYI: New interfaces for DynamicAny.
2005-07-27 Audrius Meskauskas [EMAIL PROTECTED] * org/omg/DynamicAny/DynUnion.java, org/omg/DynamicAny/DynUnionOperations.java, org/omg/DynamicAny/NameDynAnyPair.java, org/omg/DynamicAny/NameValuePair.java, org/omg/DynamicAny/DynAny.java, org/omg/DynamicAny/DynAnyOperations.java, org/omg/DynamicAny/DynArray.java, org/omg/DynamicAny/DynArrayOperations.java, org/omg/DynamicAny/DynEnum.java, org/omg/DynamicAny/DynEnumOperations.java, org/omg/DynamicAny/DynFixed.java, org/omg/DynamicAny/DynFixedOperations.java, org/omg/DynamicAny/DynSequence.java, org/omg/DynamicAny/DynSequenceOperations.java, org/omg/DynamicAny/DynStructOperations.java, org/omg/DynamicAny/DynStruct.java: New files. DynamicAny.tar.gz Description: GNU Zip compressed data ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] RFC: Class Loader patch to record class with initiating class loader
Mark == Mark Wielaard [EMAIL PROTECTED] writes: We have some similar tweaks in the libgcj ClassLoader. And a while back I change our internals to register initiating loaders by adding classes to the loadedClasses map. So, I think this is a good idea. Mark So this change will make merging ClassLoader easier for you? Maybe. I haven't looked at all the changes in detail yet. Tom ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] FYI: BasicListUI fixlet
Changed KeyEvent.isShiftDown() and KeyEvent.isControlDown() to
comparisons between KeyEvent.getModifiers() and InputEvent.SHIFT_MASK
and CTRL_MASK.
Also switched the order of shift and control handling in
MouseInputHandler.mousePressed to correspond to the JDK's behaviour.
Patch attached.
2005-07-28 Anthony Balkissoon [EMAIL PROTECTED]
* javax/swing/plaf/basic/BasicListUI.java:
(KeyHandler.keyPressed): Replaced calls to KeyEvent.isShiftDown() and
isControlDown() with comparisons of KeyEvent.getModifiers() and
InputEvent.SHIFT_MASK and CTRL_MASK.
(MouseInputHandler.mouseClicked): Reordered SHIFT and CTRL modifier
actions to correspond to JDK. Note the JDK simply ignores other
modifiers so isShiftDown() and isControlDown() are okay for mouse
input.
-Tony
Index: javax/swing/plaf/basic/BasicListUI.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/plaf/basic/BasicListUI.java,v
retrieving revision 1.28
diff -u -r1.28 BasicListUI.java
--- javax/swing/plaf/basic/BasicListUI.java 27 Jul 2005 19:48:44 - 1.28
+++ javax/swing/plaf/basic/BasicListUI.java 28 Jul 2005 15:24:44 -
@@ -49,6 +49,7 @@
import java.awt.event.ComponentListener;
import java.awt.event.FocusEvent;
import java.awt.event.FocusListener;
+import java.awt.event.InputEvent;
import java.awt.event.KeyAdapter;
import java.awt.event.KeyEvent;
import java.awt.event.MouseEvent;
@@ -208,12 +209,12 @@
if ((evt.getKeyCode() == KeyEvent.VK_DOWN)
|| (evt.getKeyCode() == KeyEvent.VK_KP_DOWN))
{
- if (!evt.isShiftDown())
+ if (evt.getModifiers() == 0)
{
BasicListUI.this.list.clearSelection();
BasicListUI.this.list.setSelectedIndex(Math.min(lead+1,max));
}
- else
+ else if (evt.getModifiers() == InputEvent.SHIFT_MASK)
{
BasicListUI.this.list.getSelectionModel().
setLeadSelectionIndex(Math.min(lead+1,max));
@@ -222,12 +223,12 @@
else if ((evt.getKeyCode() == KeyEvent.VK_UP)
|| (evt.getKeyCode() == KeyEvent.VK_KP_UP))
{
- if (!evt.isShiftDown())
+ if (evt.getModifiers() == 0)
{
BasicListUI.this.list.clearSelection();
BasicListUI.this.list.setSelectedIndex(Math.max(lead-1,0));
}
- else
+ else if (evt.getModifiers() == InputEvent.SHIFT_MASK)
{
BasicListUI.this.list.getSelectionModel().
setLeadSelectionIndex(Math.max(lead-1,0));
@@ -242,13 +243,16 @@
// FIXME: implement, need JList.ensureIndexIsVisible to work
}
else if (evt.getKeyCode() == KeyEvent.VK_BACK_SLASH
-evt.isControlDown())
+(evt.getModifiers() == InputEvent.CTRL_MASK))
{
BasicListUI.this.list.clearSelection();
}
else if ((evt.getKeyCode() == KeyEvent.VK_HOME)
|| evt.getKeyCode() == KeyEvent.VK_END)
{
+ if (evt.getModifiers() != 0
+ evt.getModifiers() != InputEvent.SHIFT_MASK)
+return;
// index is either 0 for HOME, or last cell for END
int index = (evt.getKeyCode() == KeyEvent.VK_HOME) ? 0 : max;
@@ -264,14 +268,16 @@
setLeadSelectionIndex(index);
}
else if ((evt.getKeyCode() == KeyEvent.VK_A || evt.getKeyCode()
-== KeyEvent.VK_SLASH) evt.isControlDown())
+== KeyEvent.VK_SLASH) (evt.getModifiers() ==
+ InputEvent.CTRL_MASK))
{
BasicListUI.this.list.setSelectionInterval(0, max);
// this next line is to restore the lead selection index to the old
// position, because select-all should not change the lead index
BasicListUI.this.list.addSelectionInterval(lead, lead);
}
- else if (evt.getKeyCode() == KeyEvent.VK_SPACE evt.isControlDown())
+ else if (evt.getKeyCode() == KeyEvent.VK_SPACE
+ (evt.getModifiers() == InputEvent.CTRL_MASK))
{
BasicListUI.this.list.getSelectionModel().
setLeadSelectionIndex(Math.min(lead+1,max));
@@ -300,17 +306,7 @@
int index = BasicListUI.this.locationToIndex(list, click);
if (index == -1)
return;
- if (event.isControlDown())
-{
- if (BasicListUI.this.list.getSelectionMode() ==
- ListSelectionModel.SINGLE_SELECTION)
-BasicListUI.this.list.setSelectedIndex(index);
- else if (BasicListUI.this.list.isSelectedIndex(index))
-BasicListUI.this.list.removeSelectionInterval(index,index);
- else
-BasicListUI.this.list.addSelectionInterval(index,index);
-}
- else if (event.isShiftDown())
+ if (event.isShiftDown())
{
[cp-patches] Re: RFC: New class loader patch proposal
Hi, On 7/28/05, Jeroen Frijters [EMAIL PROTECTED] wrote: Hi, Here's an alternative patch that rips out most of the complexity and leaves everything to the VM. It took me about three minutes to implement this new interface for IKVM, so I know I'm happy with it! The only thing missing that the documentation should be improved a bit. Rob and Archie, is this (close to) what you both need? Yes, I think it's perfect :) The problem's going to be gij/gcj. They have their own Class, but use the loaded class hashtable in ClassLoader. But I vote for this, it is so much cleaner. Rob. Regards, Jeroen ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] Re: RFC: New class loader patch proposal
Jeroen Frijters wrote: Here's an alternative patch that rips out most of the complexity and leaves everything to the VM. It took me about three minutes to implement this new interface for IKVM, so I know I'm happy with it! The only thing missing that the documentation should be improved a bit. Rob and Archie, is this (close to) what you both need? Yes, that looks great to me :-) My only comment is that findLoadedClass() needs some Javadoc. -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
[cp-patches] Patch: various bug fixes
These are many bugs I ran into when running several applications. There
are more I have found and will fix soon!
2005-07-28 Lillian Angel [EMAIL PROTECTED]
* java/awt/GridBagLayout.java
(distributeSizeAndWeight): added in check, because OutOfBounds
exception was being raised.
* javax/swing/JTable.java
(setRowHeight): Added in, but not implemented.
* javax/swing/plaf/basic/BasicComboBoxEditor.java
(setItem): added in check, because NullPointerException was
being raised.
* javax/swing/plaf/basic/BasicTreeUI.java
(getPathBounds): Took out unneeded call.
(uninstallListeners): added in check, because NPE was being
raised.
(installUI): took out unneeded call.
(paint): Likewise.
(getPreferredSize): Should not assume root is an instance of
DefaultMutableTreeNode. Changed to use TreeNode instead.
(getCellBounds): Should never return null
(getCellLocation): Took out unneeded call.
Index: java/awt/GridBagLayout.java
===
RCS file: /cvsroot/classpath/classpath/java/awt/GridBagLayout.java,v
retrieving revision 1.19
diff -u -r1.19 GridBagLayout.java
--- java/awt/GridBagLayout.java 10 Jul 2005 17:24:51 - 1.19
+++ java/awt/GridBagLayout.java 28 Jul 2005 19:27:26 -
@@ -913,7 +913,7 @@
sizes[start] = Math.max(sizes[start], size);
weights[start] = Math.max(weights[start], weight);
}
- else
+ else if (span 1)
{
int numOccupied = span;
int lastOccupied = -1;
Index: javax/swing/JTable.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/JTable.java,v
retrieving revision 1.36
diff -u -r1.36 JTable.java
--- javax/swing/JTable.java 25 Jul 2005 14:48:53 - 1.36
+++ javax/swing/JTable.java 28 Jul 2005 19:27:26 -
@@ -1469,7 +1469,20 @@
revalidate();
repaint();
}
-
+
+ /**
+ * Sets the value of the rowHeight property for the specified
+ * row.
+ *
+ * @param rh is the new rowHeight
+ * @param row is the row to change the rowHeight of
+ */
+ public void setRowHeight(int rh, int row)
+ {
+ setRowHeight(rh);
+ // FIXME: not implemented
+ }
+
/**
* Set the value of the [EMAIL PROTECTED] #rowMargin} property.
*
Index: javax/swing/plaf/basic/BasicComboBoxEditor.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/plaf/basic/BasicComboBoxEditor.java,v
retrieving revision 1.5
diff -u -r1.5 BasicComboBoxEditor.java
--- javax/swing/plaf/basic/BasicComboBoxEditor.java 8 Jul 2005 15:24:08 - 1.5
+++ javax/swing/plaf/basic/BasicComboBoxEditor.java 28 Jul 2005 19:27:27 -
@@ -91,7 +91,10 @@
*/
public void setItem(Object item)
{
-editor.setText(item.toString());
+ if (item == null)
+editor.setText();
+ else
+editor.setText(item.toString());
}
/**
Index: javax/swing/plaf/basic/BasicTreeUI.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/plaf/basic/BasicTreeUI.java,v
retrieving revision 1.48
diff -u -r1.48 BasicTreeUI.java
--- javax/swing/plaf/basic/BasicTreeUI.java 25 Jul 2005 17:37:48 - 1.48
+++ javax/swing/plaf/basic/BasicTreeUI.java 28 Jul 2005 19:27:27 -
@@ -588,8 +588,7 @@
TreeModel mod = tree.getModel();
DefaultMutableTreeNode root = (DefaultMutableTreeNode) mod.getRoot();
if (!tree.isRootVisible()
-tree.isExpanded(new TreePath(((DefaultMutableTreeNode) root)
- .getPath(
+tree.isExpanded(new TreePath(root)))
root = root.getNextNode();
Point loc = getCellLocation(0, 0, tree, mod, cell, root);
@@ -973,9 +972,14 @@
tree.removeKeyListener(keyListener);
tree.removePropertyChangeListener(selectionModelPropertyChangeListener);
tree.removeComponentListener(componentListener);
- tree.getCellEditor().removeCellEditorListener(cellEditorListener);
tree.removeTreeExpansionListener(treeExpansionListener);
- tree.getModel().removeTreeModelListener(treeModelListener);
+
+ TreeCellEditor tce = tree.getCellEditor();
+ if (tce != null)
+ tce.removeCellEditorListener(cellEditorListener);
+ TreeModel tm = tree.getModel();
+ if (tm != null)
+ tm.removeTreeModelListener(treeModelListener);
}
/**
@@ -1179,8 +1183,7 @@
tree = (JTree) c;
setModel(tree.getModel());
tree.setRootVisible(true);
- tree.expandPath(new TreePath(((DefaultMutableTreeNode)
-(tree.getModel()).getRoot()).getPath()));
+ tree.expandPath(new TreePath(tree.getModel().getRoot()));
treeSelectionModel = tree.getSelectionModel();
[cp-patches] FYI: BasicListUI PAGE UP and PAGE DOWN implemented
Implemented {,SHIFT-} PAGE {UP,DOWN} key action in BasicListUI. Also
had to make a small correction to JViewport's scrollRectToVisible that
PAGE DOWN revealed where we were off by 1 pixel.
Patch attached.
2005-07-28 Anthony Balkissoon [EMAIL PROTECTED]
* javax/swing/JViewport.java:
(scrollRectToVisible): Consider the x and y position of the viewport
itself when scrolling down. This fixes an off-by-1-pixel problem.
* javax/swing/plaf/basic/BasicListUI.java:
(KeyHandler.keyPressed): Implemented PAGEUP, SHIFT-PAGEUP, PAGEDOWN,
and SHIFT-PAGEDOWN key actions.
- Tony
Index: javax/swing/JViewport.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/JViewport.java,v
retrieving revision 1.23
diff -u -r1.23 JViewport.java
--- javax/swing/JViewport.java 28 Jul 2005 13:27:59 - 1.23
+++ javax/swing/JViewport.java 28 Jul 2005 19:36:31 -
@@ -517,7 +517,8 @@
else if (contentRect.y + viewBounds.y + contentRect.height
(portBounds.y+portBounds.height))
setViewPosition (new Point(pos.x, contentRect.y -
- (portBounds.height - contentRect.height)));
+ (portBounds.height - contentRect.height) -
+ portBounds.y));
// X-DIRECTION
pos = getViewPosition();
@@ -526,6 +527,7 @@
else if (contentRect.x + viewBounds.x + contentRect.width
(portBounds.x + portBounds.height))
setViewPosition (new Point(contentRect.x -
- (portBounds.width - contentRect.width), pos.y));
+ (portBounds.width - contentRect.width)
+ - portBounds.x, pos.y));
}
}
Index: javax/swing/plaf/basic/BasicListUI.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/plaf/basic/BasicListUI.java,v
retrieving revision 1.29
diff -u -r1.29 BasicListUI.java
--- javax/swing/plaf/basic/BasicListUI.java 28 Jul 2005 15:34:33 - 1.29
+++ javax/swing/plaf/basic/BasicListUI.java 28 Jul 2005 19:36:31 -
@@ -236,11 +236,41 @@
}
else if (evt.getKeyCode() == KeyEvent.VK_PAGE_UP)
{
- // FIXME: implement, need JList.ensureIndexIsVisible to work
+ int target;
+ if (lead == BasicListUI.this.list.getFirstVisibleIndex())
+{
+ target = Math.max
+(0, lead - (BasicListUI.this.list.getLastVisibleIndex() -
+ BasicListUI.this.list.getFirstVisibleIndex() + 1));
+}
+ else
+{
+ target = BasicListUI.this.list.getFirstVisibleIndex();
+}
+ if (evt.getModifiers() == 0)
+BasicListUI.this.list.setSelectedIndex(target);
+ else if (evt.getModifiers() == InputEvent.SHIFT_MASK)
+BasicListUI.this.list.getSelectionModel().
+ setLeadSelectionIndex(target);
}
else if (evt.getKeyCode() == KeyEvent.VK_PAGE_DOWN)
{
- // FIXME: implement, need JList.ensureIndexIsVisible to work
+ int target;
+ if (lead == BasicListUI.this.list.getLastVisibleIndex())
+{
+ target = Math.min
+(max, lead + (BasicListUI.this.list.getLastVisibleIndex() -
+ BasicListUI.this.list.getFirstVisibleIndex() + 1));
+}
+ else
+{
+ target = BasicListUI.this.list.getLastVisibleIndex();
+}
+ if (evt.getModifiers() == 0)
+BasicListUI.this.list.setSelectedIndex(target);
+ else if (evt.getModifiers() == InputEvent.SHIFT_MASK)
+BasicListUI.this.list.getSelectionModel().
+ setLeadSelectionIndex(target);
}
else if (evt.getKeyCode() == KeyEvent.VK_BACK_SLASH
(evt.getModifiers() == InputEvent.CTRL_MASK))
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] [RFA/JDWP] MethodCommandSet
This will implement the Method CommandSet
http://java.sun.com/j2se/1.5.0/docs/guide/jpda/jdwp/jdwp-protocol.html#JDWP_Method
It's fairly straight forward though the actual implementations for
LineTable and VariableTable will likely wait until we have a better hang
of how we deal with these in the VM.
thanks,
Aaron
ChangeLog
2005-07-28 Aaron Luchko [EMAIL PROTECTED]
*gnu/classpath/jdwp/processor/MethodCommandSet.java: Implemented
the Method CommandSet.
--- /dev/null 2005-06-09 16:29:11.371620296 -0400
+++ gnu/classpath/jdwp/processor/MethodCommandSet.java 2005-07-28 17:05:33.0 -0400
@@ -0,0 +1,159 @@
+/* MethodCommandSet.java -- class to implement the Method Command Set
+ Copyright (C) 2005 Free Software Foundation
+
+This file is part of GNU Classpath.
+
+GNU Classpath is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU Classpath is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU Classpath; see the file COPYING. If not, write to the
+Free Software Foundation, Inc., 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 gnu.classpath.jdwp.processor;
+
+import gnu.classpath.jdwp.IVirtualMachine;
+import gnu.classpath.jdwp.Jdwp;
+import gnu.classpath.jdwp.JdwpConstants;
+import gnu.classpath.jdwp.exception.JdwpException;
+import gnu.classpath.jdwp.exception.JdwpInternalErrorException;
+import gnu.classpath.jdwp.exception.NotImplementedException;
+import gnu.classpath.jdwp.id.IdManager;
+import gnu.classpath.jdwp.id.ObjectId;
+import gnu.classpath.jdwp.id.ReferenceTypeId;
+import gnu.classpath.jdwp.util.LineTable;
+import gnu.classpath.jdwp.util.VariableTable;
+
+import java.io.DataOutputStream;
+import java.io.IOException;
+import java.lang.reflect.Method;
+import java.nio.ByteBuffer;
+
+/**
+ * A class representing the Method Command Set.
+ *
+ * @author Aaron Luchko [EMAIL PROTECTED]
+ */
+public class MethodCommandSet implements CommandSet
+{
+ // Our hook into the jvm
+ private final IVirtualMachine vm = Jdwp.getIVirtualMachine();
+
+ // Manages all the different ids that are assigned by jdwp
+ private final IdManager idMan = Jdwp.getIdManager();
+
+ public boolean runCommand(ByteBuffer bb, DataOutputStream os, byte command)
+ throws JdwpException
+ {
+try
+ {
+switch (command)
+ {
+ case JdwpConstants.CommandSet.Method.LINE_TABLE:
+executeLineTable(bb, os);
+break;
+ case JdwpConstants.CommandSet.Method.VARIABLE_TABLE:
+executeVariableTable(bb, os);
+break;
+ case JdwpConstants.CommandSet.Method.BYTE_CODES:
+executeByteCodes(bb, os);
+break;
+ case JdwpConstants.CommandSet.Method.IS_OBSOLETE:
+executeIsObsolete(bb, os);
+break;
+ case JdwpConstants.CommandSet.Method.VARIABLE_TABLE_WITH_GENERIC:
+executeVariableTableWithGeneric(bb, os);
+break;
+ default:
+throw new NotImplementedException(
+ Command + command + not found in Method Command Set.);
+ }
+ }
+catch (IOException ex)
+ {
+// The DataOutputStream we're using isn't talking to a socket at all
+// So if we throw an IOException we're in serious trouble
+throw new JdwpInternalErrorException(ex);
+ }
+return true;
+ }
+
+ private void executeLineTable(ByteBuffer bb, DataOutputStream os)
+ throws JdwpException, IOException
+ {
+ReferenceTypeId refId = idMan.readReferenceTypeId(bb);
+Class clazz = refId.getType();
+
+ObjectId oid =
