[cp-patches] RE: Patches to java.util.zip by Christian Schlichtherle
Hi everyone, the changes from int to long are required as to the ZIP file format specification available online from PKZIP Inc. The specification says that all integers are 4 byte unsigned integers. Java's int type is 4 byte signed, thus the type long is required to hold a ZIP file integer. You can find this in other popular Java based ZIP file implementations as well (Apache ant, the JDK, etc.). I have introduced this fix because jazzlib 0.07 definitely breaks on ZIP files larger than 2 GB. With my patches however, jazzlib is compatible to the ZIP 32 spec which can hold up to 4 GB. Furthermore, the constructors I've introduced are provided to allow an application developer to have the choice of choosing an encoding: UTF-8 as with Sun's JDK which is only relevant if you need to exchange ZIP files with JDK created ZIPs or CP437 to exchange ZIP files created by the rest of the world (PKZIP, Winzip, infozip, MS Explorer, etc). In my opinion, the latter is more relevant for real world internationalized applications. Removing all these fixes/enhancements make my submitted patches pretty useless and do not solve important bugs/limitations of jazzlib 0.07. Anyway, as nothing happened on these topics for almost half a year I've moved away and rolled my own. The resulting ZIP package is available at http://truezip.dev.java.net and does much more than just providing classes which are backwards compatible to JDK's java.util.zip package. It provides an additional layer of abstraction so that an application can treat a ZIP file like an ordinary directory using classes which are backwards compatible to JDK's java.io package. Using this you can create for instance an entry nested in two ZIP files by simply writing to a new FileOutputStream(outer.zip/inner.zip/file.txt). With best regards, Christian Schlichtherle --- Schlichtherle IT Services Wittelsbacher Str. 10a 10707 Berlin Mobil: 0173 / 27 12 470 mailto:[EMAIL PROTECTED] http://www.schlichtherle.de -Original Message- From: Mark Wielaard [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 30, 2005 11:45 PM To: John Leuner Cc: classpath-patches@gnu.org; Christian Schlichtherle Subject: Re: Patches to java.util.zip by Christian Schlichtherle Hi (moved to classpath-patches) On Tue, 2005-08-30 at 18:02 +0200, Mark Wielaard wrote: I need to go through the rest of these patches. It would help if they could be rediffed against current CVS head and extra functionality would be moved to a new package. I reviewed the rest but dropped everything that would need new constructors. It would be best to rewrite that part so that it is an extension for another (gnu) package. While reviewing the classes I fixed some other small issues that I saw in the code. I choose to treat all strings explicitly as UTF-8 encoded although CP437 would probably be also a defensible choice. I did not use any of your int - long changes in the method signatures since I was not sure how and where that was actually needed. If there is a change in the zip format could you give a reference to that and explain how the patch changes the values that gets written/read? I committed the following: 2005-08-30 Mark Wielaard [EMAIL PROTECTED] Christian Schlichtherle [EMAIL PROTECTED] * java/util/zip/ZipEntry.java (setTime): Use Calendar.setTimeInMillis(). (getTime): First parse extra bytes. Use Calendar.getTimeInMillis(). (parseExtra): Don't return early to make sure that KNOWN_EXTRA is always set. * java/util/zip/ZipFile.java (readEntries): Parse name and comment as UTF-8 string. (close): Check that raf is not null. * java/util/zip/ZipInputStream.java (getNextEntry): Set name as UTF-8 bytes. * java/util/zip/ZipOutputStream.java (setComment): Set comment as UTF-8 bytes. (putNextEntry): Likewise for name. (finish): Likewise for both. Could you check whether I missed something essential from your original patch? Thanks, Mark smime.p7s Description: S/MIME cryptographic signature ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] FYI: getPropertyPrefix() in UI delegates
I committed this patch to tidy up the getPropertyPrefix() methods in the UI
delegates for the Basic look and feel. Sun's implementation is a little
inconsistent here: all the descendants of BasicButtonUI include the full stop ('.')
with the prefix, while the descendants of BasicMenuItemUI and BasicTextUI don't. I
thought it best to match that inconsistency, since custom look and feels that extend
BasicLookAndFeel will likely rely on it. I have Mauve tests that check the values,
and all pass with this patch. I didn't notice any differences with the Swing demo
before and after this change:
2005-08-31 David Gilbert [EMAIL PROTECTED]
* javax/swing/plaf/basic/BasicButtonUI.java
(getPropertyPrefix): include dot in prefix,
(installDefaults): remove dot which is included in prefix now,
* javax/swing/plaf/basic/BasicCheckBoxMenuItemUI.java
(getPropertyPrefix): return correct prefix,
* javax/swing/plaf/basic/BasicCheckBoxUI.java
(getPropertyPrefix): return correct prefix,
* javax/swing/plaf/basic/BasicMenuItemUI.java
(getPropertyPrefix): return correct prefix,
* javax/swing/plaf/basic/BasicMenuUI.java
(getPropertyPrefix): return correct prefix,
* javax/swing/plaf/basic/BasicRadioButtonMenuItemUI.java
(getPropertyPrefix): return correct prefix,
* javax/swing/plaf/basic/BasicRadioButtonUI.java
(getPropertyPrefix): include dot in prefix,
(getDefaultIcon): removed dot which is part of the prefix,
* javax/swing/plaf/basic/BasicToggleButtonUI.java
(getPropertyPrefix): include dot in prefix,
* javax/swing/plaf/metal/MetalCheckBoxUI.java: now extends
MetalRadioButtonUI,
(getPropertyPrefix): implemented.
Regards,
Dave
Index: javax/swing/plaf/basic/BasicButtonUI.java
===
RCS file:
/cvsroot/classpath/classpath/javax/swing/plaf/basic/BasicButtonUI.java,v
retrieving revision 1.23
diff -u -r1.23 BasicButtonUI.java
--- javax/swing/plaf/basic/BasicButtonUI.java 26 Jul 2005 14:44:07 -
1.23
+++ javax/swing/plaf/basic/BasicButtonUI.java 31 Aug 2005 15:08:10 -
@@ -115,21 +115,21 @@
*/
protected String getPropertyPrefix()
{
-return Button;
+return Button.;
}
protected void installDefaults(AbstractButton b)
{
UIDefaults defaults = UIManager.getLookAndFeelDefaults();
String prefix = getPropertyPrefix();
-focusColor = defaults.getColor(prefix + .focus);
-b.setForeground(defaults.getColor(prefix + .foreground));
-b.setBackground(defaults.getColor(prefix + .background));
-b.setMargin(defaults.getInsets(prefix + .margin));
-b.setBorder(defaults.getBorder(prefix + .border));
-b.setIconTextGap(defaults.getInt(prefix + .textIconGap));
+focusColor = defaults.getColor(prefix + focus);
+b.setForeground(defaults.getColor(prefix + foreground));
+b.setBackground(defaults.getColor(prefix + background));
+b.setMargin(defaults.getInsets(prefix + margin));
+b.setBorder(defaults.getBorder(prefix + border));
+b.setIconTextGap(defaults.getInt(prefix + textIconGap));
b.setInputMap(JComponent.WHEN_FOCUSED,
- (InputMap) defaults.get(prefix + .focusInputMap));
+ (InputMap) defaults.get(prefix + focusInputMap));
b.setOpaque(true);
}
Index: javax/swing/plaf/basic/BasicCheckBoxMenuItemUI.java
===
RCS file:
/cvsroot/classpath/classpath/javax/swing/plaf/basic/BasicCheckBoxMenuItemUI.java,v
retrieving revision 1.8
diff -u -r1.8 BasicCheckBoxMenuItemUI.java
--- javax/swing/plaf/basic/BasicCheckBoxMenuItemUI.java 2 Jul 2005 20:32:50
- 1.8
+++ javax/swing/plaf/basic/BasicCheckBoxMenuItemUI.java 31 Aug 2005 15:08:11
-
@@ -67,13 +67,13 @@
}
/**
- * DOCUMENT ME!
+ * Returns the prefix for entries in the [EMAIL PROTECTED] UIDefaults} table.
*
- * @return $returnType$ DOCUMENT ME!
+ * @return CheckBoxMenuItem
*/
protected String getPropertyPrefix()
{
-return null;
+return CheckBoxMenuItem;
}
/**
Index: javax/swing/plaf/basic/BasicCheckBoxUI.java
===
RCS file:
/cvsroot/classpath/classpath/javax/swing/plaf/basic/BasicCheckBoxUI.java,v
retrieving revision 1.10
diff -u -r1.10 BasicCheckBoxUI.java
--- javax/swing/plaf/basic/BasicCheckBoxUI.java 26 Aug 2005 18:17:57 -
1.10
+++ javax/swing/plaf/basic/BasicCheckBoxUI.java 31 Aug 2005 15:08:11 -
@@ -38,7 +38,6 @@
package javax.swing.plaf.basic;
-import javax.swing.AbstractButton;
import javax.swing.Icon;
import javax.swing.JComponent;
import javax.swing.UIDefaults;
@@ -58,10 +57,14 @@
return defaults.getIcon(CheckBox.icon);
}
- // Overridden to change method access.
+ /**
+ * Returns the prefix for entries in
[cp-patches] Re: [commit-cp] classpath ./ChangeLog java/util/zip/ZipEntry.ja...
Hi David, On Wed, 2005-08-31 at 16:14 +, David Gilbert wrote: Could this have caused the problem I'm now seeing with running the Swing demo: $ jamvm -Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel -classpath examples.zip gnu.classpath.examples.swing.Demo Cannot create system class loader Exception occured while printing exception (java/lang/RuntimeException)... Original exception was java/lang/ExceptionInInitializerError If I unzip the examples.zip archive and run the demo using the .class files, it works OK. This just started happening today. Hmmm, after a clean build and install of both classpath and jamvm I have the same issue. Reverting the patch makes things work again. Embarrassing. Apologies. I am investigating what goes wrong and why I didn't notice this before. BTW. You can run with the -verbose flag to get more information about which classes are being loaded during bootstrap (in this case it showed that it was loading ZipFile just before dying). 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
[cp-patches] Re: [commit-cp] classpath ./ChangeLog java/util/zip/ZipEntry.ja...
Could this have caused the problem I'm now seeing with running the Swing demo: $ jamvm -Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel -classpath examples.zip gnu.classpath.examples.swing.Demo Cannot create system class loader Exception occured while printing exception (java/lang/RuntimeException)... Original exception was java/lang/ExceptionInInitializerError If I unzip the examples.zip archive and run the demo using the .class files, it works OK. This just started happening today. Regards, Dave Mark Wielaard wrote: CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Mark Wielaard [EMAIL PROTECTED] 05/08/30 21:47:44 Modified files: . : ChangeLog java/util/zip : ZipEntry.java ZipFile.java ZipInputStream.java ZipOutputStream.java Log message: 2005-08-30 Mark Wielaard [EMAIL PROTECTED] Christian Schlichtherle [EMAIL PROTECTED] * java/util/zip/ZipEntry.java (setTime): Use Calendar.setTimeInMillis(). (getTime): First parse extra bytes. Use Calendar.getTimeInMillis(). (parseExtra): Don't return early to make sure that KNOWN_EXTRA is always set. * java/util/zip/ZipFile.java (readEntries): Parse name and comment as UTF-8 string. (close): Check that raf is not null. * java/util/zip/ZipInputStream.java (getNextEntry): Set name as UTF-8 bytes. * java/util/zip/ZipOutputStream.java (setComment): Set comment as UTF-8 bytes. (putNextEntry): Likewise for name. (finish): Likewise for both. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.4597tr2=1.4598r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/util/zip/ZipEntry.java.diff?tr1=1.18tr2=1.19r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/util/zip/ZipFile.java.diff?tr1=1.23tr2=1.24r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/util/zip/ZipInputStream.java.diff?tr1=1.15tr2=1.16r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/util/zip/ZipOutputStream.java.diff?tr1=1.10tr2=1.11r1=textr2=text ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Re: [commit-cp] classpath ./ChangeLog java/util/zip/ZipEntry.ja...
Andrew Pinski wrote: On Aug 31, 2005, at 12:14 PM, David Gilbert wrote: Could this have caused the problem I'm now seeing with running the Swing demo: $ jamvm -Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel -classpath examples.zip gnu.classpath.examples.swing.Demo Cannot create system class loader Exception occured while printing exception (java/lang/RuntimeException)... Original exception was java/lang/ExceptionInInitializerError If I unzip the examples.zip archive and run the demo using the .class files, it works OK. This just started happening today. This has been happening to me since I downloaded jamvm and classpath. -- Pinski Thanks for confirming that it is not just me. I can get the demo to run by unzipping examples.zip and typing: [EMAIL PROTECTED] ~/classpath-cvs/classpath/examples $ jamvm -Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel -classpath . gnu.classpath.examples.swing.Demo Regards, Dave ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] Re: [commit-cp] classpath ./ChangeLog java/util/zip/ZipEntry.ja...
On Wed, 2005-08-31 at 17:44 +0200, Mark Wielaard wrote:
Hmmm, after a clean build and install of both classpath and jamvm I have
the same issue. Reverting the patch makes things work again.
Embarrassing. Apologies. I am investigating what goes wrong and why I
didn't notice this before.
It was because I had the following patch in my working directory.
Index: java/nio/charset/Charset.java
===
RCS file: /cvsroot/classpath/classpath/java/nio/charset/Charset.java,v
retrieving revision 1.23
diff -u -r1.23 Charset.java
--- java/nio/charset/Charset.java 2 Jul 2005 20:32:40 - 1.23
+++ java/nio/charset/Charset.java 31 Aug 2005 15:48:02 -
@@ -278,7 +278,7 @@
}
catch (Exception e)
{
-throw new RuntimeException(e);
+return new CharsetProvider[] { provider() };
}
}
return providers;
I'll see if I can come up with a good/real workaround.
The issue is that since we are using the UTF-8 encoder now in zip
reading Charset tries to lookup additional providers during bootstrap
which tries to reopen the zip file we are just reading...
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
[cp-patches] [RFC/docs] Additions and fixes for README and INSTALL
Hi, I updated README and INSTALL. Everyone ok with the changes? 2005-08-31 Robert Schuster [EMAIL PROTECTED] * README: Added MysaifuVM to list of VMs * INSTALL: Added info about Qt4 and ecj. cu Robert Index: README === RCS file: /cvsroot/classpath/classpath/README,v retrieving revision 1.16 diff -u -r1.16 README --- README 9 Jul 2004 15:07:43 - 1.16 +++ README 31 Aug 2005 16:29:50 - @@ -1,4 +1,4 @@ -GNU Classpath README - Last updated: Jul 9, 2004 +GNU Classpath README - Last updated: August 31, 2005 GNU Classpath, Essential Libraries for Java is a project to create a free software implementation of the core class libraries for the java @@ -55,7 +55,8 @@ * IKVM.NET (http://www.ikvm.net/) * JC (http://jcvm.sourceforge.net/) * JNode (http://jnode.sourceforge.net/) - * SableVM (http://www.sablevm.org) + * MysaifuVM (http://www2s.biglobe.ne.jp/~dat/java/project/jvm/) + * SableVM (http://www.sablevm.org) See for a more complete list of GNU Classpath based projects the GNU Classpath website: http://www.gnu.org/software/classpath/stories.html Index: INSTALL === RCS file: /cvsroot/classpath/classpath/INSTALL,v retrieving revision 1.30 diff -u -r1.30 INSTALL --- INSTALL 4 Jul 2005 14:31:00 - 1.30 +++ INSTALL 31 Aug 2005 16:29:50 - @@ -1,4 +1,4 @@ -Installing GNU Classpath - Last updated: January 6, 2005 +Installing GNU Classpath - Last updated: August 31, 2005 First, this is a development release only! Unless you are interested in active development and debugging, or just like running random alpha code, @@ -28,11 +28,12 @@ For building the Java bytecode (.class files), one of these compilers are required. You can select which compiler using - --with-jikes, --with-gcj or --with-kjc as argument to + --with-jikes, --with-gcj, --with-ecj or --with-kjc as argument to configure; the present default is gcj. - GCJ 3.3+ (part of the GNU GCC package). - IBM jikes 1.19+. +- Eclipse Compiler for Java 3.1+ - The kjc compiler is supported with configure but we have been unable to successfully compile with it. @@ -48,7 +49,18 @@ For building the Cairo GdkGraphics2D backend you need at least Cairo 0.5.0. - For building the xmlj JAXP implementation (dsabled by default, use + For building the Qt AWT peer JNI native libraries you need to + specify --enable-qt-peer and need the following library: + +- Qt 4.0.1 + + Please note that at the moment most operating systems do not +ship Qt4 by default. We recommend using GNU Classpath' Qt4 +support only for its developers and bug reporters. See +http://developer.classpath.org/mediation/ClasspathShowcase +for details on how to get it to work. + + For building the xmlj JAXP implementation (disabled by default, use configure --enable-xmlj) you need the following installed: - The XML C library for Gnome (libxml2) http://www.xmlsoft.org/ @@ -74,6 +86,11 @@ --enable-jnicompile JNI source default=yes --enable-gtk-peer compile GTK native peers default=yes --enable-gtk-cairo compile cairo based Graphics2D default=no + --enable-qt-peercompiler Qt4 native peers default=no + --enable-default-toolkit + fully qualified class name of default AWT toolkit + default=no + --enable-xmlj compile native libxml/xslt library default=no --enable-load-library enable to use JNI native methods default=yes --with-jikesto compile the class library using jikes the default is to use gcj @@ -83,7 +100,7 @@ any compiler warning into a compilation failure default=no --enable-xmlj compile native libxml/xslt library default=no - --with-gjdoc generate documentation using gjdoc default=no + --with-gjdoc generate documentation using gjdoc default=no --with-jay Regenerate the parsers with jay must be given the path to the jay executable ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] FYI: MetalBorders
I committed this patch which implements the getTextFieldBorder() method in the
MetalBorders class:
2005-08-31 David Gilbert [EMAIL PROTECTED]
* javax/swing/plaf/metal/MetalBorders.java
(textFieldBorder): new field,
(Flush3DBorder): new class,
(TextFieldBorder): new class,
(getTextFieldBorder): implemented.
Regards,
Dave
Index: javax/swing/plaf/metal/MetalBorders.java
===
RCS file:
/cvsroot/classpath/classpath/javax/swing/plaf/metal/MetalBorders.java,v
retrieving revision 1.10
diff -u -r1.10 MetalBorders.java
--- javax/swing/plaf/metal/MetalBorders.java24 Aug 2005 08:15:26 -
1.10
+++ javax/swing/plaf/metal/MetalBorders.java31 Aug 2005 16:42:46 -
@@ -49,12 +49,14 @@
import javax.swing.JMenu;
import javax.swing.JMenuBar;
import javax.swing.JMenuItem;
+import javax.swing.JTextField;
import javax.swing.border.AbstractBorder;
import javax.swing.border.Border;
import javax.swing.plaf.BorderUIResource;
import javax.swing.plaf.UIResource;
import javax.swing.plaf.basic.BasicBorders;
+
/**
* This factory class creates borders for the different Swing components
* UI.
@@ -70,6 +72,9 @@
/** The shared instance for getRolloverButtonBorder(). */
private static Border toolbarButtonBorder;
+ /** The shared instance for getTextFieldBorder(). */
+ private static Border textFieldBorder;
+
/**
* A MarginBorder that gets shared by multiple components.
* Created on demand by the private helper function [EMAIL PROTECTED]
@@ -186,6 +191,116 @@
}
/**
+ * A simple 3D border.
+ */
+ public static class Flush3DBorder extends AbstractBorder
+implements UIResource
+ {
+/**
+ * Creates a new border instance.
+ */
+public Flush3DBorder()
+{
+}
+
+/**
+ * Returns the border insets.
+ *
+ * @param c the component (ignored).
+ *
+ * @return The border insets.
+ */
+public Insets getBorderInsets(Component c)
+{
+ return getBorderInsets(c, null);
+}
+
+/**
+ * Returns the border insets.
+ *
+ * @param c the component (ignored).
+ * @return The border insets.
+ */
+public Insets getBorderInsets(Component c, Insets newInsets)
+{
+ if (newInsets == null)
+newInsets = new Insets(2, 2, 2, 2);
+ else
+{
+ newInsets.top = 2;
+ newInsets.left = 2;
+ newInsets.bottom = 2;
+ newInsets.right = 2;
+}
+ return newInsets;
+}
+
+/**
+ * Paints the border for the specified component.
+ *
+ * @param c the component (ignored).
+ * @param g the graphics device.
+ * @param x the x-coordinate.
+ * @param y the y-coordinate.
+ * @param w the width.
+ * @param h the height.
+ */
+public void paintBorder(Component c, Graphics g, int x, int y, int w,
+int h)
+{
+ Color savedColor = g.getColor();
+ g.setColor(MetalLookAndFeel.getControlDarkShadow());
+ g.drawRect(x, y, w - 2, h - 2);
+ g.setColor(MetalLookAndFeel.getControlHighlight());
+ g.drawRect(x + 1, y + 1, w - 2, h - 2);
+ g.setColor(MetalLookAndFeel.getControl());
+ g.drawLine(x + 1, y + h - 2, x + 1, y + h - 2);
+ g.drawLine(x + w - 2, y + 1, x + w - 2, y + 1);
+ g.setColor(savedColor);
+}
+
+ }
+
+ /**
+ * A border used for the [EMAIL PROTECTED] JTextField} component.
+ */
+ public static class TextFieldBorder extends Flush3DBorder
+implements UIResource
+ {
+/**
+ * Creates a new border instance.
+ */
+public TextFieldBorder()
+{
+}
+
+/**
+ * Paints the border for the specified component.
+ *
+ * @param c the component (ignored).
+ * @param g the graphics device.
+ * @param x the x-coordinate.
+ * @param y the y-coordinate.
+ * @param w the width.
+ * @param h the height.
+ */
+public void paintBorder(Component c, Graphics g, int x, int y, int w,
+int h)
+{
+ if (c.isEnabled())
+super.paintBorder(c, g, x, y, w, h);
+ else
+{
+ Color savedColor = g.getColor();
+ g.setColor(MetalLookAndFeel.getControlShadow());
+ g.drawRect(x, y, w - 1, h - 1);
+ g.setColor(savedColor);
+}
+}
+
+ }
+
+ /**
* A border used when painting [EMAIL PROTECTED] JInternalFrame} instances.
*/
public static class InternalFrameBorder extends AbstractBorder
@@ -669,6 +784,20 @@
(outer, inner);
}
return buttonBorder;
+ }
+
+ /**
+ * Returns a border for use by the [EMAIL PROTECTED] JTextField} component.
+ *
+ * @return A border.
+ *
+ * @since 1.3
+ */
+ public static Border getTextFieldBorder()
+ {
+if (textFieldBorder == null)
+ textFieldBorder = new TextFieldBorder();
+
Re: [cp-patches] FYI: MetalIconFactory.getRadioButtonMenuItemIcon()
On Tue, 2005-08-30 at 21:35 +, David Gilbert wrote:
I committed this patch to add an icon for JRadioButtonMenuItems under the
Metal look
and feel:
+public int getIconWidth()
+{
+ return 10;
+}
I notice there are an awful lot of constant integers in the plaf code.
My reflex is to say that these ought to be given a name somewhere,
so that we can more easily change them later if need be -- particularly
if we know that, say, many of the 2s are actually METAL_BORDER_WIDTH
or the like, if you catch my meaning. What do you think?
Tom
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] Patch for PR swing/23204 BasicTableUI
This patch implements the getMinimumSize and getMaximumSize methods in
BasicTableUI, essentially fixing bug PR swing/23204 where table columns
weren't being automatically resized. I have not yet closed this bug
because changes need to be made (most likely in ViewportLayout) to allow
JTable.setAutoResizeMode(JTable.AUTO_RESIZE_OFF) to disable column
autoresizing. Once this is done I will consider this bug fixed and
close it.
The patch is attached.
2005-08-31 Anthony Balkissoon [EMAIL PROTECTED]
* javax/swing/JTable.java:
(initializeLocalVars): Changed default autoResizeMode to
AUTO_RESIZE_SUBSEQUENT_COLUMNS to match the JDK.
* javax/swing/plaf/basic/BasicTableUI.java:
(getMaximumSize): Implemented.
(getMinimumSize): Implemented.
--Tony
Index: javax/swing/JTable.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/JTable.java,v
retrieving revision 1.43
diff -u -r1.43 JTable.java
--- javax/swing/JTable.java 12 Aug 2005 20:45:17 - 1.43
+++ javax/swing/JTable.java 31 Aug 2005 18:52:08 -
@@ -673,7 +673,7 @@
this.defaultEditorsByColumnClass = new Hashtable();
createDefaultEditors();
-this.autoResizeMode = AUTO_RESIZE_ALL_COLUMNS;
+this.autoResizeMode = AUTO_RESIZE_SUBSEQUENT_COLUMNS;
this.rowHeight = 16;
this.rowMargin = 1;
this.rowSelectionAllowed = true;
Index: javax/swing/plaf/basic/BasicTableUI.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/plaf/basic/BasicTableUI.java,v
retrieving revision 1.24
diff -u -r1.24 BasicTableUI.java
--- javax/swing/plaf/basic/BasicTableUI.java 16 Aug 2005 18:07:50 - 1.24
+++ javax/swing/plaf/basic/BasicTableUI.java 31 Aug 2005 18:52:08 -
@@ -206,14 +206,44 @@
return new MouseInputHandler();
}
+ /**
+ * Return the maximum size of the table. The maximum height is the row
+* height times the number of rows. The maximum width is the sum of
+* the maximum widths of each column.
+*
+* @param comp the component whose maximum size is being queried,
+* this is ignored.
+* @return a Dimension object representing the maximum size of the table,
+* or null if the table has no elements.
+ */
public Dimension getMaximumSize(JComponent comp)
{
-return getPreferredSize(comp);
+int maxTotalColumnWidth = 0;
+for (int i = 0; i table.getColumnCount(); i++)
+ maxTotalColumnWidth += table.getColumnModel().getColumn(i).getMaxWidth();
+if (maxTotalColumnWidth == 0 || table.getRowCount() == 0)
+ return null;
+return new Dimension(maxTotalColumnWidth, table.getRowCount()*table.getRowHeight());
}
+ /**
+ * Return the minimum size of the table. The minimum height is the row
+* height times the number of rows. The minimum width is the sum of
+* the minimum widths of each column.
+*
+* @param comp the component whose minimum size is being queried,
+* this is ignored.
+* @return a Dimension object representing the minimum size of the table,
+* or null if the table has no elements.
+ */
public Dimension getMinimumSize(JComponent comp)
{
-return getPreferredSize(comp);
+int minTotalColumnWidth = 0;
+for (int i = 0; i table.getColumnCount(); i++)
+ minTotalColumnWidth += table.getColumnModel().getColumn(i).getMinWidth();
+if (minTotalColumnWidth == 0 || table.getRowCount() == 0)
+ return null;
+return new Dimension(minTotalColumnWidth, table.getRowCount()*table.getRowHeight());
}
public Dimension getPreferredSize(JComponent comp)
@@ -355,7 +385,7 @@
{
ListSelectionModel rowModel = table.getSelectionModel();
ListSelectionModel colModel = table.getColumnModel().getSelectionModel();
-
+
int rowLead = rowModel.getLeadSelectionIndex();
int rowMax = table.getModel().getRowCount() - 1;
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] Patch for PR swing/23037 FileChooser.java
This patch fixes PR swing/23037 where the directory up button in
JFileChoosers wasn't stopping at the top of the directory structure, but
rather bouncing back to the user's home directory.
Patch attached.
2005-08-31 Anthony Balkissoon [EMAIL PROTECTED]
PR swing/23037
* javax/swing/JFileChooser.java
(changeToParentDirectory): If parent directory is null, do nothing.
--Tony
Index: javax/swing/JFileChooser.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/JFileChooser.java,v
retrieving revision 1.13
diff -u -r1.13 JFileChooser.java
--- javax/swing/JFileChooser.java 11 Jul 2005 19:57:23 - 1.13
+++ javax/swing/JFileChooser.java 31 Aug 2005 19:16:42 -
@@ -415,7 +415,8 @@
*/
public void changeToParentDirectory()
{
-setCurrentDirectory(fsv.getParentDirectory(currentDir));
+if (fsv.getParentDirectory(currentDir) != null)
+ setCurrentDirectory(fsv.getParentDirectory(currentDir));
}
/**
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] FYI: MetalIconFactory.getRadioButtonMenuItemIcon()
Tom Tromey wrote:
On Tue, 2005-08-30 at 21:35 +, David Gilbert wrote:
I committed this patch to add an icon for JRadioButtonMenuItems under the Metal look
and feel:
+public int getIconWidth()
+{
+ return 10;
+}
I notice there are an awful lot of constant integers in the plaf code.
My reflex is to say that these ought to be given a name somewhere,
so that we can more easily change them later if need be -- particularly
if we know that, say, many of the 2s are actually METAL_BORDER_WIDTH
or the like, if you catch my meaning. What do you think?
Tom
I'll keep a look out for anything that might need a named constant. The
particular example you mentioned shouldn't cause a problem, because this
is the value that matches Sun's JDK and it is covered with a Mauve test
(not sure if I checked in all my icon dimension tests yet, but I will).
The value will never change (it is a 10x10 icon, forever).
But as I start to dig deeper into the look and feel code, I'm sure there
will be some magic values for which your comment is spot on. Very
likely in the layout code which I haven't dug into very far yet.
The icon drawing code is another area where there are lots of constants,
for example:
g.drawLine(x + 2, y, x + 6, y);
g.drawLine(x + 7, y + 1, x + 7, y + 1);
g.drawLine(x + 8, y + 2, x + 8, y + 6);
g.drawLine(x + 7, y + 7, x + 7, y + 7);
g.drawLine(x + 2, y + 8, x + 6, y + 8);
g.drawLine(x + 1, y + 7, x + 1, y + 7);
g.drawLine(x, y + 2, x, y + 6);
g.drawLine(x + 1, y + 1, x + 1, y + 1);
Icons get *drawn* this way in the MetalLookAndFeel, rather than
displaying a PNG image for example, so that the icon can change
appearance when (a) the component state changes and (b) the Metal theme
(primarily colors) is changed (less common). There are no state changes
in the fragment above, but take a look through MetalIconFactory.java if
you are interested. The constants are just offsets from the top-left
corner of the icon, and won't change as long as we are replicating the
icons from the Metal look and feel.
Regards,
Dave
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] Patch for PR swing/23036 BasicFileChooserUI
This patch fixes PR swing/23036 where the look-in box for JFileChoosers
wasn't displaying the correct parent directories.
Patch is attached.
2005-08-31 Anthony Balkissoon [EMAIL PROTECTED]
* javax/swing/plaf/basic/BasicFileChooserUI.java:
(boxEntries): Made this method package private because I added a
call to it from an implicitly defined listener class. Also fixed
indentation.
(createPropertyChangeListener): If the returned property listener
hears DIRECTORY_CHANGED_PROPERTY, call boxEntries() to update the
look-in box entries.
--Tony
Index: javax/swing/plaf/basic/BasicFileChooserUI.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/plaf/basic/BasicFileChooserUI.java,v
retrieving revision 1.7
diff -u -r1.7 BasicFileChooserUI.java
--- javax/swing/plaf/basic/BasicFileChooserUI.java 13 Jul 2005 23:22:31 - 1.7
+++ javax/swing/plaf/basic/BasicFileChooserUI.java 31 Aug 2005 19:59:22 -
@@ -1090,1 +1090,1 @@
}
// FIXME: Indent the entries in the combobox
- private void boxEntries()
+ // Made this method package private to access it from within inner classes
+ // with better performance
+ void boxEntries()
{
ArrayList parentFiles = new ArrayList();
File parent = filechooser.getCurrentDirectory();
@@ -1098,6 +1100,6 @@
parent = filechooser.getFileSystemView().getDefaultDirectory();
while (parent != null)
{
- String name = parent.getName();
- if (name.equals())
- name = parent.getAbsolutePath();
+String name = parent.getName();
+if (name.equals())
+ name = parent.getAbsolutePath();
- parentFiles.add(parentFiles.size(), name);
- parent = parent.getParentFile();
+parentFiles.add(parentFiles.size(), name);
+parent = parent.getParentFile();
}
if (parentFiles.size() == 0)
@@ -1509,12 +1511,12 @@
}
else if (e.getPropertyName().equals(JFileChooser.DIRECTORY_CHANGED_PROPERTY))
{
- //boxEntries();
filelist.clearSelection();
filelist.revalidate();
filelist.repaint();
setDirectorySelected(false);
setDirectory(filechooser.getCurrentDirectory());
+ boxEntries();
}
else if (e.getPropertyName().equals(JFileChooser.CHOOSABLE_FILE_FILTER_CHANGED_PROPERTY)
|| e.getPropertyName().equals(JFileChooser.FILE_FILTER_CHANGED_PROPERTY))
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] fix heavyweight placement within lightweight container
Hi,
This patch fixes the placement of heavyweight components in lightweight
containers. I have an app that adds a Canvas to a JFrame; the canvas
was being drawn with the wrong offsets relative to the frame. I've
committed this patch, which fixes the canvas's placement.
Tom
2005-08-31 Thomas Fitzsimmons [EMAIL PROTECTED]
* gnu/java/awt/peer/gtk/GtkComponentPeer.java (setBounds): Only
add parent's x and y co-ordinates to translation if parent's
parent is not a window.
Index: gnu/java/awt/peer/gtk/GtkComponentPeer.java
===
RCS file: /cvsroot/classpath/classpath/gnu/java/awt/peer/gtk/GtkComponentPeer.java,v
retrieving revision 1.95
diff -u -r1.95 GtkComponentPeer.java
--- gnu/java/awt/peer/gtk/GtkComponentPeer.java 25 Aug 2005 02:26:48 - 1.95
+++ gnu/java/awt/peer/gtk/GtkComponentPeer.java 31 Aug 2005 21:13:40 -
@@ -424,6 +424,7 @@
int new_y = y;
Component parent = awtComponent.getParent ();
+Component next_parent;
// Heavyweight components that are children of one or more
// lightweight containers have to be handled specially. Because
@@ -441,12 +442,22 @@
{
lightweightChild = true;
+next_parent = parent.getParent ();
+
i = ((Container) parent).getInsets ();
- new_x += parent.getX () + i.left;
- new_y += parent.getY () + i.top;
+if (next_parent instanceof Window)
+ {
+new_x += i.left;
+new_y += i.top;
+ }
+else
+ {
+new_x += parent.getX () + i.left;
+new_y += parent.getY () + i.top;
+ }
- parent = parent.getParent ();
+ parent = next_parent;
}
// We only need to convert from Java to GTK coordinates if we're
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] [RFC/docs] Additions and fixes for README and INSTALL
Hi Robert, On Wed, 2005-08-31 at 18:57 +0200, Robert Schuster wrote: I updated README and INSTALL. Everyone ok with the changes? 2005-08-31 Robert Schuster [EMAIL PROTECTED] * README: Added MysaifuVM to list of VMs * INSTALL: Added info about Qt4 and ecj. Thanks for keeping these documents up to date. Please commit this. 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: Patches to java.util.zip by Christian Schlichtherle
Hi everyone, the changes from int to long are required as to the ZIP file format specification available online from PKZIP Inc. The specification says that all integers are 4 byte unsigned integers. Java's int type is 4 byte signed, thus the type long is required to hold a ZIP file integer. You can find this in other popular Java based ZIP file implementations as well (Apache ant, the JDK, etc.). I have introduced this fix because jazzlib 0.07 definitely breaks on ZIP files larger than 2 GB. With my patches however, jazzlib is compatible to the ZIP 32 spec which can hold up to 4 GB. Furthermore, the constructors I've introduced are provided to allow an application developer to have the choice of choosing an encoding: UTF-8 as with Sun's JDK which is only relevant if you need to exchange ZIP files with JDK created ZIPs or CP437 to exchange ZIP files created by the rest of the world (PKZIP, Winzip, infozip, MS Explorer, etc). In my opinion, the latter is more relevant for real world internationalized applications. Removing all these fixes/enhancements make my submitted patches pretty useless and do not solve important bugs/limitations of jazzlib 0.07. Anyway, as nothing happened on these topics for almost half a year I've moved away and rolled my own. The resulting ZIP package is available at http://truezip.dev.java.net and does much more than just providing classes which are backwards compatible to JDK's java.util.zip package. It provides an additional layer of abstraction so that an application can treat a ZIP file like an ordinary directory using classes which are backwards compatible to JDK's java.io package. Using this you can create for instance an entry nested in two ZIP files by simply writing to a new FileOutputStream(outer.zip/inner.zip/file.txt). With best regards, Christian Schlichtherle --- Schlichtherle IT Services Wittelsbacher Str. 10a 10707 Berlin Mobil: 0173 / 27 12 470 mailto:[EMAIL PROTECTED] http://www.schlichtherle.de -Original Message- From: Mark Wielaard [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 30, 2005 11:45 PM To: John Leuner Cc: classpath-patches@gnu.org; Christian Schlichtherle Subject: Re: Patches to java.util.zip by Christian Schlichtherle Hi (moved to classpath-patches) On Tue, 2005-08-30 at 18:02 +0200, Mark Wielaard wrote: I need to go through the rest of these patches. It would help if they could be rediffed against current CVS head and extra functionality would be moved to a new package. I reviewed the rest but dropped everything that would need new constructors. It would be best to rewrite that part so that it is an extension for another (gnu) package. While reviewing the classes I fixed some other small issues that I saw in the code. I choose to treat all strings explicitly as UTF-8 encoded although CP437 would probably be also a defensible choice. I did not use any of your int - long changes in the method signatures since I was not sure how and where that was actually needed. If there is a change in the zip format could you give a reference to that and explain how the patch changes the values that gets written/read? I committed the following: 2005-08-30 Mark Wielaard [EMAIL PROTECTED] Christian Schlichtherle [EMAIL PROTECTED] * java/util/zip/ZipEntry.java (setTime): Use Calendar.setTimeInMillis(). (getTime): First parse extra bytes. Use Calendar.getTimeInMillis(). (parseExtra): Don't return early to make sure that KNOWN_EXTRA is always set. * java/util/zip/ZipFile.java (readEntries): Parse name and comment as UTF-8 string. (close): Check that raf is not null. * java/util/zip/ZipInputStream.java (getNextEntry): Set name as UTF-8 bytes. * java/util/zip/ZipOutputStream.java (setComment): Set comment as UTF-8 bytes. (putNextEntry): Likewise for name. (finish): Likewise for both. Could you check whether I missed something essential from your original patch? Thanks, Mark smime.p7s Description: S/MIME cryptographic signature ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RE: Patches to java.util.zip by Christian Schlichtherle
Christian Schlichtherle wrote: the changes from int to long are required as to the ZIP file format specification available online from PKZIP Inc. The specification says that all integers are 4 byte unsigned integers. Java's int type is 4 byte signed, thus the type long is required to hold a ZIP file integer. You can find this in other popular Java based ZIP file implementations as well (Apache ant, the JDK, etc.). Thanks for taking the time to explain this. We obviously should take in these fixes. Furthermore, the constructors I've introduced are provided to allow an application developer to have the choice of choosing an encoding: UTF-8 as with Sun's JDK which is only relevant if you need to exchange ZIP files with JDK created ZIPs or CP437 to exchange ZIP files created by the rest of the world (PKZIP, Winzip, infozip, MS Explorer, etc). In my opinion, the latter is more relevant for real world internationalized applications. Unfortunately, we cannot add additional public constructors, but I would suggest adding a system property to control the encoding used by our zip implementation. By default we should be compatible with the JDK, but this would allow applications and/or users to override the encoding to be compatible with the rest of the world. Thanks again. Regards, Jeroen ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RE: Patches to java.util.zip by Christian Schlichtherle
Hi, On Wed, 2005-08-31 at 12:06 +0200, Jeroen Frijters wrote: Christian Schlichtherle wrote: the changes from int to long are required as to the ZIP file format specification available online from PKZIP Inc. The specification says that all integers are 4 byte unsigned integers. Java's int type is 4 byte signed, thus the type long is required to hold a ZIP file integer. You can find this in other popular Java based ZIP file implementations as well (Apache ant, the JDK, etc.). Thanks for taking the time to explain this. We obviously should take in these fixes. Yes, if someone can make a little testcase where we fail now and show how we are not properly converting the signed/unsigned ints at the moment that would be appreciated. Note that at the moment all public methods take and return longs already, we only store it as int internally and try treat it as unsigned already. It might be that we need to internally store everything in an long and not just treat the signed ints as unsigned ints as we do now in the code, but the patch contained so many unrelated changes that it was hard to make out which changes were explicitly for this issue. So if someone could extract those parts of the patch that would help a lot. Thanks, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RE: Patches to java.util.zip by Christian Schlichtherle
Christian Schlichtherle wrote: Unfortunately, we cannot add additional public constructors, but I would suggest adding a system property to control the encoding used by our zip implementation. By default we should be compatible with the JDK, but this would allow applications and/or users to override the encoding to be compatible with the rest of the world. this would be an all-or-nothing-approach, i.e. you could have CP437 for either all ZIP* objects or none. The constructors however allow you to define this on a case by case basis, e.g. using CP437 for any file ending with a .zip suffix and UTF-8 for any file ending with a .jar suffix, which is the most reasonable general approach to deal with the encoding issue in my personal opinion (which is arguable however). Personally, I'm almost always in favor of compatibility with the JDK and in this case there is no doubt in my mind that we should use UTF-8 by default. I recognize that the system property is only a hack that solves a limited number of scenarios, but it's better than nothing. For my personal education: What's wrong about adding constructors? It is a violation of the Sun license included with the API specification -- you could argue about whether the license is valid or not, but that's not the point, and it would preclude us (or any JVM based on GNU Classpath) from ever passing the TCK. Regards, Jeroen ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RE: Patches to java.util.zip by Christian Schlichtherle
Hi everyone, Unfortunately, we cannot add additional public constructors, but I would suggest adding a system property to control the encoding used by our zip implementation. By default we should be compatible with the JDK, but this would allow applications and/or users to override the encoding to be compatible with the rest of the world. this would be an all-or-nothing-approach, i.e. you could have CP437 for either all ZIP* objects or none. The constructors however allow you to define this on a case by case basis, e.g. using CP437 for any file ending with a .zip suffix and UTF-8 for any file ending with a .jar suffix, which is the most reasonable general approach to deal with the encoding issue in my personal opinion (which is arguable however). For my personal education: What's wrong about adding constructors? The result would still be backward compatible to the JDK source, so I think this would make up a good solution. This is also what people have often requested from Sun if you look at the bug tracker thread on this topic. With best regards, Christian smime.p7s Description: S/MIME cryptographic signature ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RE: Patches to java.util.zip by Christian Schlichtherle
Hi everyone,
Yes, if someone can make a little testcase where we fail now
and show how we are not properly converting the
signed/unsigned ints at the moment that would be appreciated.
Note that at the moment all public methods take and return
longs already, we only store it as int internally and try
treat it as unsigned already. It might be that we need to
internally store everything in an long and not just treat the
signed ints as unsigned ints as we do now in the code, but
the patch contained so many unrelated changes that it was
hard to make out which changes were explicitly for this
issue. So if someone could extract those parts of the patch
that would help a lot.
More specifically, the size and compressed size field in the ZipEntry class
are causing the problems as some comparisons are happening on these. The
issue is that once a big integer equal or greater than 2*1024^3 and smaller
than 4*1024^3 is stored into a Java int, it is hard to use this int as if it
were unsigned. You would have to do something like this on an int
(untested):
final static long NUM_FOUR_BYTE_INTS = 256L * 256L * 256L * 256L; // Number
of 4 byte ints
private static long int2long(int i) {
return i = 0 ? (long)i : (long)NUM_FOUR_BYTE_INTS - (long)i;
}
private static void doIt() {
int ok = 2 * 1024 * 1024 * 1024 - 1; // max signed int
int tooBig = 3 * 1024 * 1024 * 1024; // Creates a negative integer
// Compare ok and tooBig
assert int2long(ok) int2long(tooBig) : This is ok!;
assert ok tooBig : This fails!;
}
This is way too much computational overhead and it is way too easy to forget
this on a comparison. Thus, the better way to deal with this issue is hold 4
byte signed ints in a Java long if you don't need to care for the memory
overhead.
With best regards,
Christian
smime.p7s
Description: S/MIME cryptographic signature
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
[Bug classpath/23652] New: scripts/check_jni_methods.sh is not portable
It appears that scripts/check_jni_methods.sh requires at least GNU diff and GNU grep to run properly: cd /home/eric/cvs/gcc/libjava/classpath scripts/check_jni_methods.sh diff: illegal option -- 0 usage: diff [-bitw] [-c | -e | -f | -h | -n | -u] file1 file2 diff [-bitw] [-C number | -U number] file1 file2 diff [-bitw] [-D string] file1 file2 diff [-bitw] [-c | -e | -f | -h | -n | -u] [-l] [-r] [-s] [-S name] directory1 directory2 grep: illegal option -- q grep: illegal option -- f Usage: grep -hblcnsviw pattern file . Moreover, it doesn't appear to be run through CONFIG_SHELL. -- Summary: scripts/check_jni_methods.sh is not portable Product: classpath Version: 0.17 Status: UNCONFIRMED Severity: normal Priority: P2 Component: classpath AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ebotcazou at gcc dot gnu dot org CC: bug-classpath at gnu dot org GCC build triplet: *-*-solaris2.* GCC host triplet: *-*-solaris2.* GCC target triplet: *-*-solaris2.* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23652 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: Patches to java.util.zip by Christian Schlichtherle
Christian Schlichtherle wrote: More specifically, the size and compressed size field in the ZipEntry class are causing the problems as some comparisons are happening on these. The issue is that once a big integer equal or greater than 2*1024^3 and smaller than 4*1024^3 is stored into a Java int, it is hard to use this int as if it were unsigned. You would have to do something like this on an int (untested): ... This is way too much computational overhead To compare two unsigned ints just invert their sign bits: I.e. (using C syntax): unsigned int32 i, j; signed int32 is = (signed int32) i; signed int32 js = (signed int32) j; Then (i COMP j) if and only if ((signed int32) (is ^ 0x80) COMP (signed int32) (js 0x8000)). Which is probably faster than: ((long) (is 0x) COMP (long) (js 0x)) -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
[Bug classpath/23653] lib/Makefile is not portable
--- Additional Comments From mark at klomp dot org 2005-08-31 14:12 --- Subject: Re: New: lib/Makefile is not portable -path is not a portable option for find. Would changing it to -wholename help? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23653 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: Patches to java.util.zip by Christian Schlichtherle
Jeroen Frijters wrote: Christian Schlichtherle wrote: For my personal education: What's wrong about adding constructors? It is a violation of the Sun license included with the API specification -- you could argue about whether the license is valid or not, but that's not the point, and it would preclude us (or any JVM based on GNU Classpath) from ever passing the TCK. Let us not beat about the bush. It would be bad for everyone (except Microsoft) if Java implementors were allowed to modify the APIs of the Java Class Libraries. Even if the API changes are upwards compatible (e.g. adding visible methods, constructors, fields or classes) the cause trouble. Specifically, if vendor XYZ has enhanced the APIs, then someone developing an application using vendor XYZ's Java platform may well find that their software does not run on other vendor's Java platform. Those with long memories will remember that Microsoft tried this trick. It was only the Sun license (and Sun's willingness to take Microsoft to court) that saved the Java community from the hell of vendor specific Java enhancements. -- Steve ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RE: Patches to java.util.zip by Christian Schlichtherle
Hi Christian, On Wed, 2005-08-31 at 14:05 +0200, Christian Schlichtherle wrote: For my personal education: What's wrong about adding constructors? The result would still be backward compatible to the JDK source, so I think this would make up a good solution. This is also what people have often requested from Sun if you look at the bug tracker thread on this topic. In principle there is nothing wrong about it. But it isn't really what GNU Classpath is currently focusing on. Creating a Free Software implementation of the core class libraries is already a lot of work. Tracking extensions would currently be additional work that would distract from completion our set of core libraries. It is really better done in separate projects that don't have explicit compatibility as a goal. Your TrueZIP is a nice example of that. There you can do real innovation and create a really great new interface for people to use. For GNU Classpath we are focusing on providing the freedoms people except when using Free Software, better/smaller/faster/smarter implementations, good and complete documentation and creating opportunities for research and integration with other free software platforms (see native compilation in gcj, integration with #c and .net through ikvm, our gtk+ and qt peers for gnome and kde integration, all the research done http://www.gnu.org/software/classpath/stories.html etc). That doesn't mean we aren't looking for innovations, but we are looking for ways to make them as transparent as possible to our users. GNU Classpath should just feel/be better out of the box then other (proprietary) implementations without the user having to explicitly use extensions in their programs. Who knows what happens when we are entering the endgame and GNU Classpath is as complete as the proprietary non-free implementation. But we are not there yet, and that is certainly still one or two years ahead of us. But even then for a core class library implementation being conservative about extensions is a good thing. If you aren't careful you have to support a new way to use the library for years and then you will have to make really sure that it is worth it both for your users and to the developers that need to maintain backwards compatibility with it. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
StatCVS report updated
I updated the StatCVS report for GNU Classpath: http://www.object-refinery.com/classpath/statcvs/ Regards, Dave ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RE: Patches to java.util.zip by Christian Schlichtherle
on Wed, 31 Aug 2005, Christian Schlichtherle wrote:
More specifically, the size and compressed size field in the ZipEntry
class
are causing the problems as some comparisons are happening on these.
The
issue is that once a big integer equal or greater than 2*1024^3 and
smaller
than 4*1024^3 is stored into a Java int, it is hard to use this int as
if it
were unsigned. You would have to do something like this on an int
(untested):
final static long NUM_FOUR_BYTE_INTS = 256L * 256L * 256L * 256L; //
Number
of 4 byte ints
private static long int2long(int i) {
return i = 0 ? (long)i : (long)NUM_FOUR_BYTE_INTS - (long)i;
}
private static void doIt() {
int ok = 2 * 1024 * 1024 * 1024 - 1; // max signed int
int tooBig = 3 * 1024 * 1024 * 1024; // Creates a negative
integer
// Compare ok and tooBig
assert int2long(ok) int2long(tooBig) : This is ok!;
assert ok tooBig : This fails!;
}
This is way too much computational overhead and it is way too easy to
forget
this on a comparison. Thus, the better way to deal with this issue is
hold 4
byte signed ints in a Java long if you don't need to care for the
memory
overhead.
Well, you could do that. But I find that:
long x = (i 0xL);
Converts an unsigned int (i) into a signed long (x) correctly just fine.
/Sven
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: Patches to java.util.zip by Christian Schlichtherle
Stephen Crawley wrote: Let us not beat about the bush. It would be bad for everyone (except Microsoft) if Java implementors were allowed to modify the APIs of the Java Class Libraries. If you are a Java(TM) licensee, I think you can modify the APIs through the respective JSRs at the JCP. Sun, IBM, and others do it all the time, afaict. The J2SE growth I see with each version has to come from somewhere :) If you are not a Java(TM) technology licensee, then you can, essentially, do whatever you want, modulo violating other people's rights, of course. Even if the API changes are upwards compatible (e.g. adding visible methods, constructors, fields or classes) the cause trouble. Specifically, if vendor XYZ has enhanced the APIs, then someone developing an application using vendor XYZ's Java platform may well find that their software does not run on other vendor's Java platform. Yeah, I fully agree. I see that sometimes, myself, too, and find it pretty annoying. Some people are apparently ocassionally developing their programs written in the Java programming language on some closed, proprietary implementation that contains APIs, which enhance the ones in GNU Classpath. So when I try to use their applications on a free runtime, like Kaffe, their applications just don't work. That's why educating developers about the Java Trap is important. Those with long memories will remember that Microsoft tried this trick. They even went so far as to drop RMI completely. And JNI. http://www.javaworld.com/jw-10-1997/jw-10-sunsuit.html It was only the Sun license (and Sun's willingness to take Microsoft to court) that saved the Java community from the hell of vendor specific Java enhancements. I only wish Sun had saved the Java community from com.sun.* and sun.*, tools.jar and similar Sun-specific, non-standarsised nosense, as well. I can't have it all, I guess :) cheers, dalibor topic ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
[Bug awt/20782] jawt assertion failure
--- Additional Comments From fitzsim at redhat dot com 2005-08-31 21:57 --- Fixed in GNU Classpath. Closing. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20782 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: Patches to java.util.zip by Christian Schlichtherle
Mark Wielaard wrote: But even then for a core class library implementation being conservative about extensions is a good thing. If you aren't careful you have to support a new way to use the library for years and then you will have to make really sure that it is worth it both for your users and to the developers that need to maintain backwards compatibility with it. I fully agree. I think the J2SE development over the last 10 years offers a strong argument in favour of conservativism. In 1996, the Java 1.0 Nutshell book came at whopping 460 pages, describing the language, and the APIs. In 1995, the Java in Nutshell book is now 1252 pages. And the language has not changed that much, to warrant such a blowup: it largely due to the JCP putting every API within their reach that could not run away fast enough into the J2SE. As a result, countless trees have been decimated for documenting all the backward compatibility cruft. ;) cheers, dalibor topic ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Patches to java.util.zip by Christian Schlichtherle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://www.javaworld.com/jw-10-1997/jw-10-sunsuit.html Interesting article, especially this one: And while Sun can exercise its legal rights over the use of the Java name, it can do little to stop Microsoft from implementing a clean room version of the Java virtual machine, says Morgenthal. :) cu Robert -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDFk2vG9cfwmwwEtoRAombAJ9UTVX6pPf1WLBog1fBIAOKkUCWrQCfQzGF 4iEmTksWnekMs9YRe8Aug1o= =9i55 -END PGP SIGNATURE- ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: [commit-cp] classpath ./ChangeLog java/util/zip/ZipEntry.ja...
Could this have caused the problem I'm now seeing with running the Swing demo: $ jamvm -Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel -classpath examples.zip gnu.classpath.examples.swing.Demo Cannot create system class loader Exception occured while printing exception (java/lang/RuntimeException)... Original exception was java/lang/ExceptionInInitializerError If I unzip the examples.zip archive and run the demo using the .class files, it works OK. This just started happening today. Regards, Dave Mark Wielaard wrote: CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Mark Wielaard [EMAIL PROTECTED] 05/08/30 21:47:44 Modified files: . : ChangeLog java/util/zip : ZipEntry.java ZipFile.java ZipInputStream.java ZipOutputStream.java Log message: 2005-08-30 Mark Wielaard [EMAIL PROTECTED] Christian Schlichtherle [EMAIL PROTECTED] * java/util/zip/ZipEntry.java (setTime): Use Calendar.setTimeInMillis(). (getTime): First parse extra bytes. Use Calendar.getTimeInMillis(). (parseExtra): Don't return early to make sure that KNOWN_EXTRA is always set. * java/util/zip/ZipFile.java (readEntries): Parse name and comment as UTF-8 string. (close): Check that raf is not null. * java/util/zip/ZipInputStream.java (getNextEntry): Set name as UTF-8 bytes. * java/util/zip/ZipOutputStream.java (setComment): Set comment as UTF-8 bytes. (putNextEntry): Likewise for name. (finish): Likewise for both. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.4597tr2=1.4598r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/util/zip/ZipEntry.java.diff?tr1=1.18tr2=1.19r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/util/zip/ZipFile.java.diff?tr1=1.23tr2=1.24r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/util/zip/ZipInputStream.java.diff?tr1=1.15tr2=1.16r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/util/zip/ZipOutputStream.java.diff?tr1=1.10tr2=1.11r1=textr2=text
[commit-cp] classpath ./ChangeLog javax/swing/plaf/basic/Ba...
CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: David Gilbert [EMAIL PROTECTED] 05/08/31 15:23:10 Modified files: . : ChangeLog javax/swing/plaf/basic: BasicButtonUI.java BasicCheckBoxMenuItemUI.java BasicCheckBoxUI.java BasicMenuItemUI.java BasicMenuUI.java BasicRadioButtonMenuItemUI.java BasicRadioButtonUI.java BasicToggleButtonUI.java javax/swing/plaf/metal: MetalCheckBoxUI.java Log message: 2005-08-31 David Gilbert [EMAIL PROTECTED] * javax/swing/plaf/basic/BasicButtonUI.java (getPropertyPrefix): include dot in prefix, (installDefaults): remove dot which is included in prefix now, * javax/swing/plaf/basic/BasicCheckBoxMenuItemUI.java (getPropertyPrefix): return correct prefix, * javax/swing/plaf/basic/BasicCheckBoxUI.java (getPropertyPrefix): return correct prefix, * javax/swing/plaf/basic/BasicMenuItemUI.java (getPropertyPrefix): return correct prefix, * javax/swing/plaf/basic/BasicMenuUI.java (getPropertyPrefix): return correct prefix, * javax/swing/plaf/basic/BasicRadioButtonMenuItemUI.java (getPropertyPrefix): return correct prefix, * javax/swing/plaf/basic/BasicRadioButtonUI.java (getPropertyPrefix): include dot in prefix, (getDefaultIcon): removed dot which is part of the prefix, * javax/swing/plaf/basic/BasicToggleButtonUI.java (getPropertyPrefix): include dot in prefix, * javax/swing/plaf/metal/MetalCheckBoxUI.java: now extends MetalRadioButtonUI, (getPropertyPrefix): implemented. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.4598tr2=1.4599r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/javax/swing/plaf/basic/BasicButtonUI.java.diff?tr1=1.23tr2=1.24r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/javax/swing/plaf/basic/BasicCheckBoxMenuItemUI.java.diff?tr1=1.8tr2=1.9r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/javax/swing/plaf/basic/BasicCheckBoxUI.java.diff?tr1=1.10tr2=1.11r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/javax/swing/plaf/basic/BasicMenuItemUI.java.diff?tr1=1.20tr2=1.21r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/javax/swing/plaf/basic/BasicMenuUI.java.diff?tr1=1.14tr2=1.15r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/javax/swing/plaf/basic/BasicRadioButtonMenuItemUI.java.diff?tr1=1.8tr2=1.9r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/javax/swing/plaf/basic/BasicRadioButtonUI.java.diff?tr1=1.9tr2=1.10r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/javax/swing/plaf/basic/BasicToggleButtonUI.java.diff?tr1=1.10tr2=1.11r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/javax/swing/plaf/metal/MetalCheckBoxUI.java.diff?tr1=1.3tr2=1.4r1=textr2=text
Re: [cp-patches] Re: [commit-cp] classpath ./ChangeLog java/util/zip/ZipEntry.ja...
On Aug 31, 2005, at 12:14 PM, David Gilbert wrote: Could this have caused the problem I'm now seeing with running the Swing demo: $ jamvm -Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel -classpath examples.zip gnu.classpath.examples.swing.Demo Cannot create system class loader Exception occured while printing exception (java/lang/RuntimeException)... Original exception was java/lang/ExceptionInInitializerError If I unzip the examples.zip archive and run the demo using the .class files, it works OK. This just started happening today. This has been happening to me since I downloaded jamvm and classpath. -- Pinski
Re: [cp-patches] Re: [commit-cp] classpath ./ChangeLog java/util/zip/ZipEntry.ja...
Andrew Pinski wrote: On Aug 31, 2005, at 12:14 PM, David Gilbert wrote: Could this have caused the problem I'm now seeing with running the Swing demo: $ jamvm -Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel -classpath examples.zip gnu.classpath.examples.swing.Demo Cannot create system class loader Exception occured while printing exception (java/lang/RuntimeException)... Original exception was java/lang/ExceptionInInitializerError If I unzip the examples.zip archive and run the demo using the .class files, it works OK. This just started happening today. This has been happening to me since I downloaded jamvm and classpath. -- Pinski Thanks for confirming that it is not just me. I can get the demo to run by unzipping examples.zip and typing: [EMAIL PROTECTED] ~/classpath-cvs/classpath/examples $ jamvm -Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel -classpath . gnu.classpath.examples.swing.Demo Regards, Dave
[commit-cp] classpath ./ChangeLog java/nio/charset/Charset....
CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Mark Wielaard [EMAIL PROTECTED] 05/08/31 17:01:43 Modified files: . : ChangeLog java/nio/charset: Charset.java Log message: * java/nio/charset/Charset.java (charsetForName): Try default provider before trying to load extra providers. (availableCharsets): Explicitly add default provider Charsets. (providers2): Don't include default provider. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.4600tr2=1.4601r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/nio/charset/Charset.java.diff?tr1=1.23tr2=1.24r1=textr2=text
[commit-cp] classpath ./ChangeLog gnu/java/awt/peer/gtk/Gtk...
CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Thomas Fitzsimmons [EMAIL PROTECTED] 05/08/31 21:18:15 Modified files: . : ChangeLog gnu/java/awt/peer/gtk: GtkComponentPeer.java Log message: 2005-08-31 Thomas Fitzsimmons [EMAIL PROTECTED] * gnu/java/awt/peer/gtk/GtkComponentPeer.java (setBounds): Only add parent's x and y co-ordinates to translation if parent's parent is not a window. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.4604tr2=1.4605r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/gnu/java/awt/peer/gtk/GtkComponentPeer.java.diff?tr1=1.95tr2=1.96r1=textr2=text
[commit-cp] classpath ChangeLog
CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Thomas Fitzsimmons [EMAIL PROTECTED] 05/08/31 21:28:49 Modified files: . : ChangeLog Log message: * ChangeLog: Add PR reference. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.4606tr2=1.4607r1=textr2=text
