Re: [cp-patches] Patch: Opening RandomAccessFiles requires excessive permission
On Mon, 2005-12-05 at 14:42 +, Gary Benson wrote:
public void write (int oneByte) throws IOException
{
+if (out == null)
+ throw new IOException(Bad file descriptor);
+
out.write(oneByte);
I don't know if this is performance critical code or is used very often,
but this seems to be a special case and i'd suggest something like:
public void write (int oneByte) throws IOException
{
try {
out.write(oneByte);
return;
} catch (NullPointerException e) {
throw new IOException(Bad file descriptor);
}
}
I'll not win a beautiful-code prize, but will be compiled to the fastest
code.
TWISTI
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] Patch: fix Float/DoubleBuffer.compareTo in the presence of NaN
This patch makes sure FloatBuffer and DoubleBuffer objects compare properly when they contain NaN values. I've already checked in Mauve tests cases. Ok to commit? AG 2005-12-06 Anthony Green [EMAIL PROTECTED] * java/nio/DoubleBuffer.java (compareTo): Handle NaN values within the buffer. * java/nio/FloatBuffer.java (compareTo): Ditto. Index: java/nio/FloatBuffer.java === RCS file: /cvsroot/classpath/classpath/java/nio/FloatBuffer.java,v retrieving revision 1.20 diff -u -r1.20 FloatBuffer.java --- java/nio/FloatBuffer.java 2 Jul 2005 20:32:39 - 1.20 +++ java/nio/FloatBuffer.java 6 Dec 2005 11:02:39 - @@ -303,7 +303,11 @@ if (a b) return -1; - + + // Handle the case where a and b are NaN. + if ((a != a) (b != b)) + continue; + return 1; } Index: java/nio/DoubleBuffer.java === RCS file: /cvsroot/classpath/classpath/java/nio/DoubleBuffer.java,v retrieving revision 1.20 diff -u -r1.20 DoubleBuffer.java --- java/nio/DoubleBuffer.java 2 Jul 2005 20:32:39 - 1.20 +++ java/nio/DoubleBuffer.java 6 Dec 2005 11:02:39 - @@ -304,6 +304,10 @@ if (a b) return -1; + // Handle the case where a and b are NaN. + if ((a != a) (b != b)) + continue; + return 1; } ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] FYI: ViewportLayout fix
Hi,
This is a small fix for the ViewportLayout. As it was before, the layout
manager sets the size for the view to it's minimum when the port is
smaller thant the view. This can't be correct. To be honest, I think it
still isn't correct now, I don't have time to investigate more atm and
it seems to work better than before, so I commit this. For the possible
bug I added a comment.
2005-12-06 Roman Kennke [EMAIL PROTECTED]
* javax/swing/ViewportLayout.java
(layoutContainer): Don't set the view to it's minimumSize when
the
port is larger than the view. Rather it should left at it's
preferred size. Also, I added a comment explaining a possible bug
in this method.
Cheers, Roman
Index: javax/swing/ViewportLayout.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/ViewportLayout.java,v
retrieving revision 1.18
diff -u -r1.18 ViewportLayout.java
--- javax/swing/ViewportLayout.java 26 Oct 2005 19:40:26 - 1.18
+++ javax/swing/ViewportLayout.java 6 Dec 2005 14:30:07 -
@@ -153,7 +153,6 @@
}
else
{
-viewPref.height = viewMinimum.height;
int overextension = portLowerRight.y - viewPref.height;
if (overextension 0)
portBounds.y -= overextension;
@@ -168,13 +167,17 @@
}
else
{
-viewPref.width = viewMinimum.width;
int overextension = portLowerRight.x - viewPref.width;
if (overextension 0)
portBounds.x -= overextension;
}
port.setViewPosition(portBounds.getLocation());
+// TODO: I doubt that the size should really be touched here, except when
+// the view is somehow smaller than its minimumSize. I would think that
+// when the size of a view is set manually to a fixed value, that this
+// value should be left unchanged, and not reset to the preferred or
+// minimum size. -- Roman Kennke
port.setViewSize(viewPref);
}
}
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] [generics] RFC: fix generics branch compilation on Darwin
Casey Marshall wrote: This puts the 'environ' declaration/define in jcl.h; I hope this is OK, it looks like the best place for a global thing like this. What you have now results in a duplicate declaration of environ on systems that already declare environ in unistd.h (or wherever), but don't have a crt_externs.h. Not a big deal (the build should still work) but it will cause a GCC warning with -Wredundant-decls. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Patch: Opening RandomAccessFiles requires excessive permission
Christian Thalinger wrote:
I don't know if this is performance critical code or is used very often,
but this seems to be a special case and i'd suggest something like:
public void write (int oneByte) throws IOException
{
try {
out.write(oneByte);
return;
} catch (NullPointerException e) {
throw new IOException(Bad file descriptor);
}
}
I'll not win a beautiful-code prize, but will be compiled to the fastest
code.
That's getting into the micro-optimzation realm, which is
fraught with danger and mistaken assumptions :-) E.g., on
some machines the time overhead of setting up a try/catch in
a method that wouldn't otherwise have one is higher than
the single comparison required to test for null. In particular,
any interpreter is going to have to test for null anyway,
so the second time it's already in cache, blah blah, etc.
Not to mention that the space overhead of a try/catch (vs. none)
will probably be higher too. So IMHO it's better to avoid
too much of this kind of thing (unless it actually makes the
source code clearer (don't think so in this case)).
Apologies for the minor IMHO rant.. :-)
-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] FYI: Container fixlet
Mark pointed out that my fix from
2005-11-17 Roman Kennke [EMAIL PROTECTED]
* java/awt/Container.java
(Container): Added comment.
(remove): Only call removeNotify if removed component is still
showing.
(paintComponents): Call paint() instead of super.paint().
(AccessibleContainerHandler.AccessibleContainerHandler): Added
comment.
(LightweightDispatcher.acquireComponentForMouseEvent):
Don't special case MOUSE_RELEASED events. They should be
dispatched unmodified just as MOUSE_PRESSED.
(LightweightDispatcher.handleEvent): Also clean up the pressCount
after a MOUSE_
was not quite right. We actually should dispatch the MOUSE_RELEASE to the
same component that received the original MOUSE_PRESSED, otherwise
dragging is not working correctly, because the MOUSE_RELEASE will be
dispatched to an arbitrary component, but not the dragged component.
This is fixed by the attached patch:
2005-12-06 Roman Kennke [EMAIL PROTECTED]
PR classpath/25256
* java/awt/Container.java
(LightweightDispatcher.acquireComponentForMouseEvent): When we
receive a MOUSE_RELEASED then dispatch it to the same component
that received the original MOUSE_PRESSED. This is needed for
correct dragging behaviour.
/Roman
Index: java/awt/Container.java
===
RCS file: /cvsroot/classpath/classpath/java/awt/Container.java,v
retrieving revision 1.71
diff -u -r1.71 Container.java
--- java/awt/Container.java 23 Nov 2005 15:16:40 - 1.71
+++ java/awt/Container.java 6 Dec 2005 16:18:51 -
@@ -2157,12 +2157,18 @@
break;
}
-if (me.getID() == MouseEvent.MOUSE_PRESSED modifiers 0
+if (me.getID() == MouseEvent.MOUSE_PRESSED
+ me.getID() == MouseEvent.MOUSE_PRESSED modifiers 0
|| me.getID() == MouseEvent.MOUSE_DRAGGED)
{
// If any of the following events occur while a button is held down,
// they should be dispatched to the same component to which the
// original MOUSE_PRESSED event was dispatched:
+// - MOUSE_RELEASED: This is important for correct dragging
+// behaviour, otherwise the release goes to an arbitrary component
+// outside of the dragged component. OTOH, if there is no mouse
+// drag while the mouse is pressed, the component under the mouse
+// is the same as the previously pressed component anyway.
// - MOUSE_PRESSED: another button pressed while the first is held
// down
// - MOUSE_DRAGGED
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] FYI: JComponent fixlet
I removed an unneeded warning in JComponent. We used to print out this
warning when a component has no UI installed. This probably was useful
in the early days when some components didn't have a UI class yet or
something like that. Today such a warning is completely superfluous and
confuses some users. Also, it actually is completely legal to have a
component without an UI class.
2005-12-06 Roman Kennke [EMAIL PROTECTED]
* javax/swing/JComponent.java
(updateUI): Removed unneeded warning.
/Roman
Index: javax/swing/JComponent.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/JComponent.java,v
retrieving revision 1.90
diff -u -r1.90 JComponent.java
--- javax/swing/JComponent.java 23 Nov 2005 15:39:11 - 1.90
+++ javax/swing/JComponent.java 6 Dec 2005 16:26:14 -
@@ -2740,7 +2740,7 @@
*/
public void updateUI()
{
-System.out.println(update UI not overwritten in class: + this);
+// Nothing to do here.
}
public static Locale getDefaultLocale()
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Patch: fix Float/DoubleBuffer.compareTo in the presence of NaN
Anthony == Anthony Green [EMAIL PROTECTED] writes: Anthony This patch makes sure FloatBuffer and DoubleBuffer objects compare Anthony properly when they contain NaN values. I've already checked in Mauve Anthony tests cases. Ok to commit? Does it do the right thing if a is NaN and b is not? Or vice versa? If so, this is ok. Tom ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Patch: Add security check to Class.getClasses()
Gary == Gary Benson [EMAIL PROTECTED] writes: Gary Class.getClasses() was not performing the member access checks like it Gary ought. The attached patch fixes. I'm working on mauve tests for all Gary of Class's security calls so there will be a check for this issue Gary soonish. Class.getClasses is directly calling memberAccessCheck before it calls internalGetClasses. Also supposedly getClasses should call with Member.PUBLIC, not Member.DECLARED. So it seems to me that this patch is not needed. Tom ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Patch: Opening RandomAccessFiles requires excessive permission
On Tue, 2005-12-06 at 10:00 -0600, Archie Cobbs wrote: That's getting into the micro-optimzation realm, which is fraught with danger and mistaken assumptions :-) E.g., on some machines the time overhead of setting up a try/catch in a method that wouldn't otherwise have one is higher than the single comparison required to test for null. In particular, any interpreter is going to have to test for null anyway, so the second time it's already in cache, blah blah, etc. ...setting up a try/catch...? What do you mean? Agreed on the interpreter thing, but who does benchmarks on interpreters? Not to mention that the space overhead of a try/catch (vs. none) will probably be higher too. So IMHO it's better to avoid too much of this kind of thing (unless it actually makes the source code clearer (don't think so in this case)). Actually the generated code is smaller and i don't think there is too much space overhead in the VM (at least not in CACAO). Yes, the code is not clearer but it's just a 6-liner in a core class... so it should be understandable for everyone :-) Whatever... /me still trying to kick sun's ass TWISTI ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
RE: [cp-patches] RFC: StringIndexOutOfBoundsException fixes inString contructors
On Wed, 2005-11-02 at 12:50 +0100, Jeroen Frijters wrote: Christian Thalinger wrote: +if (offset + count 0 || offset + count ascii.length) You can write this more efficiently as: if (ascii.length - offset count) (This assumes that offset and count have previously been checked to be non-negative.) Hi! Sorry for the long delay, but here it is. I left a comment in there so it's clear what we are checking for. Commited as attached. TWISTI 2005-12-06 Christian Thalinger [EMAIL PROTECTED] * java/lang/String.java (String): Better out-of-bounds and overflow checks. Index: java/lang/String.java === RCS file: /cvsroot/classpath/classpath/java/lang/String.java,v retrieving revision 1.76 diff -u -3 -p -r1.76 String.java --- java/lang/String.java 8 Nov 2005 16:04:49 - 1.76 +++ java/lang/String.java 6 Dec 2005 18:47:30 - @@ -273,7 +273,8 @@ public final class String implements Ser throw new StringIndexOutOfBoundsException(offset: + offset); if (count 0) throw new StringIndexOutOfBoundsException(count: + count); -if (offset + count 0 || offset + count ascii.length) +// equivalent to: offset + count 0 || offset + count ascii.length +if (ascii.length - offset count) throw new StringIndexOutOfBoundsException(offset + count: + (offset + count)); value = new char[count]; @@ -338,7 +339,8 @@ public final class String implements Ser throw new StringIndexOutOfBoundsException(offset: + offset); if (count 0) throw new StringIndexOutOfBoundsException(count: + count); -if (offset + count 0 || offset + count data.length) +// equivalent to: offset + count 0 || offset + count data.length +if (data.length - offset count) throw new StringIndexOutOfBoundsException(offset + count: + (offset + count)); try @@ -418,7 +420,8 @@ public final class String implements Ser throw new StringIndexOutOfBoundsException(offset: + offset); if (count 0) throw new StringIndexOutOfBoundsException(count: + count); -if (offset + count 0 || offset + count data.length) +// equivalent to: offset + count 0 || offset + count data.length +if (data.length - offset count) throw new StringIndexOutOfBoundsException(offset + count: + (offset + count)); int o, c; @@ -533,7 +536,8 @@ public final class String implements Ser throw new StringIndexOutOfBoundsException(offset: + offset); if (count 0) throw new StringIndexOutOfBoundsException(count: + count); -if (offset + count 0 || offset + count data.length) +// equivalent to: offset + count 0 || offset + count data.length +if (data.length - offset count) throw new StringIndexOutOfBoundsException(offset + count: + (offset + count)); if (dont_copy) ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] FYI: Container fixlet
Hi Mark,
Am Dienstag, den 06.12.2005, 18:49 +0100 schrieb Mark Wielaard:
Hi Roman,
On Tue, 2005-12-06 at 16:25 +, Roman Kennke wrote:
2005-12-06 Roman Kennke [EMAIL PROTECTED]
PR classpath/25256
* java/awt/Container.java
(LightweightDispatcher.acquireComponentForMouseEvent): When we
receive a MOUSE_RELEASED then dispatch it to the same component
that received the original MOUSE_PRESSED. This is needed for
correct dragging behaviour.
[...]
@@ -2157,12 +2157,18 @@
break;
}
-if (me.getID() == MouseEvent.MOUSE_PRESSED modifiers 0
+if (me.getID() == MouseEvent.MOUSE_PRESSED
+ me.getID() == MouseEvent.MOUSE_PRESSED modifiers 0
|| me.getID() == MouseEvent.MOUSE_DRAGGED)
{
Shouldn't that first line say MouseEvent.MOUSE_RELEASED now, and
shouldn't the condition be an || ?
if (me.getID() == MouseEvent.MOUSE_RELEASED
|| (me.getID() == MouseEvent.MOUSE_PRESSED modifiers 0)
|| me.getID() == MouseEvent.MOUSE_DRAGGED)
Of course you are right. I really shouldn't send patches at the end of a
long working day...
2005-12-06 Roman Kennke [EMAIL PROTECTED]
PR classpath/25256
* java/awt/Container.java
(LightweightDispatcher.acquireComponentForMouseEvent): Fixed
the MOUSE_RELEASED flag and || conditional.
/Roman
Index: java/awt/Container.java
===
RCS file: /cvsroot/classpath/classpath/java/awt/Container.java,v
retrieving revision 1.72
diff -u -r1.72 Container.java
--- java/awt/Container.java 6 Dec 2005 16:22:25 - 1.72
+++ java/awt/Container.java 6 Dec 2005 19:23:20 -
@@ -2157,8 +2157,8 @@
break;
}
-if (me.getID() == MouseEvent.MOUSE_PRESSED
- me.getID() == MouseEvent.MOUSE_PRESSED modifiers 0
+if (me.getID() == MouseEvent.MOUSE_RELEASED
+|| me.getID() == MouseEvent.MOUSE_PRESSED modifiers 0
|| me.getID() == MouseEvent.MOUSE_DRAGGED)
{
// If any of the following events occur while a button is held down,
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Patch: Opening RandomAccessFiles requires excessive permission
Christian Thalinger wrote: That's getting into the micro-optimzation realm, which is fraught with danger and mistaken assumptions :-) E.g., on some machines the time overhead of setting up a try/catch in a method that wouldn't otherwise have one is higher than the single comparison required to test for null. In particular, any interpreter is going to have to test for null anyway, so the second time it's already in cache, blah blah, etc. ...setting up a try/catch...? What do you mean? Agreed on the Simply that on some VM's there is overhead associated with executing code that can possibly catch an exception, even if no exception is actually thrown. For example, locals might be stored on the stack instead of in registers if the engine doesn't know how to unwind registers. Not to mention that the space overhead of a try/catch (vs. none) will probably be higher too. So IMHO it's better to avoid too much of this kind of thing (unless it actually makes the source code clearer (don't think so in this case)). Actually the generated code is smaller and i don't think there is too much space overhead in the VM (at least not in CACAO). Yes, the code is not clearer but it's just a 6-liner in a core class... so it should be understandable for everyone :-) You say the generated code is smaller but that depends on who generates the code (if you mean the generated Java bytecode, I'd guess you're wrong there too because of the extra exception table required). And that depends on which VM you're using.. which is my only point: it all depends, so you can't assume anything for sure. I didn't really mean to criticize this change so much as the idea of initiating a wild goose chase of similar changes which may or may not actually improve anything. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Patch: Opening RandomAccessFiles requires excessive permission
Christian Thalinger wrote: On Tue, 2005-12-06 at 10:00 -0600, Archie Cobbs wrote: That's getting into the micro-optimzation realm, which is fraught with danger and mistaken assumptions :-) E.g., on some machines the time overhead of setting up a try/catch in a method that wouldn't otherwise have one is higher than the single comparison required to test for null. In particular, any interpreter is going to have to test for null anyway, so the second time it's already in cache, blah blah, etc. ...setting up a try/catch...? What do you mean? Agreed on the interpreter thing, but who does benchmarks on interpreters? On gcj using SJLJ exceptions there is overhead for entering a try block. And for the dwarf unwinder there is overhead in the unwinding tables (but not in the code) for each try/catch. That you don't care about the implications for platforms other than your own, does not imply that they do not exist. David Daney ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Patch: Opening RandomAccessFiles requires excessive permission
On Tue, 2005-12-06 at 13:32 -0600, Archie Cobbs wrote: You say the generated code is smaller but that depends on who generates the code (if you mean the generated Java bytecode, I'd guess you're wrong there too because of the extra exception table required). And that depends on which VM you're using.. which is my only point: it all depends, so you can't assume anything for sure. I didn't really mean to criticize this change so much as the idea of initiating a wild goose chase of similar changes which may or may not actually improve anything. Yeah, i didn't take it personally :-) Of course i see your point, but what i'm trying to say is, if we ever want to catch up (or even be better) than sun or other proprietary JVMs, we should think about optimizing some core functions in classpath... TWISTI ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] Patch: BoxLayout fix
2005-12-06 Anthony Balkissoon [EMAIL PROTECTED] Fixes bug #25233 * javax/swing/BoxLayout.java: (maximumLayoutSize): Don't add the Insets to the Dimension calculated in checkTotalRequirements(). ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] Patch: BoxLayout fix
This patch fixes PR 25233. 2005-12-06 Anthony Balkissoon [EMAIL PROTECTED] Fixes bug #25233 * javax/swing/BoxLayout.java: (maximumLayoutSize): Don't add the Insets to the Dimension calculated in checkTotalRequirements(). --Tony Index: javax/swing/BoxLayout.java === RCS file: /cvsroot/classpath/classpath/javax/swing/BoxLayout.java,v retrieving revision 1.25 diff -u -r1.25 BoxLayout.java --- javax/swing/BoxLayout.java 2 Nov 2005 11:47:57 - 1.25 +++ javax/swing/BoxLayout.java 6 Dec 2005 19:34:56 - @@ -334,9 +334,8 @@ throw new AWTError(BoxLayout can't be shared); checkTotalRequirements(); -Insets i = container.getInsets(); -return new Dimension(xTotal.maximum + i.left + i.right, - yTotal.maximum + i.top + i.bottom); +return new Dimension(xTotal.maximum, + yTotal.maximum); } } ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Patch: Opening RandomAccessFiles requires excessive permission
Christian Thalinger wrote: what i'm trying to say is, if we ever want to catch up (or even be better) than sun or other proprietary JVMs, we should think about optimizing some core functions in classpath... I definitely agree there. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Patch: Opening RandomAccessFiles requires excessive permission
Twisti == Christian Thalinger [EMAIL PROTECTED] writes: Twisti Yeah, i didn't take it personally :-) Of course i see your point, but Twisti what i'm trying to say is, if we ever want to catch up (or even be Twisti better) than sun or other proprietary JVMs, we should think about Twisti optimizing some core functions in classpath... Yeah. This is tricky for us since the various VMs differ. That said, I think we've seen a number of performance fixes go in during the last year, and for the most part these haven't been micro-optimizations. In this particular case, I think RandomAccessFile is not used very much. I would only bother looking at optimizations in this code if it showed up in a profile of some application. Tom ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Patch: BoxLayout fix
I reverted this patch because it caused a Mauve regression. I'll have to write more tests and figure out what was wrong. regression: gnu.testlet.javax.swing.BoxLayout.maximumLayoutSize On Tue, 2005-12-06 at 14:52 -0500, Anthony Balkissoon wrote: This patch fixes PR 25233. 2005-12-06 Anthony Balkissoon [EMAIL PROTECTED] Fixes bug #25233 * javax/swing/BoxLayout.java: (maximumLayoutSize): Don't add the Insets to the Dimension calculated in checkTotalRequirements(). --Tony ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches --Tony ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] FYI: GridBagLayout.ArrangeGrid fix
Hi,
An application I was running exposed a crash in
GridBagLayout.ArrangeGrid. I committed this fix.
Tom
2005-12-06 Thomas Fitzsimmons [EMAIL PROTECTED]
* java/awt/GridBagLayout.java (ArrangeGrid): Use info rather than
layoutInfo in the component for loop. Cache layout information
after resizing components.
Index: java/awt/GridBagLayout.java
===
RCS file: /cvsroot/classpath/classpath/java/awt/GridBagLayout.java,v
retrieving revision 1.22
diff -u -r1.22 GridBagLayout.java
--- java/awt/GridBagLayout.java 18 Oct 2005 20:06:15 - 1.22
+++ java/awt/GridBagLayout.java 6 Dec 2005 21:16:18 -
@@ -341,11 +341,14 @@
GridBagLayoutInfo info = getLayoutInfo (parent, PREFERREDSIZE);
if (info.cols == 0 info.rows == 0)
return;
- layoutInfo = info;
// DEBUG
- //dumpLayoutInfo (layoutInfo);
-
+ //dumpLayoutInfo (info);
+
+ // Calling setBounds on these components causes this layout to
+ // be invalidated, clearing the layout information cache,
+ // layoutInfo. So we wait until after this for loop to set
+ // layoutInfo.
for(int i = 0; i components.length; i++)
{
Component component = components [i];
@@ -357,11 +360,11 @@
GridBagConstraints constraints =
lookupInternalConstraints(component);
- int cellx = sumIntArray(layoutInfo.colWidths, constraints.gridx);
- int celly = sumIntArray(layoutInfo.rowHeights, constraints.gridy);
- int cellw = sumIntArray(layoutInfo.colWidths,
+ int cellx = sumIntArray(info.colWidths, constraints.gridx);
+ int celly = sumIntArray(info.rowHeights, constraints.gridy);
+ int cellw = sumIntArray(info.colWidths,
constraints.gridx + constraints.gridwidth) - cellx;
- int cellh = sumIntArray(layoutInfo.rowHeights,
+ int cellh = sumIntArray(info.rowHeights,
constraints.gridy + constraints.gridheight) - celly;
Insets insets = constraints.insets;
@@ -438,11 +441,14 @@
break;
}
- component.setBounds(layoutInfo.pos_x + x, layoutInfo.pos_y + y, dim.width, dim.height);
+ component.setBounds(info.pos_x + x, info.pos_y + y, dim.width, dim.height);
}
// DEBUG
- //dumpLayoutInfo (layoutInfo);
+ //dumpLayoutInfo (info);
+
+ // Cache layout information.
+ layoutInfo = getLayoutInfo (parent, PREFERREDSIZE);
}
/**
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Patch: BoxLayout fix
On Tue, 2005-12-06 at 15:58 -0500, Anthony Balkissoon wrote: I reverted this patch because it caused a Mauve regression. I'll have to write more tests and figure out what was wrong. regression: gnu.testlet.javax.swing.BoxLayout.maximumLayoutSize Okay, here's the new patch. It doesn't cause the regression and also makes us pass the new test: gnu.testlet.javax.swing.BoxLayout.maximumLayoutSize2 Patch simply involves checking for overflow. 2005-12-06 Anthony Balkissoon [EMAIL PROTECTED] * javax/swing/BoxLayout.java: (maximumLayoutSize): Add Insets to Dimension and then check for overflow. --Tony Index: javax/swing/BoxLayout.java === RCS file: /cvsroot/classpath/classpath/javax/swing/BoxLayout.java,v retrieving revision 1.26 diff -u -r1.26 BoxLayout.java --- javax/swing/BoxLayout.java 6 Dec 2005 19:50:23 - 1.26 +++ javax/swing/BoxLayout.java 6 Dec 2005 21:25:01 - @@ -334,8 +334,16 @@ throw new AWTError(BoxLayout can't be shared); checkTotalRequirements(); -return new Dimension(xTotal.maximum, - yTotal.maximum); +Insets i = container.getInsets(); +int xDim = xTotal.maximum + i.left + i.right; +int yDim = yTotal.maximum + i.top + i.bottom; + +// Check for overflow +if (xDim xTotal.maximum) + xDim = Integer.MAX_VALUE; +if (yDim yTotal.maximum) + yDim = Integer.MAX_VALUE; +return new Dimension(xDim, yDim); } } ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] FYI: Container fixlet
[Sorry for the duplicate message, trouble with my primary email account]
Hi Roman,
On Tue, 2005-12-06 at 16:25 +, Roman Kennke wrote:
2005-12-06 Roman Kennke [EMAIL PROTECTED]
PR classpath/25256
* java/awt/Container.java
(LightweightDispatcher.acquireComponentForMouseEvent): When we
receive a MOUSE_RELEASED then dispatch it to the same component
that received the original MOUSE_PRESSED. This is needed for
correct dragging behaviour.
[...]
@@ -2157,12 +2157,18 @@
break;
}
-if (me.getID() == MouseEvent.MOUSE_PRESSED modifiers 0
+if (me.getID() == MouseEvent.MOUSE_PRESSED
+ me.getID() == MouseEvent.MOUSE_PRESSED modifiers 0
|| me.getID() == MouseEvent.MOUSE_DRAGGED)
{
Shouldn't that first line say MouseEvent.MOUSE_RELEASED now, and
shouldn't the condition be an || ?
if (me.getID() == MouseEvent.MOUSE_RELEASED
|| (me.getID() == MouseEvent.MOUSE_PRESSED modifiers 0)
|| me.getID() == MouseEvent.MOUSE_DRAGGED)
Cheers,
Mark
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] FYI: LookAndFeel.toString() fixlet
Hi,
Riccardo reported a bug off list about code that tried to parse the
LookAndFeel.toString() result to find the actual Class name of the
LookAndFeel subclass. Although this is highly questionable the big Swing
book does indeed that toString() returns a string based on the
description and class name. And we currently returned something very
non-descriptive, so I updated it as follows:
2005-12-06 Mark Wielaard [EMAIL PROTECTED]
* javax/swing/LookAndFeel.java (toString): Include description and
Class name.
Committed,
Mark
diff -u -r1.15 LookAndFeel.java
--- javax/swing/LookAndFeel.java20 Oct 2005 18:58:46 - 1.15
+++ javax/swing/LookAndFeel.java6 Dec 2005 17:26:45 -
@@ -300,11 +300,11 @@
/**
* Returns a string that displays and identifies this object's properties.
*
- * @return the string LookAndFeel
+ * @return string containing the description and class name.
*/
public String toString()
{
-return LookAndFeel;
+return getDescription() + + getClass().getName();
}
/**
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] [generics] Patch: FYI: more genericization
I'm checking this in on the generics branch.
Even more genericization that I somehow missed earlier. I really
suspect japi is just feeding me methods and classes piecemeal somehow
:-)
This one includes some real bug fixes in javax.imageio. An earlier
patch I made to ImageIO was in error, so I more fully genericized this
class in order to catch bugs. I think this is the first batch of
actual bugs caught by genericization -- which is nice but hardly
stellar for a safety feature. Another way to look at it is that we're
really great and hardly make mistakes in this area :-)
The ImageIO fixes should be back-ported to the trunk. I'll try to do
that.
There's a bit more genericization to come, and then of course whatever
japi coughs up in a couple of days.
Tom
2005-12-06 Tom Tromey [EMAIL PROTECTED]
* javax/imageio/ImageIO.java (ImageReaderIterator): Genericized.
Added new constructor.
(ImageWriterIterator): Likewise.
(getReadersByFilter): Genericized.
(getWritersByFilter): Likewise.
(getImageReadersBySuffix): Likewise.
(getImageWriters): Likewise.
(hasNext): Likewise.
* javax/print/attribute/AttributeSetUtilities.java
(verifyAttributeCategory): Genericized.
(verifyAttributeValue): Likewise.
(verifyCategoryForValue): Likewise.
* javax/print/attribute/AttributeSet.java (containsKey): Genericized.
(get): Likewise.
(remove): Likewise.
* javax/print/attribute/Attribute.java (getCategory): Genericized.
* javax/print/attribute/HashAttributeSet.java (HashAttributeSet):
Genericized.
(containsKey): Likewise.
* javax/imageio/spi/ServiceRegistry.java (deregisterAll):
Genericized.
* javax/imageio/spi/IIOServiceProvider.java (onDeregistration):
Genericized.
(onRegistration): Likewise.
* javax/imageio/metadata/IIOMetadataFormatImpl.java (getObjectClass):
Genericized.
(getObjectMaxValue): Likewise.
(getObjectMinValue): Likewise.
* javax/imageio/ImageIO.java (getImageReadersBySuffix): Genericized.
(getImageWriters): Likewise.
Index: javax/imageio/ImageIO.java
===
RCS file: /cvsroot/classpath/classpath/javax/imageio/ImageIO.java,v
retrieving revision 1.4.2.8
diff -u -r1.4.2.8 ImageIO.java
--- javax/imageio/ImageIO.java 1 Dec 2005 15:09:47 - 1.4.2.8
+++ javax/imageio/ImageIO.java 7 Dec 2005 00:46:23 -
@@ -315,27 +315,37 @@
}
}
- private static final class ImageReaderIterator implements Iterator
+ private static final class ImageReaderIterator
+implements IteratorImageReader
{
-Iterator it;
+IteratorImageReaderSpi it;
Object readerExtension;
-public ImageReaderIterator(Iterator it, Object readerExtension)
+public ImageReaderIterator(IteratorImageReaderSpi it,
+ Object readerExtension)
{
this.it = it;
this.readerExtension = readerExtension;
}
+
+public ImageReaderIterator(IteratorImageReaderSpi it)
+{
+ this.it = it;
+}
public boolean hasNext()
{
return it.hasNext();
}
-public Object next()
+public ImageReader next()
{
try
{
- return ((ImageReaderSpi)
it.next()).createReaderInstance(readerExtension);
+ ImageReaderSpi spi = it.next();
+ return (readerExtension == null
+ ? spi.createReaderInstance()
+ : spi.createReaderInstance(readerExtension));
}
catch (IOException e)
{
@@ -349,27 +359,37 @@
}
}
- private static final class ImageWriterIterator implements Iterator
+ private static final class ImageWriterIterator
+implements IteratorImageWriter
{
-Iterator it;
+IteratorImageWriterSpi it;
Object writerExtension;
-public ImageWriterIterator(Iterator it, Object writerExtension)
+public ImageWriterIterator(IteratorImageWriterSpi it,
+ Object writerExtension)
{
this.it = it;
this.writerExtension = writerExtension;
}
+
+public ImageWriterIterator(IteratorImageWriterSpi it)
+{
+ this.it = it;
+}
public boolean hasNext()
{
return it.hasNext();
}
-public Object next()
+public ImageWriter next()
{
try
{
- return ((ImageWriterSpi)
it.next()).createWriterInstance(writerExtension);
+ ImageWriterSpi spi = it.next();
+ return (writerExtension == null
+ ? spi.createWriterInstance()
+ : spi.createWriterInstance(writerExtension));
}
catch (IOException e)
{
@@ -386,13 +406,14 @@
private static File cacheDirectory;
private static boolean useCache = true;
- private static Iterator getReadersByFilter(Class type,
-
[cp-patches] [generics] Patch: FYI: more genericization
I'm checking this in on the generics branch.
This adds generics in to javax.security.auth.Subject.
I think this covers everything in the japi report as of today (with a
minor exception java.util; and it is a bit hard to be 100% sure as
some of the things in the report have been fixed for a few days).
Tom
2005-12-06 Tom Tromey [EMAIL PROTECTED]
* javax/security/auth/Subject.java (Subject): Genericized.
(getPrincipals): Likewise.
(getPrivateCredentials): Likewise.
(getPublicCredentials): Likewise.
(getPublicCredentials): Likewise.
Index: javax/security/auth/Subject.java
===
RCS file: /cvsroot/classpath/classpath/javax/security/auth/Subject.java,v
retrieving revision 1.2.2.5
diff -u -r1.2.2.5 Subject.java
--- javax/security/auth/Subject.java20 Sep 2005 18:46:30 - 1.2.2.5
+++ javax/security/auth/Subject.java7 Dec 2005 01:08:36 -
@@ -91,8 +91,9 @@
readOnly = false;
}
- public Subject (final boolean readOnly, final Set principals,
- final Set pubCred, final Set privCred)
+ public Subject (final boolean readOnly,
+ final Set? extends Principal principals,
+ final Set? pubCred, final Set? privCred)
{
if (principals == null || pubCred == null || privCred == null)
{
@@ -265,12 +266,12 @@
privCred.containsAll (that.getPrivateCredentials());
}
- public Set getPrincipals()
+ public SetPrincipal getPrincipals()
{
return principals;
}
- public Set getPrincipals(Class clazz)
+ public T extends Principal SetT getPrincipals(ClassT clazz)
{
HashSet result = new HashSet (principals.size());
for (Iterator it = principals.iterator(); it.hasNext(); )
@@ -284,12 +285,12 @@
return Collections.unmodifiableSet (result);
}
- public Set getPrivateCredentials()
+ public SetObject getPrivateCredentials()
{
return privCred;
}
- public Set getPrivateCredentials (Class clazz)
+ public T SetT getPrivateCredentials (ClassT clazz)
{
HashSet result = new HashSet (privCred.size());
for (Iterator it = privCred.iterator(); it.hasNext(); )
@@ -303,12 +304,12 @@
return Collections.unmodifiableSet (result);
}
- public Set getPublicCredentials()
+ public SetObject getPublicCredentials()
{
return pubCred;
}
- public Set getPublicCredentials (Class clazz)
+ public T SetT getPublicCredentials (ClassT clazz)
{
HashSet result = new HashSet (pubCred.size());
for (Iterator it = pubCred.iterator(); it.hasNext(); )
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] FYI: LookAndFeel.toString() fixlet
Mark == Mark Wielaard [EMAIL PROTECTED] writes: Mark Riccardo reported a bug off list about code that tried to parse the Mark LookAndFeel.toString() result to find the actual Class name of the Mark LookAndFeel subclass. Although this is highly questionable It would be nice if we had a collection of these oddities that we run across. They could be material for a fun talk. Tom ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Patch: fix Float/DoubleBuffer.compareTo in the presence of NaN
On Tue, 2005-12-06 at 11:12 -0700, Tom Tromey wrote: Anthony == Anthony Green [EMAIL PROTECTED] writes: Anthony This patch makes sure FloatBuffer and DoubleBuffer objects compare Anthony properly when they contain NaN values. I've already checked in Mauve Anthony tests cases. Ok to commit? Does it do the right thing if a is NaN and b is not? Or vice versa? If so, this is ok. Yes, definitely. Although I have what is probably an even simpler patch now. I'll commit the following later tomorrow unless there are objections. Index: java/nio/FloatBuffer.java === RCS file: /cvsroot/classpath/classpath/java/nio/FloatBuffer.java,v retrieving revision 1.20 diff -u -r1.20 FloatBuffer.java --- java/nio/FloatBuffer.java 2 Jul 2005 20:32:39 - 1.20 +++ java/nio/FloatBuffer.java 7 Dec 2005 02:46:34 - @@ -303,8 +303,12 @@ if (a b) return -1; - - return 1; + + if (a b) + return 1; + + // Otherwise a and b must both be NaN and we can continue + // looping. } return remaining() - other.remaining(); (and similarly for DoubleBuffer.java) ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
RFC: merging GNU Crypto and Jessie
A few of us have been throwing around the idea of merging GNU Crypto and Jessie into GNU Classpath, so Classpath will have full support for crypto and SSL out of the box. We've proposed this before, and I think this idea was mostly approved by the group, but no-one ever got around to doing it. I'd like to propose again that we do this. I'll try to get to this myself, but if I can't get this done, we'll at least have a plan of action. I propose that we - Rename the root package 'gnu.crypto' to 'gnu.javax.crypto' in GNU Crypto, and merge the current CVS sources into Classpath (not under external/). We then put GNU Crypto into a kind of stasis mode, and continue to develop these sources in Classpath. - Rename the root package 'org.metastatic.jessie' to 'gnu.javax.net.ssl' in Jessie, and merge the current sources. Then, I'll stop developing that branch on its own. We can then also merge other parts of GNU Crypto to projects where they make sense; its testsuite can go into Mauve (it was written to use (a possibly old version of) Mauve's own test harness classes), and the various tools can go into cp-tools. I think most Classpath hackers think this is a good idea; I'm sending this mail out to the individual project lists to see if there are any objections from users of either package. To be clear, GNU Crypto won't go away, while Jessie will. GNU Crypto MAY continue to be developed, but not by me (and if history is a precedent, then neither by anyone else). If I'm not able to put this patch together, I will answer anyone's questions about how to proceed, if we get a volunteer. Thanks. ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Free Swing runs with JGoodies Forms
Robert Schuster wrote: Thanks to all Swing hackers!!! JGoodies Forms, which contains a layout manager and some glue classes to make it harder to write bad GUIs, works with free Swing! Great! But ... where is the obligatory screenshot? :) cheers, dalibor topic ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: RFC: merging GNU Crypto and Jessie
Casey Marshall wrote: A few of us have been throwing around the idea of merging GNU Crypto and Jessie into GNU Classpath, so Classpath will have full support for crypto and SSL out of the box. We've proposed this before, and I think this idea was mostly approved by the group, but no-one ever got around to doing it. I'd like to propose again that we do this. I'll try to get to this myself, but if I can't get this done, we'll at least have a plan of action. I propose that we - Rename the root package 'gnu.crypto' to 'gnu.javax.crypto' in GNU Crypto, and merge the current CVS sources into Classpath (not under external/). We then put GNU Crypto into a kind of stasis mode, and continue to develop these sources in Classpath. - Rename the root package 'org.metastatic.jessie' to 'gnu.javax.net.ssl' in Jessie, and merge the current sources. Then, I'll stop developing that branch on its own. We can then also merge other parts of GNU Crypto to projects where they make sense; its testsuite can go into Mauve (it was written to use (a possibly old version of) Mauve's own test harness classes), and the various tools can go into cp-tools. I think most Classpath hackers think this is a good idea; I'm sending this mail out to the individual project lists to see if there are any objections from users of either package. To be clear, GNU Crypto won't go away, while Jessie will. GNU Crypto MAY continue to be developed, but not by me (and if history is a precedent, then neither by anyone else). If I'm not able to put this patch together, I will answer anyone's questions about how to proceed, if we get a volunteer. Awesome! I believe fitzsim and me are making simultaneous saltos[1] of joy at different ends of the planet at the moment. :) cheers, dalibor topic [1] figuratively speaking. ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: RFC: merging GNU Crypto and Jessie
On Mon, 2005-12-05 at 23:42 -0800, Casey Marshall wrote: A few of us have been throwing around the idea of merging GNU Crypto and Jessie into GNU Classpath, so Classpath will have full support for crypto and SSL out of the box. We've proposed this before, and I think this idea was mostly approved by the group, but no-one ever got around to doing it. I'd like to propose again that we do this. I'll try to get to this myself, but if I can't get this done, we'll at least have a plan of action. I propose that we That would be really great! Maybe i can help in some way, although i don't have the time to merge it on myself. TWISTI ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Security manager problem
On Tue, 2005-12-06 at 16:14 +, Gary Benson wrote: I'm having security manager problems, with JamVM at least. Various initialisations happen the first time a permission is checked, including java.security.Security's clinit method which reads the provider files $vendor.security and classpath.security. By this time you are most likely running under a security manager, so if that doesn't allow those files to be read then you get SecurityExceptions you weren't expecting. It's been a long time since I've read anything about this kind of stuff, but my understanding is that you simply wrap things like this up in a AccessController.doPrivileged(), since the access control context of the bootstrap or system class loader will permit file I/O. AG ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Security manager problem
Anthony Green wrote: On Tue, 2005-12-06 at 16:14 +, Gary Benson wrote: I'm having security manager problems, with JamVM at least. Various initialisations happen the first time a permission is checked, including java.security.Security's clinit method which reads the provider files $vendor.security and classpath.security. By this time you are most likely running under a security manager, so if that doesn't allow those files to be read then you get SecurityExceptions you weren't expecting. It's been a long time since I've read anything about this kind of stuff, but my understanding is that you simply wrap things like this up in a AccessController.doPrivileged(), since the access control context of the bootstrap or system class loader will permit file I/O. That's interesting, as I was just looking at an some code in an AccessController.doPrivileged() that was doing security checks. Perhaps JamVM's AccessController.doPrivileged() is not in fact doing anything. Cheers, Gary ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Free Swing runs with JGoodies Forms
Great! But ... where is the obligatory screenshot? :) Yes. yes. Here it is: http://page.mi.fu-berlin.de/~rschuste/ffmki-classpath.png (running on JamVM Classpath 0.19+CVS) For reference. The same dialogs on JDK 1.5: http://bitecode.de/wiki/images/2/24/09-2004-launcher2.jpg http://bitecode.de/wiki/images/7/70/09-2004-launcher1.jpg Btw: The dialogs do not work on gij so some very recent changes must have made that possible. cya Robert signature.asc Description: OpenPGP digital signature ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: [GNU Crypto] RFC: merging GNU Crypto and Jessie
On Dec 6, 2005, at 1:14 AM, Raif S. Naffah wrote: On Tuesday 06 December 2005 18:42, Casey Marshall wrote: A few of us have been throwing around the idea of merging GNU Crypto and Jessie into GNU Classpath, so Classpath will have full support for crypto and SSL out of the box. We've proposed this before, and I think this idea was mostly approved by the group, but no-one ever got around to doing it. I'd like to propose again that we do this. I'll try to get to this myself, but if I can't get this done, we'll at least have a plan of action. I propose that we - Rename the root package 'gnu.crypto' to 'gnu.javax.crypto' in GNU Crypto, and merge the current CVS sources into Classpath (not under external/). We then put GNU Crypto into a kind of stasis mode, and continue to develop these sources in Classpath. - Rename the root package 'org.metastatic.jessie' to 'gnu.javax.net.ssl' in Jessie, and merge the current sources. Then, I'll stop developing that branch on its own. does this mean that Classpath's crypto classes will be using the GNU Crypto assembly, cipher, hash, key, mac, mode, pad, prng and sig sub-packages with the jce wrappers? Basically yes. The goal is to merge everything with a JCE wrapper, because that will fill in many algorithms present in proprietary VMs, but currently missing in Classpath. Things without JCE wrappers don't really make sense for Classpath, because they aren't portably accessible. Thanks. ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Security manager problem
Anthony == Anthony Green [EMAIL PROTECTED] writes: Anthony Perhaps. Implementing proper sandbox behaviour is easy to defer. I Anthony think it will take the kind of work you are doing to drive VMs to take Anthony care of details like this. Do we even do it properly in libgcj (being Anthony careful to account for reflection, etc)? I would be surprised. Nope. There is a big 'XXX' in AccessController. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13604 Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Security manager problem
Anthony == Anthony Green [EMAIL PROTECTED] writes: Anthony It's been a long time since I've read anything about this Anthony kind of stuff, but my understanding is that you simply wrap Anthony things like this up in a AccessController.doPrivileged(), Anthony since the access control context of the bootstrap or system Anthony class loader will permit file I/O. Yes. Finding and solving all the instances of this problem in Classpath is, unfortunately, a good part of the required security work. If you dig around a bit you'll find other places where this treatment has already been applied. Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Security manager problem
Hi, On 12/6/05, Gary Benson [EMAIL PROTECTED] wrote: Anthony Green wrote: It's been a long time since I've read anything about this kind of stuff, but my understanding is that you simply wrap things like this up in a AccessController.doPrivileged(), since the access control context of the bootstrap or system class loader will permit file I/O. That's interesting, as I was just looking at an some code in an AccessController.doPrivileged() that was doing security checks. Perhaps JamVM's AccessController.doPrivileged() is not in fact doing anything. What version of JamVM are you using? As far as I'm aware, JamVMs implementation of VMAccessController is complete (it was provided by Casey Marshall, if I remember correctly). I've made some recent changes to the native method that obtains the stack, so it _could_ have broken in 1.4.1. Do you have a testcase? Thanks, Rob. Cheers, Gary ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: memory behavior to expect with gjdoc-0.7.6
[Sorry for the duplicate message, trouble with my primary email account] Hi, On Mon, 2005-12-05 at 18:52 +0100, Mark Wielaard wrote: Thanks. This seems to point out two things: 1) There is a huge allocation (2MB+): GC: Alloc attempt for 2209016 bytes failed. at this point in the code: // REVIEW: Using max instead of average may allocate a very large // buffer. Maybe we should do something more efficient? int remaining = in.remaining (); int n = (int) (remaining * maxBytesPerChar ()); ByteBuffer out = ByteBuffer.allocate (n); I believe that REVIEW note gives us a hint :) It gives us a hint (thanks for review help from Sven on irc) that we are pushing huge Strings through the encoders. In particular gjdoc creates a full String for each XHTMLified/pretty-printed/color-coded/etc source file in HtmlDoclet.java. Although all the rest of the generated pages are streamed to disk the actual source code formating is done in one go: String result = java2xhtml.makeHTML(sourceBuffer.getBuffer(), sourceFile.getName()); Which is then written to disk in one go. For the larger source files this can be pretty big. So a quick workaround for now would be to not include the -linksource flag to gjdoc. If someone wants a nice hacking task then they could look into making java2xhtml take a Reader to read the source from and a HtmlPage to output to instead of creating one huge String. Cheers, Mark ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
[commit-cp] classpath ./ChangeLog javax/swing/ViewportLayou...
CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Roman Kennke [EMAIL PROTECTED]05/12/06 14:31:09 Modified files: . : ChangeLog javax/swing: ViewportLayout.java Log message: 2005-12-06 Roman Kennke [EMAIL PROTECTED] * javax/swing/ViewportLayout.java (layoutContainer): Don't set the view to it's minimumSize when the port is larger than the view. Rather it should left at it's preferred size. Also, I added a comment explaining a possible bug in this method. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.5764tr2=1.5765r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/javax/swing/ViewportLayout.java.diff?tr1=1.18tr2=1.19r1=textr2=text
[commit-cp] classpath ./ChangeLog java/awt/Container.java
CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Roman Kennke [EMAIL PROTECTED]05/12/06 16:22:25 Modified files: . : ChangeLog java/awt : Container.java Log message: 2005-12-06 Roman Kennke [EMAIL PROTECTED] PR classpath/25256 * java/awt/Container.java (LightweightDispatcher.acquireComponentForMouseEvent): When we receive a MOUSE_RELEASED then dispatch it to the same component that received the original MOUSE_PRESSED. This is needed for correct dragging behaviour. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.5765tr2=1.5766r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/awt/Container.java.diff?tr1=1.71tr2=1.72r1=textr2=text
[commit-cp] classpath ./ChangeLog javax/swing/JComponent.java
CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Roman Kennke [EMAIL PROTECTED]05/12/06 16:27:15 Modified files: . : ChangeLog javax/swing: JComponent.java Log message: 2005-12-06 Roman Kennke [EMAIL PROTECTED] * javax/swing/JComponent.java (updateUI): Removed unneeded warning. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.5766tr2=1.5767r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/javax/swing/JComponent.java.diff?tr1=1.90tr2=1.91r1=textr2=text
[commit-cp] classpath ./ChangeLog java/awt/BorderLayout.java
CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Anthony Balkissoon [EMAIL PROTECTED] 05/12/06 16:30:03 Modified files: . : ChangeLog java/awt : BorderLayout.java Log message: 2005-12-06 Anthony Balkissoon [EMAIL PROTECTED] * java/awt/BorderLayout.java: (maximumLayoutSize): Don't calculate anything, just return a new Dimension with Integer.MAX_VALUE for both dimensions. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.5767tr2=1.5768r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/awt/BorderLayout.java.diff?tr1=1.21tr2=1.22r1=textr2=text
[commit-cp] classpath ./ChangeLog java/lang/String.java
CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Christian Thalinger [EMAIL PROTECTED] 05/12/06 18:52:27 Modified files: . : ChangeLog java/lang : String.java Log message: 2005-12-06 Christian Thalinger [EMAIL PROTECTED] * java/lang/String.java (String): Better out-of-bounds and overflow checks. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.5769tr2=1.5770r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/lang/String.java.diff?tr1=1.76tr2=1.77r1=textr2=text
[commit-cp] classpath ./ChangeLog java/awt/Container.java
CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Roman Kennke [EMAIL PROTECTED]05/12/06 19:27:53 Modified files: . : ChangeLog java/awt : Container.java Log message: 2005-12-06 Roman Kennke [EMAIL PROTECTED] PR classpath/25256 * java/awt/Container.java (LightweightDispatcher.acquireComponentForMouseEvent): Fixed the MOUSE_RELEASED flag and || conditional. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.5770tr2=1.5771r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/awt/Container.java.diff?tr1=1.72tr2=1.73r1=textr2=text
[commit-cp] classpath ./ChangeLog javax/swing/BoxLayout.java
CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Anthony Balkissoon [EMAIL PROTECTED] 05/12/06 19:50:24 Modified files: . : ChangeLog javax/swing: BoxLayout.java Log message: 2005-12-06 Anthony Balkissoon [EMAIL PROTECTED] Fixes bug #25233 * javax/swing/BoxLayout.java: (maximumLayoutSize): Don't add the Insets to the Dimension calculated in checkTotalRequirements(). CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.5771tr2=1.5772r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/javax/swing/BoxLayout.java.diff?tr1=1.25tr2=1.26r1=textr2=text
[commit-cp] classpath ./ChangeLog java/awt/GridBagLayout.java
CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Thomas Fitzsimmons [EMAIL PROTECTED] 05/12/06 21:20:18 Modified files: . : ChangeLog java/awt : GridBagLayout.java Log message: 2005-12-06 Thomas Fitzsimmons [EMAIL PROTECTED] * java/awt/GridBagLayout.java (ArrangeGrid): Use info rather than layoutInfo in the component for loop. Cache layout information after resizing components. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.5772tr2=1.5773r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/awt/GridBagLayout.java.diff?tr1=1.22tr2=1.23r1=textr2=text
[commit-cp] classpath ./ChangeLog javax/swing/BoxLayout.java
CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Anthony Balkissoon [EMAIL PROTECTED] 05/12/06 21:26:38 Modified files: . : ChangeLog javax/swing: BoxLayout.java Log message: 2005-12-06 Anthony Balkissoon [EMAIL PROTECTED] * javax/swing/BoxLayout.java: (maximumLayoutSize): Add Insets to Dimension and then check for overflow. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.5773tr2=1.5774r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/javax/swing/BoxLayout.java.diff?tr1=1.26tr2=1.27r1=textr2=text
[commit-cp] classpath javax/imageio/ImageIO.java javax/prin... [generics-branch]
CVSROOT:/cvsroot/classpath Module name:classpath Branch: generics-branch Changes by: Tom Tromey [EMAIL PROTECTED] 05/12/07 00:53:56 Modified files: javax/imageio : ImageIO.java javax/print/attribute: Attribute.java HashAttributeSet.java AttributeSetUtilities.java AttributeSet.java javax/imageio/spi: ServiceRegistry.java IIOServiceProvider.java javax/imageio/metadata: IIOMetadataFormatImpl.java . : ChangeLog Log message: * javax/imageio/ImageIO.java (ImageReaderIterator): Genericized. Added new constructor. (ImageWriterIterator): Likewise. (getReadersByFilter): Genericized. (getWritersByFilter): Likewise. (getImageReadersBySuffix): Likewise. (getImageWriters): Likewise. (hasNext): Likewise. * javax/print/attribute/AttributeSetUtilities.java (verifyAttributeCategory): Genericized. (verifyAttributeValue): Likewise. (verifyCategoryForValue): Likewise. * javax/print/attribute/AttributeSet.java (containsKey): Genericized. (get): Likewise. (remove): Likewise. * javax/print/attribute/Attribute.java (getCategory): Genericized. * javax/print/attribute/HashAttributeSet.java (HashAttributeSet): Genericized. (containsKey): Likewise. * javax/imageio/spi/ServiceRegistry.java (deregisterAll): Genericized. * javax/imageio/spi/IIOServiceProvider.java (onDeregistration): Genericized. (onRegistration): Likewise. * javax/imageio/metadata/IIOMetadataFormatImpl.java (getObjectClass): Genericized. (getObjectMaxValue): Likewise. (getObjectMinValue): Likewise. * javax/imageio/ImageIO.java (getImageReadersBySuffix): Genericized. (getImageWriters): Likewise. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/javax/imageio/ImageIO.java.diff?only_with_tag=generics-branchtr1=1.4.2.8tr2=1.4.2.9r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/javax/print/attribute/Attribute.java.diff?only_with_tag=generics-branchtr1=1.2.2.2tr2=1.2.2.3r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/javax/print/attribute/HashAttributeSet.java.diff?only_with_tag=generics-branchtr1=1.3.2.2tr2=1.3.2.3r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/javax/print/attribute/AttributeSetUtilities.java.diff?only_with_tag=generics-branchtr1=1.2.2.3tr2=1.2.2.4r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/javax/print/attribute/AttributeSet.java.diff?only_with_tag=generics-branchtr1=1.2.2.2tr2=1.2.2.3r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/javax/imageio/spi/ServiceRegistry.java.diff?only_with_tag=generics-branchtr1=1.1.2.5tr2=1.1.2.6r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/javax/imageio/spi/IIOServiceProvider.java.diff?only_with_tag=generics-branchtr1=1.1.2.2tr2=1.1.2.3r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/javax/imageio/metadata/IIOMetadataFormatImpl.java.diff?only_with_tag=generics-branchtr1=1.1.2.4tr2=1.1.2.5r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?only_with_tag=generics-branchtr1=1.2386.2.188tr2=1.2386.2.189r1=textr2=text
[commit-cp] classpath javax/security/auth/Subject.java ./Ch... [generics-branch]
CVSROOT:/cvsroot/classpath Module name:classpath Branch: generics-branch Changes by: Tom Tromey [EMAIL PROTECTED] 05/12/07 01:15:18 Modified files: javax/security/auth: Subject.java . : ChangeLog Log message: * javax/security/auth/Subject.java (Subject): Genericized. (getPrincipals): Likewise. (getPrivateCredentials): Likewise. (getPublicCredentials): Likewise. (getPublicCredentials): Likewise. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/javax/security/auth/Subject.java.diff?only_with_tag=generics-branchtr1=1.2.2.5tr2=1.2.2.6r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?only_with_tag=generics-branchtr1=1.2386.2.189tr2=1.2386.2.190r1=textr2=text
