Re: Duplicate object prevention policy
> The theoretical answer depends on lots of things, such as: > > 1) the probable number of times that the method will be called, > 2) the likelihood that the lookup (if implemented) will succeed, > 3) the cost of creating the object, > 4) the cost of the name lookup is, > 5) the incremental GC cost if duplicate copies of the object become > garbage, > 6) the incremental GC cost if the mapping data structure keeps > otherwise garbage objects alive, > 7) the incremental GC cost if the application keeps duplicate > copies of the objects alive, > 8) the (speculative) cost of using obj.equals(obj2) versus obj == obj2 > if we could guarantee that objects are ONLY created via the method, > 9) etcetera > > > And all of these depend on the nature of the objects and the way that they > are used in a typical application. In short, there are no general answers. Hi Steve, I know that this depends on a lot of things but I just wanted to know if this has been discussed before and if there is any "guide" for the most likely cases. I prefer a style of very clean "semantics" which means that I will implement the lookup in most cases, even if there my be some performance issues - if they're not too big. Jan signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Duplicate object prevention policy
Hello list, imagine the following case: A method supports the lookup of objects using a name -> object mapping. The objects are stored in a map but can easily be newly created instead of performing a real lookup. Shall we perform this real lookup even if the newly created object is equal to the original object in terms of Object.equals(). Concrete?: Have a look at java.awt.datatransfer.SystemFlavorMap#decodeDataFlavor(). This is only one appearance of this problem (out of many many). Jan signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: 0.19 "release meeting" - Wed Oct 19 21:00 UTC
> But feel free to just reply to this email with suggestions and ideas if > you cannot make it to the meeting. We will make sure to post a summary > of anything discussed to the list also. Hi all, I think I can not make it to the meeting today. But you should know that bug #24099 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24099) is blocking my further development at the moment. So I would like that this bug, with is more something like a feature request, is solved for 0.19. Because I don't know anything about GTK and GDK I'm not able to help here but will test any patch. Jan signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Need help with BasicTreeUI
There are still some problems running my custom TreeUI which inherits
from BasicTreeUI.
(updateCachedPreferredSize) was not implemented so I decided to move
most of the code from (getPreferredSize) to (updateCachedPreferredSize)
which is imho the best place for computing the size (see the patch
attached).
But now the TreeWorld in gnu.classpath.examples.swing.Demo doesn't work
anymore. The tree isn't even displayed because the preferred size is
0x0. But when I set preferredSize to at least 10x10 there are a lot of
bugs painting the tree.
Anybody out there who can help me to drag down this problem? I'm not
very familiar with painting in BasicTreeUI.
Jan
Index: BasicTreeUI.java
===
RCS
file: /cvsroot/classpath/classpath/javax/swing/plaf/basic/BasicTreeUI.java,v
retrieving revision 1.95
diff -u -r1.95 BasicTreeUI.java
--- BasicTreeUI.java13 Oct 2005 19:34:08 - 1.95
+++ BasicTreeUI.java13 Oct 2005 21:30:31 -
@@ -1160,7 +1160,7 @@
*/
protected void updateSize()
{
-preferredSize = null;
+validCachedPreferredSize = false;
updateCachedPreferredSize();
tree.treeDidChange();
}
@@ -1174,7 +1174,26 @@
*/
protected void updateCachedPreferredSize()
{
-// FIXME: not implemented
+int maxWidth = 0;
+boolean isLeaf = false;
+if (currentVisiblePath != null)
+ {
+Object[] path = currentVisiblePath.getPath();
+for (int i = 0; i < path.length; i++)
+ {
+TreePath curr = new TreePath(getPathToRoot(path[i], 0));
+Rectangle bounds = getPathBounds(tree,
+curr);
+if (treeModel != null)
+ isLeaf = treeModel.isLeaf(curr);
+if (hasControlIcons())
+ bounds.width += getCurrentControlIcon(curr).getIconWidth
();
+maxWidth = Math.max(maxWidth, bounds.x + bounds.width);
+ }
+preferredSize = new Dimension(maxWidth, (getRowHeight() *
path.length));
+ }
+preferredSize = new Dimension(0, 0);
+validCachedPreferredSize = true;
}
/**
@@ -1478,25 +1497,11 @@
public Dimension getPreferredSize(JComponent c, boolean
checkConsistancy)
{
// FIXME: checkConsistancy not implemented, c not used
-int maxWidth = 0;
-boolean isLeaf = false;
-if (currentVisiblePath != null)
+if(!validCachedPreferredSize)
{
-Object[] path = currentVisiblePath.getPath();
-for (int i = 0; i < path.length; i++)
- {
-TreePath curr = new TreePath(getPathToRoot(path[i], 0));
-Rectangle bounds = getPathBounds(tree,
-curr);
-if (treeModel != null)
- isLeaf = treeModel.isLeaf(curr);
-if (hasControlIcons())
- bounds.width += getCurrentControlIcon(curr).getIconWidth
();
-maxWidth = Math.max(maxWidth, bounds.x + bounds.width);
- }
-return new Dimension(maxWidth, (getRowHeight() * path.length));
+updateCachedPreferredSize();
}
-return new Dimension(0, 0);
+return preferredSize;
}
/**
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
