Re: [cp-patches] Patch: midi example program
1. It would be interesting to have a MIDI demo. It maybe could even emit
some sounds, if the devices are available.
2. If the class is executable, should it maybe better be public? Some
IDE's may not provide context command to run non-public class.
Anthony Green wrote:
Here's a GUI midi demo for the examples collection.
It's just a window with two combo boxes for selecting the MIDI IN and
OUT devices. It's handy for debugging.
OK?
AG
2005-10-04 Anthony Green [EMAIL PROTECTED]
* examples/gnu/classpath/examples/midi/Demo.java: New file.
diff -uN examples/gnu/classpath/examples/midi-empty/Demo.java
examples/gnu/classpath/examples/midi/Demo.java
--- examples/gnu/classpath/examples/midi-empty/Demo.java1969-12-31
16:00:00.0 -0800
+++ examples/gnu/classpath/examples/midi/Demo.java 2005-10-04
18:11:48.0 -0700
@@ -0,0 +1,137 @@
+/* Demo.java -- And example of MIDI support
+ Copyright (C) 2005 Free Software Foundation, Inc.
+
+This file is part of GNU Classpath examples.
+
+GNU Classpath is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU Classpath is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU Classpath; see the file COPYING. If not, write to the
+Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+02110-1301 USA. */
+
+package gnu.classpath.examples.midi;
+
+import java.awt.*;
+import java.awt.event.*;
+import java.util.*;
+import javax.sound.midi.*;
+
+/**
+ * An example how javax.sound.midi facilities work.
+ */
+class Demo extends Frame implements ItemListener
+{
+ Choice midiInChoice = new Choice();
+ Choice midiOutChoice = new Choice();
+
+ MidiDevice inDevice = null;
+ MidiDevice outDevice = null;
+
+ ArrayList inDevices = new ArrayList();
+ ArrayList outDevices = new ArrayList();
+
+ public Demo () throws Exception
+ {
+MenuBar mb = new MenuBar ();
+Menu menu = new Menu (File);
+MenuItem quit = new MenuItem(Quit, new MenuShortcut('Q'));
+quit.addActionListener(new ActionListener()
+ {
+ public void actionPerformed(ActionEvent e)
+ {
+ System.exit(0);
+ }
+ });
+menu.add (quit);
+mb.add(menu);
+
+setTitle(synthcity: the GNU Classpath MIDI Demo);
+setLayout(new FlowLayout());
+
+MidiDevice.Info[] infos = MidiSystem.getMidiDeviceInfo();
+
+for (int i = 0; i infos.length; i++)
+ {
+ MidiDevice device = MidiSystem.getMidiDevice(infos[i]);
+ if (device.getMaxReceivers() 0)
+ {
+ midiOutChoice.addItem(infos[i].getDescription());
+ outDevices.add(device);
+ }
+ if (device.getMaxTransmitters() 0)
+ {
+ midiInChoice.addItem(infos[i].getDescription());
+ inDevices.add(device);
+ }
+ }
+
+setMenuBar (mb);
+add(new Label(MIDI IN: ));
+add(midiInChoice);
+add(new Label( MIDI OUT: ));
+add(midiOutChoice);
+
+midiInChoice.addItemListener(this);
+midiOutChoice.addItemListener(this);
+
+pack();
+show();
+ }
+
+ public void itemStateChanged (ItemEvent e)
+ {
+try
+ {
+ if (e.getItemSelectable() == midiInChoice)
+ {
+ if (inDevice != null)
+ inDevice.close();
+ inDevice = (MidiDevice)
+ inDevices.get(midiInChoice.getSelectedIndex());
+ }
+
+ if (e.getItemSelectable() == midiOutChoice)
+ {
+ if (outDevice != null)
+ outDevice.close();
+ outDevice = (MidiDevice)
+ outDevices.get(midiOutChoice.getSelectedIndex());
+ }
+
+ if (inDevice != null outDevice != null)
+ {
+ if (! inDevice.isOpen())
+ inDevice.open();
+ if (! outDevice.isOpen())
+ outDevice.open();
+ Transmitter t = inDevice.getTransmitter();
+ if (t == null)
+ System.err.println (inDevice + .getTransmitter() == null);
+ Receiver r = outDevice.getReceiver();
+ if (r == null)
+ System.err.println (outDevice + .getReceiver() == null);
+
+ if (t != null r != null)
+ t.setReceiver (r);
+ }
+ }
+catch (Exception ex)
+ {
+ ex.printStackTrace();
+ }
+ }
+
+ public static void main (String args[]) throws Exception
+{
+ new Demo();
+}
+}
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] Stupid spec constant values
(I'm not subscribed to classpath-patches so please cc me on responses)
Here are a couple of patches to deal with japi errors relating to
constant field values. In both cases they reflect stupidity in the
spec but since binary compatibility *does* require that constant field
values should match I think the japi errors are valid. Sun even
include these values in their documentation these days, ridiculous as
they are.
I'd prefer if someone else would commit these because I haven't
touched the classpath code in ages and I'm afraid of breaking things
;) I'd also like someone who understands the rmi code to check that
patch, because even though I changed the only code in Classpath itself
that uses the packagePrefix field, I'm not sure whether there are any
implications for code outside of Classpath that refers to it. (Note
that any such code would already be broken if compiled against the JDK
- my concern is whether *more* work is needed here to cover all the
cases).
Here's a changelog for the RMI one (hope I got the format right):
2005-10-04 Stuart Ballard [EMAIL PROTECTED]
* java/rmi/LoaderHandler.java (packagePrefix): Match Sun's value.
* java/rmi/RemoteRef.java (packagePrefix): Likewise.
* java/rmi/RemoteObject.java (readObject): Hardcode the GNU package
prefix.
And for the swing one:
2005-10-04 Stuart Ballard [EMAIL PROTECTED]
* javax/swing/undo/StateEdit.java (RCSID): Match Sun's value.
* javax/swing/undo/StateEditable.java (RCSID): Likewise.
Thanks,
Stuart.
--
http://sab39.dev.netreach.com/
? java/rmi/server/.RemoteObject.java.swp
Index: java/rmi/server/LoaderHandler.java
===
RCS file: /cvsroot/classpath/classpath/java/rmi/server/LoaderHandler.java,v
retrieving revision 1.7
diff -u -u -r1.7 LoaderHandler.java
--- java/rmi/server/LoaderHandler.java 2 Jul 2005 20:32:40 - 1.7
+++ java/rmi/server/LoaderHandler.java 4 Oct 2005 17:59:19 -
@@ -45,7 +45,11 @@
*/
public interface LoaderHandler
{
- String packagePrefix = ;
+ /**
+ * For binary compatibility with the JDK, the string sun.rmi.server.
+ * Not actually used for anything.
+ */
+ String packagePrefix = sun.rmi.server;
/**
* @deprecated
Index: java/rmi/server/RemoteObject.java
===
RCS file: /cvsroot/classpath/classpath/java/rmi/server/RemoteObject.java,v
retrieving revision 1.9
diff -u -u -r1.9 RemoteObject.java
--- java/rmi/server/RemoteObject.java 2 Jul 2005 20:32:40 - 1.9
+++ java/rmi/server/RemoteObject.java 4 Oct 2005 17:59:19 -
@@ -120,7 +120,9 @@
in.read (); //some unknown UnicastRef2 field
}
- cname = RemoteRef.packagePrefix + '.' + cname;
+ // It would be nice to use RemoteRef.packagePrefix here, but for binary
+ // compatibility with the JDK that has to contain sun.rmi.server...
+ cname = gnu.java.rmi.server. + cname;
try
{
Class cls = Class.forName(cname);
Index: java/rmi/server/RemoteRef.java
===
RCS file: /cvsroot/classpath/classpath/java/rmi/server/RemoteRef.java,v
retrieving revision 1.8
diff -u -u -r1.8 RemoteRef.java
--- java/rmi/server/RemoteRef.java 2 Jul 2005 20:32:40 - 1.8
+++ java/rmi/server/RemoteRef.java 4 Oct 2005 17:59:19 -
@@ -48,7 +48,11 @@
{
long serialVersionUID = 3632638527362204081L;
- String packagePrefix = gnu.java.rmi.server;
+ /**
+ * For binary compatibility with the JDK, the string sun.rmi.server.
+ * Not actually used for anything.
+ */
+ String packagePrefix = sun.rmi.server;
/**
* @deprecated
Index: javax/swing/undo/StateEdit.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/undo/StateEdit.java,v
retrieving revision 1.8
diff -u -u -r1.8 StateEdit.java
--- javax/swing/undo/StateEdit.java 2 Jul 2005 20:32:52 - 1.8
+++ javax/swing/undo/StateEdit.java 4 Oct 2005 17:59:41 -
@@ -104,9 +104,11 @@
* System (RCS). This certainly should not be part of the API
* specification. But in order to be API-compatible with
* Sun#x2019;s reference implementation, GNU Classpath also has to
- * provide this field. However, we do not try to match its value.
+ * provide this field and match its value. The value used here is
+ * from the JDK 1.5 release.
*/
- protected static final String RCSID = ;
+ protected static final String RCSID = $ +
+Id: StateEdit.java,v 1.6 1997/10/01 20:05:51 sandipc Exp $;
/**
Index: javax/swing/undo/StateEditable.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/undo/StateEditable.java,v
retrieving revision 1.7
diff -u -u -r1.7 StateEditable.java
--- javax/swing/undo/StateEditable.java 2 Jul 2005 20:32:52 - 1.7
+++ javax/swing/undo/StateEditable.java 4 Oct 2005 17:59:41
Re: [cp-patches] Patch: dssi control handling
Hi Anthony, On Tue, 2005-10-04 at 08:21 -0700, Anthony Green wrote: The following patch sets up the controller mapping and processes MIDI controller events. OK? You obviously are the person that knows this code best. You didn't say what kind of feedback you would like so I am giving the feedback I am best at maintainer nitpicks... +/* The original get_port_default() and set_control() routines were + * copied from the DSSI source distribution and are covered by the + * following copyright and license... + * + * Copyright 2004 Chris Cannam, Steve Harris and Sean Bolton. + * + * Permission to use, copy, modify, distribute, and sell this software + * for any purpose is hereby granted without fee, provided that the + * above copyright notice and this permission notice are included in + * all copies or substantial portions of the software. + */ In general this is free software and gpl-compatible, so we can use that. But we should list all such things explicitly in the file LICENSING with an explicit reference to the upstream source. I will also send an email to FSF legal to alert them about our inclusion of this for their records and input. And if at all possible it would be good to have these two routines in a separate file so it is clear we are not the original authors/upstream for this code. There (or in a separate README) you can also list what changes (if any) we made to this code. See for examples the LICENSE file and the external project READMEs in the external sub-directories. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Stupid spec constant values
Hi Stuart, On Tue, 2005-10-04 at 14:16 -0400, Stuart Ballard wrote: Here are a couple of patches to deal with japi errors relating to constant field values. In both cases they reflect stupidity in the spec but since binary compatibility *does* require that constant field values should match I think the japi errors are valid. Sun even include these values in their documentation these days, ridiculous as they are. The RCSID fields really serve no good purpose and I would just propose we remove these fields and ask for a japi override mode to ignore them. I bet the value of these fields even changes between minor releases. The LoaderHandler.packagePrefix is also a bit subtle. The only way I can see why/how people are using it is to check whether a LoaderHandler is actually the system LoaderHandler implementation. So changing it to something that isn't actually the package that we define it in might break code (not seen actual code that does that though). IBM doesn't seem to document the value of this constant in their online documentation and I don't have an RMI book handy to see what they say about it. Although the whole class is deprecated so I doubt it really matters much. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Patch: dssi control handling
On Wed, 2005-10-05 at 10:26 +0200, Mark Wielaard wrote: And if at all possible it would be good to have these two routines in a separate file so it is clear we are not the original authors/upstream for this code. There (or in a separate README) you can also list what changes (if any) we made to this code. Ok, I'll do this. Thanks, AG ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
RE: [cp-patches] Stupid spec constant values
Stuart Ballard wrote: On 10/5/05, Jeroen Frijters [EMAIL PROTECTED] wrote: They never change. They only exist because of an historical accident, way back. I don't have a strong opinion on whether we should copy them or not, but I certainly have no objection against it (and I'd like the Japi scores to be as high as reasonably possible). They do change - if you look in the japi results they're different in different versions (I checked 1.2, 1.4 and 1.5). Not that it matters much, but I didn't see any changes from 1.3 to 1.4 to 1.5, and given the fact that the dates are both in 1997, I assumed it was just a historical thing. Regards, Jeroen ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] FYI: JTableHeader completed
Hi,
I added the remaining missing methods to javax.swing.table.JTableHeader.
2005-10-05 Roman Kennke [EMAIL PROTECTED]
* javax/swing/table/JTableHeader.java
(accessibleContext): Removed unneeded field. The protected
field with the same name should be used instead.
(JTableHeader): Moved field initialization to new method
initializeLocalVars().
(setColumnModel): Add and remove this to the old and new model.
(columnAdded): New listener method.
(columnMarginChanged): New listener method.
(columnMoved): New listener method.
(columnRemoved): New listener method.
(columnSelectionChanged): New listener method.
(resizeAndRepaint): New method.
(initializeLocalVars): New method.
/Roman
Index: javax/swing/table/JTableHeader.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/table/JTableHeader.java,v
retrieving revision 1.12
diff -u -r1.12 JTableHeader.java
--- javax/swing/table/JTableHeader.java 2 Jul 2005 20:32:51 - 1.12
+++ javax/swing/table/JTableHeader.java 5 Oct 2005 14:11:43 -
@@ -61,9 +61,14 @@
import javax.swing.JComponent;
import javax.swing.JTable;
import javax.swing.UIManager;
+import javax.swing.event.ChangeEvent;
+import javax.swing.event.ListSelectionEvent;
+import javax.swing.event.TableColumnModelEvent;
+import javax.swing.event.TableColumnModelListener;
import javax.swing.plaf.TableHeaderUI;
public class JTableHeader extends JComponent
+ implements TableColumnModelListener, Accessible
{
protected class AccessibleJTableHeader extends AccessibleJComponent
{
@@ -305,11 +310,6 @@
private static final long serialVersionUID = 5144633983372967710L;
/**
- * The accessibleContext property.
- */
- AccessibleContext accessibleContext;
-
- /**
* The columnModel property.
*/
protected TableColumnModel columnModel;
@@ -373,17 +373,8 @@
*/
public JTableHeader(TableColumnModel cm)
{
-accessibleContext = new AccessibleJTableHeader();
columnModel = cm == null ? createDefaultColumnModel() : cm;
-draggedColumn = null;
-draggedDistance = 0;
-opaque = true;
-reorderingAllowed = true;
-resizingAllowed = true;
-resizingColumn = null;
-table = null;
-updateTableInRealTime = true;
-cellRenderer = createDefaultRenderer();
+initializeLocalVars();
updateUI();
}
@@ -504,7 +495,9 @@
*/
public void setColumnModel(TableColumnModel c)
{
+columnModel.removeColumnModelListener(this);
columnModel = c;
+columnModel.addColumnModelListener(this);
}
/**
@@ -664,5 +657,89 @@
return columnModel.getColumnIndexAtX(point.x);
return -1;
+ }
+
+ /**
+ * Receives notification when a column is added to the column model.
+ *
+ * @param event the table column model event
+ */
+ public void columnAdded(TableColumnModelEvent event)
+ {
+// TODO: What else to do here (if anything)?
+resizeAndRepaint();
+ }
+
+ /**
+ * Receives notification when a column margin changes in the column model.
+ *
+ * @param event the table column model event
+ */
+ public void columnMarginChanged(ChangeEvent event)
+ {
+// TODO: What else to do here (if anything)?
+resizeAndRepaint();
+ }
+
+ /**
+ * Receives notification when a column is moved within the column model.
+ *
+ * @param event the table column model event
+ */
+ public void columnMoved(TableColumnModelEvent event)
+ {
+// TODO: What else to do here (if anything)?
+resizeAndRepaint();
+ }
+
+ /**
+ * Receives notification when a column is removed from the column model.
+ *
+ * @param event the table column model event
+ */
+ public void columnRemoved(TableColumnModelEvent event)
+ {
+// TODO: What else to do here (if anything)?
+resizeAndRepaint();
+ }
+
+ /**
+ * Receives notification when the column selection has changed.
+ *
+ * @param event the table column model event
+ */
+ public void columnSelectionChanged(ListSelectionEvent event)
+ {
+// TODO: What else to do here (if anything)?
+resizeAndRepaint();
+ }
+
+ /**
+ * Validates the layout of this table header and repaints it. This is
+ * equivalent to coderevalidate()/code followed by
+ * coderepaint()/code.
+ */
+ public void resizeAndRepaint()
+ {
+revalidate();
+repaint();
+ }
+
+ /**
+ * Initializes the fields and properties of this class with default values.
+ * This is called by the constructors.
+ */
+ protected void initializeLocalVars()
+ {
+accessibleContext = new AccessibleJTableHeader();
+draggedColumn = null;
+draggedDistance = 0;
+opaque = true;
+reorderingAllowed = true;
+resizingAllowed = true;
+resizingColumn = null;
+table = null;
+updateTableInRealTime = true;
+cellRenderer = createDefaultRenderer();
}
[cp-patches] FYI: AbstractDocument and GapContent patch
This patch makes AbstractDocument return an ElementChange in the
DocumentEvent that it fires after a remove operation. Adds undoable
edit support to GapContent's remove operation.
2005-10-05 Anthony Balkissoon [EMAIL PROTECTED]
* javax/swing/text/AbstractDocument.java:
(remove): If removing content returns an UndoableEdit, then add an
ElementEdit to the DocumentEvent before firing.
* javax/swing/text/GapContent.java:
(UndoRemove): New class to implement UndoableEdit for remove operation.
(remove): Return an UndoableEdit instead of null.
--Tony
Index: javax/swing/text/AbstractDocument.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/text/AbstractDocument.java,v
retrieving revision 1.31
diff -u -r1.31 AbstractDocument.java
--- javax/swing/text/AbstractDocument.java 4 Oct 2005 19:37:19 - 1.31
+++ javax/swing/text/AbstractDocument.java 5 Oct 2005 15:12:26 -
@@ -616,10 +616,38 @@
DefaultDocumentEvent event =
new DefaultDocumentEvent(offset, length,
DocumentEvent.EventType.REMOVE);
+
+// Here we set up the parameters for an ElementChange, if one
+// needs to be added to the DocumentEvent later
+Element root = getDefaultRootElement();
+int start = root.getElementIndex(offset);
+int end = root.getElementIndex(offset + length);
+
+Element[] removed = new Element[end - start + 1];
+for (int i = start; i = end; i++)
+ removed[i - start] = root.getElement(i);
+
removeUpdate(event);
+
+Element[] added = new Element[1];
+added[0] = root.getElement(start);
boolean shouldFire = content.getString(offset, length).length() != 0;
-content.remove(offset, length);
+
+UndoableEdit temp = content.remove(offset, length);
+
postRemoveUpdate(event);
+
+GapContent.UndoRemove changes = null;
+if (content instanceof GapContent)
+ changes = (GapContent.UndoRemove) temp;
+
+if (changes != null)
+ {
+// We need to add an ElementChange to our DocumentEvent
+ElementEdit edit = new ElementEdit (root, start, removed, added);
+event.addEdit(edit);
+ }
+
if (shouldFire)
fireRemoveUpdate(event);
}
Index: javax/swing/text/GapContent.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/text/GapContent.java,v
retrieving revision 1.29
diff -u -r1.29 GapContent.java
--- javax/swing/text/GapContent.java 4 Oct 2005 19:37:19 - 1.29
+++ javax/swing/text/GapContent.java 5 Oct 2005 15:12:26 -
@@ -168,6 +168,44 @@
}
+ class UndoRemove extends AbstractUndoableEdit
+ {
+public int where;
+String text;
+public UndoRemove(int start, String removedText)
+{
+ where = start;
+ text = removedText;
+}
+
+public void undo () throws CannotUndoException
+{
+ super.undo();
+ try
+ {
+insertString(where, text);
+ }
+ catch (BadLocationException ble)
+ {
+throw new CannotUndoException();
+ }
+}
+
+public void redo () throws CannotUndoException
+{
+ super.redo();
+ try
+ {
+remove(where, text.length());
+ }
+ catch (BadLocationException ble)
+ {
+throw new CannotRedoException();
+ }
+}
+
+ }
+
/** The serialization UID (compatible with JDK1.5). */
private static final long serialVersionUID = -6226052713477823730L;
@@ -259,8 +297,7 @@
* @param where the position where the string is inserted
* @param str the string that is to be inserted
*
- * @return an UndoableEdit object (currently not supported, so
- * codenull/code is returned)
+ * @return an UndoableEdit object
*
* @throws BadLocationException if codewhere/code is not a valid
* location in the buffer
@@ -287,8 +324,7 @@
* @param where the position where the content is to be removed
* @param nitems number of characters to be removed
*
- * @return an UndoableEdit object (currently not supported, so
- * codenull/code is returned)
+ * @return an UndoableEdit object
*
* @throws BadLocationException if codewhere/code is not a valid
* location in the buffer
@@ -305,9 +341,10 @@
throw new BadLocationException(where + nitems cannot be greater
+ than the content length, where + nitems);
+String removedText = getString(where, nitems);
replace(where, nitems, null, 0);
-return null;
+return new UndoRemove(where, removedText);
}
/**
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
RE: [cp-patches] Stupid spec constant values
Hi, On Wed, 2005-10-05 at 12:02 +0200, Jeroen Frijters wrote: Mark Wielaard wrote: The RCSID fields really serve no good purpose and I would just propose we remove these fields and ask for a japi override mode to ignore them. I bet the value of these fields even changes between minor releases. They never change. They only exist because of an historical accident, way back. I don't have a strong opinion on whether we should copy them or not, but I certainly have no objection against it (and I'd like the Japi scores to be as high as reasonably possible). But later in the thread it seems that these constants do change. So I ignore this part for now. The LoaderHandler.packagePrefix is also a bit subtle. The only way I can see why/how people are using it is to check whether a LoaderHandler is actually the system LoaderHandler implementation. So changing it to something that isn't actually the package that we define it in might break code (not seen actual code that does that though). This one is very subtle. Since it is a compile time constant, the compiler will inline the value, so if a piece of code is compiled against GNU Classpath and then run on Sun's JDK (or vice versa) you get incorrect results. So I'd argue for changing our constants to match Sun's. Of course. You are right. Constant Strings get inlined (stupid compiler optimization if you ask me). I would say that people should always compile from source against the libraries they want to actually use. But there is no point in deliberately not being compatible here. And the change does look right. So I'll check it in. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Stupid spec constant values
Hi, On Wed, 2005-10-05 at 09:40 -0400, Stuart Ballard wrote: On 10/5/05, Jeroen Frijters [EMAIL PROTECTED] wrote: Stuart Ballard wrote: Not that it matters much, but I didn't see any changes from 1.3 to 1.4 to 1.5, and given the fact that the dates are both in 1997, I assumed it was just a historical thing. The values in the japi results are different in those versions. Perhaps they were different in the Blackdown JDKs - I think those are the versions I have installed for 1.2 through 1.4. What that means for what the right thing to do is, I don't know, though. I think the right thing to do here is just ignoring this field. A constantly changing constant static field value is useless anyway. And adding RCS keywords in our own source code only makes the problem worse since people have to be careful that they don't get expanded when moving the source around between repositories. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Stupid spec constant values
On 10/5/05, Jeroen Frijters [EMAIL PROTECTED] wrote: Stuart Ballard wrote: Not that it matters much, but I didn't see any changes from 1.3 to 1.4 to 1.5, and given the fact that the dates are both in 1997, I assumed it was just a historical thing. The values in the japi results are different in those versions. Perhaps they were different in the Blackdown JDKs - I think those are the versions I have installed for 1.2 through 1.4. What that means for what the right thing to do is, I don't know, though. http://www.kaffe.org/~stuart/japi/htmlout/cvs/h-jdk13-classpath.html#err_bad_javax_swing_undo http://www.kaffe.org/~stuart/japi/htmlout/cvs/h-jdk14-classpath.html#err_bad_javax_swing_undo http://www.kaffe.org/~stuart/japi/htmlout/cvs/h-jdk15-classpath.html#err_bad_javax_swing_undo Interestingly some of the earlier values actually give later dates... The 1.5 values in the japi results match the docs, though. Stuart. -- http://sab39.dev.netreach.com/ ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Stupid spec constant values
Stuart == Stuart Ballard [EMAIL PROTECTED] writes: Stuart Putting the values in, stupid and ridiculous as they are, costs us Stuart nothing, but it eliminates a false positive in the errors so that the Stuart *real* errors stand out more. Yeah. Stuart Exactly - in other words, code working as you (Mark) described would Stuart fail anyway, unless we actually moved our implementations into a Stuart sun.rmi.server package. Since this is purely hypothetical code we're Stuart talking about, I'd not bother, but if any actual such code showed up, Stuart that's what we'd have to do. Yeah, or do bytecode rewriting in the class loader :-) Stuart Sun has a whole constant field values page in their documentation Stuart and all these values are listed there - even the RCSIDs. I've always assumed that this page is auto-generated by javadoc, which unfortunately doesn't know how to distinguish the dumb constants ;-) I think this patch should go in. Perhaps the javadoc comments could use an '@specnote' before the text explaining the lameness of these fields? Tom ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] FYI: JOptionPane.showInputDialog() doesn't need to cast return value
Hi, The JOptionPane.showInputDialog(Component, Object, String, int, Icon, Object[], Object) and the internalShowInputDialog version were casting the return value to a String, but since it returns an Object this was just wrong. All other variants of [internal]showInputDialog() do return Strings so this was probably just a copy/paste error. 2005-10-05 Mark Wielaard [EMAIL PROTECTED] * javax/swing/JOptionPane.java (showInputDialog(Component,Object,String,int,Icon,Object[],Object)): Don't cast return value. (internalShowInputDialog(Component,Object,String,int,Icon,Object[], Object)): Likewise. Found by running pollo. Committed, Mark Index: javax/swing/JOptionPane.java === RCS file: /cvsroot/classpath/classpath/javax/swing/JOptionPane.java,v retrieving revision 1.19 diff -u -r1.19 JOptionPane.java --- javax/swing/JOptionPane.java 3 Oct 2005 15:23:44 - 1.19 +++ javax/swing/JOptionPane.java 5 Oct 2005 17:31:10 - @@ -1059,7 +1059,7 @@ dialog.pack(); dialog.show(); -return (String) pane.getInputValue(); +return pane.getInputValue(); } /** @@ -1298,7 +1298,7 @@ startModal(frame); -return (String) pane.getInputValue(); +return pane.getInputValue(); } /** 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] FYI: PlainView implementations
This implements insertUpdate and removeUpdate for PlainView.
I did this work in response to bug 24152:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24152
Basically, this allows us to cache the length of the longest line (and
which line it is) so that calls to getPreferredSpan don't take a
ridiculously long time. These 2 methods allow us to calculate the
length on the fly as text is inserted and deleted.
The test program in the bug report used to be unrunnable under classpath
because the delay was (much much much) too long, but it is runnable
now.
However, the method getDemoText (in the test case attached to the bug
report) still runs orders of magnitude slower on classpath than on the
JDK. The calls in the method are to Math.random and to
StringBuffer.append. Someone may want to look into this.
2005-10-05 Anthony Balkissoon [EMAIL PROTECTED]
* javax/swing/text/PlainView.java:
(insertOrRemoveUpdate): New method.
(insertUpdate): New method.
(removeUpdate): New method.
--Tony
Index: javax/swing/text/PlainView.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/text/PlainView.java,v
retrieving revision 1.14
diff -u -r1.14 PlainView.java
--- javax/swing/text/PlainView.java 4 Oct 2005 19:37:20 - 1.14
+++ javax/swing/text/PlainView.java 5 Oct 2005 18:07:29 -
@@ -46,6 +46,9 @@
import java.awt.Rectangle;
import java.awt.Shape;
+import javax.swing.event.DocumentEvent;
+import javax.swing.event.DocumentEvent.ElementChange;
+
public class PlainView extends View
implements TabExpander
{
@@ -289,6 +292,101 @@
{
// FIXME: not implemented
return 0;
+ }
+
+ /**
+ * Since insertUpdate and removeUpdate each deal with children
+ * Elements being both added and removed, they both have to perform
+ * the same checks. So they both simply call this method.
+ * @param changes the DocumentEvent for the changes to the Document.
+ * @param a the allocation of the View.
+ * @param f the ViewFactory to use for rebuilding.
+ */
+ void insertOrRemoveUpdate(DocumentEvent changes, Shape a, ViewFactory f)
+ {
+Element el = getElement();
+ElementChange ec = changes.getChange(el);
+if (ec == null)
+ return;
+
+// Check to see if we removed the longest line, if so we have to
+// search through all lines and find the longest one again
+Element[] removed = ec.getChildrenRemoved();
+if (removed != null)
+ {
+for (int i = 0; i removed.length; i++)
+ if (removed[i].equals(longestLine))
+{
+ // reset maxLineLength and search through all lines for longest one
+ maxLineLength = -1;
+ determineMaxLineLength();
+ return;
+}
+ }
+
+// Make sure we have the metrics
+updateMetrics();
+
+// Since we didn't remove the longest line, we can just compare it to
+// the new lines to see if any of them are longer
+Element[] newElements = ec.getChildrenAdded();
+Segment seg = new Segment();
+float longestNewLength = 0;
+Element longestNewLine = null;
+
+if (newElements == null)
+ return;
+for (int i = 0; i newElements.length; i++)
+ {
+Element child = newElements[i];
+int start = child.getStartOffset();
+int end = child.getEndOffset();
+try
+ {
+el.getDocument().getText(start, start + end, seg);
+ }
+catch (BadLocationException ex)
+ {
+ }
+
+int width = metrics.charsWidth(seg.array, seg.offset, seg.count);
+if (width longestNewLength)
+ {
+longestNewLine = child;
+longestNewLength = width;
+ }
+ }
+if (longestNewLength maxLineLength)
+ {
+maxLineLength = longestNewLength;
+longestLine = longestNewLine;
+ }
+ }
+
+ /**
+ * This method is called when something is inserted into the Document
+ * that this View is displaying.
+ *
+ * @param changes the DocumentEvent for the changes.
+ * @param a the allocation of the View
+ * @param f the ViewFactory used to rebuild
+ */
+ public void insertUpdate(DocumentEvent changes, Shape a, ViewFactory f)
+ {
+insertOrRemoveUpdate(changes, a, f);
+ }
+
+ /**
+ * This method is called when something is removed from the Document
+ * that this View is displaying.
+ *
+ * @param changes the DocumentEvent for the changes.
+ * @param a the allocation of the View
+ * @param f the ViewFactory used to rebuild
+ */
+ public void removeUpdate(DocumentEvent changes, Shape a, ViewFactory f)
+ {
+insertOrRemoveUpdate(changes, a, f);
}
}
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] __attribute__ patch (Was: Re: RFC: __attribute__ handling)
Twisti == Christian Thalinger [EMAIL PROTECTED] writes: Twisti Here is the actual patch. Tested on IRIX with MIPSPro compiler. I'm checking this in. FWIW a patch like this is easier to apply if you use 'cvs diff -N' to get the new files in the patch for real. The 'cvsdo' utility can fake a cvs add if you don't have write permission... Tom ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] FYI: GapContent fix
Hi,
I discovered and fixed an issue with GapContent. The positions are
expected to be stored sorted, but they weren't. The methods
setPositionsInRange and adjustPositionsInRange were messing this up.
I also added two private methods that could be used for debugging. I
regularily need something like this.
2005-10-05 Roman Kennke [EMAIL PROTECTED]
* javax/swing/text/GapContent.java
(setPositionsInRange): Changed check for interval end to actually
check for the position offsets.
(adjustPositionsInRange): Changed check for interval end to actually
check for the position offsets.
(dump): New method for debugging.
(dumpPositions): New method for debugging.
/Roman
Index: javax/swing/text/GapContent.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/text/GapContent.java,v
retrieving revision 1.30
diff -u -r1.30 GapContent.java
--- javax/swing/text/GapContent.java 5 Oct 2005 15:19:47 - 1.30
+++ javax/swing/text/GapContent.java 5 Oct 2005 20:17:59 -
@@ -41,6 +41,7 @@
import java.io.Serializable;
import java.util.ArrayList;
import java.util.Collections;
+import java.util.Iterator;
import java.util.ListIterator;
import java.util.Vector;
@@ -457,7 +458,6 @@
if (index 0)
index = -(index + 1);
positions.add(index, pos);
-
return pos;
}
@@ -675,18 +675,14 @@
int index1 = Collections.binarySearch(positions,
new GapContentPosition(offset));
-int index2 = Collections.binarySearch(positions,
- new GapContentPosition(endOffset));
if (index1 0)
index1 = -(index1 + 1);
-if (index2 0)
- index2 = -(index2 + 1);
for (ListIterator i = positions.listIterator(index1); i.hasNext();)
{
-if (i.nextIndex() index2)
+GapContentPosition p = (GapContentPosition) i.next();
+if (p.mark endOffset)
break;
-GapContentPosition p = (GapContentPosition) i.next();
if (p.mark = offset p.mark = endOffset)
p.mark = value;
}
@@ -707,18 +703,14 @@
int index1 = Collections.binarySearch(positions,
new GapContentPosition(offset));
-int index2 = Collections.binarySearch(positions,
- new GapContentPosition(endOffset));
if (index1 0)
index1 = -(index1 + 1);
-if (index2 0)
- index2 = -(index2 + 1);
for (ListIterator i = positions.listIterator(index1); i.hasNext();)
{
-if (i.nextIndex() index2)
- break;
-
GapContentPosition p = (GapContentPosition) i.next();
+if (p.mark endOffset)
+ break;
+
if (p.mark = offset p.mark = endOffset)
p.mark += incr;
}
@@ -736,5 +728,40 @@
return;
setPositionsInRange(gapEnd, 0, 0);
+ }
+
+ /**
+ * Outputs debugging info to System.err. It prints out the buffer array,
+ * the gapStart is marked by a lt; sign, the gapEnd is marked by a gt;
+ * sign and each position is marked by a # sign.
+ */
+ private void dump()
+ {
+System.err.println(GapContent debug information);
+System.err.println(buffer length: + buffer.length);
+System.err.println(gap start: + gapStart);
+System.err.println(gap end: + gapEnd);
+for (int i = 0; i buffer.length; i++)
+ {
+if (i == gapStart)
+ System.err.print('');
+if (i == gapEnd)
+ System.err.print('');
+
+if (!Character.isISOControl(buffer[i]))
+ System.err.print(buffer[i]);
+else
+ System.err.print('.');
+ }
+System.err.println();
+ }
+
+ private void dumpPositions()
+ {
+for (Iterator i = positions.iterator(); i.hasNext();)
+ {
+GapContentPosition pos = (GapContentPosition) i.next();
+System.err.println(position at: + pos.mark);
+ }
}
}___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] RFC: runtime exceptions thrown in AccessController
Hi Nicolas,
On Wed, 2005-10-05 at 18:23 +0200, Nicolas Geoffray wrote:
I changed implementation of AccessController.doPrivileged methods that
hava a PrivilegedExceptionAction argument. When a runtime exception is
catched, it throws it, and doesn't wrap it in a
PrivilegedExceptionAction object.
I'm new in committing. Should I get a write access to the cvs?
Thanks. I wrote a mauve test for it to check that the problem was really
solved. And updated the documentation.
Committed as follows:
2005-10-05 Mark Wielaard [EMAIL PROTECTED]
Reported by Nicolas Geoffray [EMAIL PROTECTED]
* java/security/AccessController.java
(doPrivileged(PrivilegedExceptionAction)): If the Exception is a
Runtime exception, then throw the exception directly, otherwise
wrap it.
(doPrivileged(PrivilegedExceptionAction,AccessControlContext)):
Likewise.
For these kind of small, obviously correct patches we can just check
them in. If you want to contribute larger patches please read:
http://www.gnu.org/software/classpath/docs/hacking.html
Thanks,
Mark
Index: java/security/AccessController.java
===
RCS file: /cvsroot/classpath/classpath/java/security/AccessController.java,v
retrieving revision 1.10
diff -u -r1.10 AccessController.java
--- java/security/AccessController.java 2 Jul 2005 20:32:40 - 1.10
+++ java/security/AccessController.java 5 Oct 2005 21:21:20 -
@@ -142,8 +142,8 @@
* @param action the codePrivilegedExceptionAction/code whose
* coderun()/code should be be called.
* @return the result of the codeaction.run()/code method.
- * @exception PrivilegedActionException wrapped around any exception that
- * is thrown in the coderun()/code method.
+ * @exception PrivilegedActionException wrapped around any checked exception
+ * that is thrown in the coderun()/code method.
*/
public static Object doPrivileged(PrivilegedExceptionAction action)
throws PrivilegedActionException
@@ -153,6 +153,10 @@
{
return action.run();
}
+catch (RuntimeException e)
+ {
+ throw e;
+ }
catch (Exception e)
{
throw new PrivilegedActionException(e);
@@ -178,8 +182,8 @@
* @param context the codeAccessControlContext/code whose protection
* domains should be added to the protection domain of the calling class.
* @return the result of the codeaction.run()/code method.
- * @exception PrivilegedActionException wrapped around any exception that
- * is thrown in the coderun()/code method.
+ * @exception PrivilegedActionException wrapped around any checked exception
+ * that is thrown in the coderun()/code method.
*/
public static Object doPrivileged(PrivilegedExceptionAction action,
AccessControlContext context)
@@ -189,6 +193,10 @@
try
{
return action.run();
+ }
+catch (RuntimeException e)
+ {
+ throw e;
}
catch (Exception e)
{
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]: Patch: JTree fix
Fixed up BasicTreeUI because it was not efficent when painting.
2005-10-05 Lillian Angel [EMAIL PROTECTED]
* javax/swing/plaf/metal/MetalTreeUI.java
(installUI): Fixed to call toggleExpandState instead.
* javax/swing/plaf/basic/BasicTreeUI.java
(getPathForRow): Used currentVisiblePath to get Path.
(getRowForPath): Used currentVisiblePath to get row.
(getRowCount): Returned currentVisiblePath length.
(updateLayoutCacheExpandedNodes): Took out unneeded code.
(installUI): Fixed to call toggleExpandState instead.
(getPreferredSize): Made more efficent by using
currentVisiblePath.
(toggleExpandState): Called updateCurrentVisiblePath.
(getCellLocation): Made more efficent.
(paintNode): Removed.
(paintRecursive): Made more efficent, changed paintNode calls to
paintRow.
(getNextVisibleNode): Reimplemented to use currentVisiblePath.
(getPreviousVisibleNode): Likewise.
(paintRow): Implemented.
(updateCurrentVisiblePath): New helper used to cache the current
visible path.
Index: javax/swing/plaf/basic/BasicTreeUI.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/plaf/basic/BasicTreeUI.java,v
retrieving revision 1.84
diff -u -r1.84 BasicTreeUI.java
--- javax/swing/plaf/basic/BasicTreeUI.java 29 Sep 2005 22:51:34 - 1.84
+++ javax/swing/plaf/basic/BasicTreeUI.java 5 Oct 2005 21:18:46 -
@@ -242,6 +242,9 @@
/** The bounds of the current cell. */
Rectangle bounds;
+
+ /** The current path of the visible nodes in the tree. */
+ TreePath currentVisiblePath;
/** Listeners */
private PropertyChangeListener propertyChangeListener;
@@ -648,18 +651,9 @@
{
if (treeModel != null)
{
-Object node = treeModel.getRoot();
-if (!tree.isRootVisible()
- tree.isExpanded(new TreePath(getPathToRoot(node, 0
- node = getNextNode(node);
-
-for (int i = 0; i row; i++)
- node = getNextVisibleNode(node);
-
-if (node == null)
- return null;
-
-return new TreePath(getPathToRoot(node, 0));
+Object[] nodes = currentVisiblePath.getPath();
+if (row nodes.length)
+ return new TreePath(getPathToRoot(nodes[row], 0));
}
return null;
}
@@ -680,13 +674,16 @@
{
int row = 0;
Object dest = path.getLastPathComponent();
-Object curr = treeModel.getRoot();
-while (curr != null !curr.equals(dest))
- {
-++row;
-curr = getNextVisibleNode(curr);
+int rowCount = getRowCount(tree);
+Object[] nodes = currentVisiblePath.getPath();
+while (row rowCount)
+ {
+if (dest.equals(nodes[row]))
+ return row;
+row++;
}
-return row;
+
+return -1;
}
/**
@@ -698,21 +695,7 @@
*/
public int getRowCount(JTree tree)
{
-int count = 0;
-if (treeModel != null)
- {
-Object node = treeModel.getRoot();
-if (!tree.isRootVisible()
- tree.isExpanded(new TreePath((getPathToRoot(node, 0)
- node = getNextNode(node);
-
-while (node != null)
- {
-count++;
-node = getNextVisibleNode(node);
- }
- }
-return count;
+return currentVisiblePath.getPathCount();
}
/**
@@ -1087,8 +1070,7 @@
protected void updateLayoutCacheExpandedNodes()
{
if (treeModel != null)
- updateExpandedDescendants(new TreePath(getPathToRoot(treeModel.
- getRoot(), 0)));
+ updateExpandedDescendants(new TreePath(treeModel.getRoot()));
}
/**
@@ -1340,7 +1322,11 @@
TreeModel mod = tree.getModel();
setModel(mod);
if (mod != null)
- tree.expandPath(new TreePath(mod.getRoot()));
+ {
+TreePath path = new TreePath(mod.getRoot());
+if (!tree.isExpanded(path))
+ toggleExpandState(path);
+ }
treeSelectionModel = tree.getSelectionModel();
installKeyboardActions();
@@ -1482,25 +1466,11 @@
{
// FIXME: checkConsistancy not implemented, c not used
int maxWidth = 0;
-int count = 0;
-if (treeModel != null)
- {
-Object node = treeModel.getRoot();
-if (node != null)
- {
-maxWidth = (int) (getCellBounds(0, 0, node).getWidth());
-while (node != null)
- {
-count++;
-Object nextNode = getNextVisibleNode(node);
-if (nextNode != null)
- maxWidth = Math.max(maxWidth,
- (int) (getCellBounds(0, 0, nextNode).getWidth()));
-node = nextNode;
- }
- }
- }
-return new Dimension(maxWidth, (getRowHeight() * count));
+Object[] path
Re: [cp-patches]: FYI: JTree fix
Small fix. Added in a comment as a reminder to fix last bit of painting problem. 2005-10-05 Lillian Angel [EMAIL PROTECTED] * javax/swing/plaf/basic/BasicTreeUI.java (paintRow): Fixed indentation. (updateCurrentVisiblePath): Added FIXME comment. On Wed, 2005-10-05 at 17:28 -0400, Lillian Angel wrote: Fixed up BasicTreeUI because it was not efficent when painting. 2005-10-05 Lillian Angel [EMAIL PROTECTED] * javax/swing/plaf/metal/MetalTreeUI.java (installUI): Fixed to call toggleExpandState instead. * javax/swing/plaf/basic/BasicTreeUI.java (getPathForRow): Used currentVisiblePath to get Path. (getRowForPath): Used currentVisiblePath to get row. (getRowCount): Returned currentVisiblePath length. (updateLayoutCacheExpandedNodes): Took out unneeded code. (installUI): Fixed to call toggleExpandState instead. (getPreferredSize): Made more efficent by using currentVisiblePath. (toggleExpandState): Called updateCurrentVisiblePath. (getCellLocation): Made more efficent. (paintNode): Removed. (paintRecursive): Made more efficent, changed paintNode calls to paintRow. (getNextVisibleNode): Reimplemented to use currentVisiblePath. (getPreviousVisibleNode): Likewise. (paintRow): Implemented. (updateCurrentVisiblePath): New helper used to cache the current visible path. ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches Index: javax/swing/plaf/basic/BasicTreeUI.java === RCS file: /cvsroot/classpath/classpath/javax/swing/plaf/basic/BasicTreeUI.java,v retrieving revision 1.85 diff -u -r1.85 BasicTreeUI.java --- javax/swing/plaf/basic/BasicTreeUI.java 5 Oct 2005 21:29:18 - 1.85 +++ javax/swing/plaf/basic/BasicTreeUI.java 5 Oct 2005 21:48:22 - @@ -3144,7 +3144,8 @@ if (!mod.isLeaf(node)) max = mod.getChildCount(node); - if (!node.equals(mod.getRoot())) + if (!node.equals(mod.getRoot()) + (tree.isRootVisible() || getLevel(node) != 1)) icon.paintIcon(tree, g, indentation - rightChildIndent - 3, h); if (tree.isExpanded(path)) @@ -3691,7 +3692,9 @@ current = current.pathByAddingChild(next); else current = new TreePath(next); - + +// FIXME: Inefficent to have 2 loops when the +// tree is very large. Find a better way. do next = getNextNode(next); while (next != null ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] FYI: some styled text fixes
I have tested my styled text testapp again and found that it was broken.
Here comes the fix. Mainly I changed BoxView to completely use the
SizeRequirements utility methods. Also, since these methods now work
correctly, I also had to tweak some alignment properties of related views.
Now the app at least shows up again. It still needs some tweaks though to
be usable.
Also included are some missing methods for the BoxView thingy.
2005-10-05 Roman Kennke [EMAIL PROTECTED]
* javax/swing/text/BoxView.java
(baselineLayout): New method.
(calculateMajorAxisRequirements): Reimplemented to use the
SizeRequirements utility methods.
(calculateMinorAxisRequirements): Reimplemented to use the
SizeRequirements utility methods.
(layout): Use the new baselineLayout method.
(layoutMajorAxis): Reimplemented to use the new
getChildRequirements method.
(layoutMinorAxis): Reimplemented to use the new
getChildRequirements method.
(getChildRequirements): New method.
(getSpan): New method.
(getOffset): New method.
(getAlignment): New method.
* javax/swing/text/ParagraphView.java
(Row.getAlignment): New method.
(getAlignment): New method.
* javax/swing/text/View.java
(getContainer): Improved error message in assertion a little.
/Roman
Index: javax/swing/text/BoxView.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/text/BoxView.java,v
retrieving revision 1.4
diff -u -r1.4 BoxView.java
--- javax/swing/text/BoxView.java 13 Sep 2005 23:44:49 - 1.4
+++ javax/swing/text/BoxView.java 5 Oct 2005 21:45:57 -
@@ -295,7 +295,6 @@
{
// Adjust size if the size is changed.
Rectangle bounds = a.getBounds();
-
if (bounds.width != getWidth() || bounds.height != getHeight())
setSize(bounds.width, bounds.height);
@@ -357,6 +356,24 @@
}
/**
+ * Calculates the layout of the children of this codeBoxView/code along
+ * the specified axis.
+ *
+ * @param span the target span
+ * @param axis the axis that is examined
+ * @param offsets an empty array, filled with the offsets of the children
+ * @param spans an empty array, filled with the spans of the children
+ */
+ protected void baselineLayout(int span, int axis, int[] offsets,
+int[] spans)
+ {
+if (axis == myAxis)
+ layoutMajorAxis(span, axis, offsets, spans);
+else
+ layoutMinorAxis(span, axis, offsets, spans);
+ }
+
+ /**
* Calculates the size requirements of this codeBoxView/code along
* its major axis, that is the axis specified in the constructor.
*
@@ -370,27 +387,8 @@
protected SizeRequirements calculateMajorAxisRequirements(int axis,
SizeRequirements sr)
{
-if (sr == null)
- sr = new SizeRequirements();
-else
- {
-sr.maximum = 0;
-sr.minimum = 0;
-sr.preferred = 0;
-sr.alignment = 0.5F;
- }
-
-int count = getViewCount();
-
-// Sum up the sizes of the children along the specified axis.
-for (int i = 0; i count; ++i)
- {
-View child = getView(i);
-sr.minimum += child.getMinimumSpan(axis);
-sr.preferred += child.getPreferredSpan(axis);
-sr.maximum += child.getMaximumSpan(axis);
- }
-return sr;
+SizeRequirements[] childReqs = getChildRequirements(axis);
+return SizeRequirements.getTiledSizeRequirements(childReqs);
}
/**
@@ -408,48 +406,8 @@
protected SizeRequirements calculateMinorAxisRequirements(int axis,
SizeRequirements sr)
{
-if (sr == null)
- sr = new SizeRequirements();
-else
- {
-sr.maximum = 0;
-sr.minimum = 0;
-sr.preferred = 0;
-sr.alignment = 0.5F;
- }
-
-int count = getViewCount();
-
-int aboveBaseline = 0;
-int belowBaseline = 0;
-int aboveBaselineMin = 0;
-int belowBaselineMin = 0;
-int aboveBaselineMax = 0;
-int belowBaselineMax = 0;
-
-for (int i = 0; i count; ++i)
- {
-View child = getView(i);
-float align = child.getAlignment(axis);
-int pref = (int) child.getPreferredSpan(axis);
-int min = (int) child.getMinimumSpan(axis);
-int max = (int) child.getMaximumSpan(axis);
-aboveBaseline += (int) (align * pref);
-belowBaseline += (int) ((1.F - align) * pref);
-aboveBaselineMin += (int) (align * min);
-belowBaselineMin += (int) ((1.F - align) * min);
-aboveBaselineMax += (int) (align * max);
-belowBaselineMax += (int) ((1.F - align) * max);
- }
-sr.minimum = aboveBaselineMin + belowBaselineMin;
-sr.maximum = aboveBaselineMax + belowBaselineMax;
-sr.preferred =
Re: [cp-patches] QT4 configury bits for OS-X
Hi Andreas, On Tue, 2005-09-27 at 20:57 +0200, Andreas Tobler wrote: I tested this patch on ppclinux, sparc solaris10 and ppc-darwin8.2 with positive and negative configs. I hope I catched all. Comments welcome. 2005-09-27 Andreas Tobler [EMAIL PROTECTED] * configure.ac: Add Qt4 configury bits for OS-X. Looks fine to me. Although it seems this is for all Darwin systems, not just OS-X. It also still works for me. So please check it in. 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] [generics] Patch: FYI: genericize some methods
I'm checking this in on the generics branch.
This genericizes a bunch of methods from AWT and Swing.
Tom
2005-10-05 Tom Tromey [EMAIL PROTECTED]
* javax/swing/tree/DefaultTreeSelectionModel.java (getListeners):
Genericized.
* javax/swing/tree/DefaultTreeModel.java (getListeners): Genericized.
* javax/swing/Timer.java (getListeners): Genericized.
* javax/swing/text/StyleContext.java (getListeners): Genericized.
* javax/swing/text/DefaultCaret.java (getListeners): Genericized.
* javax/swing/text/AbstractDocument.java (getListeners):
Genericized.
* javax/swing/table/DefaultTableColumnModel.java (getListeners):
Genericized.
* javax/swing/table/AbstractTableModel.java (getListeners):
Genericized.
* javax/swing/JComponent.java (getListeners): Genericized.
* javax/swing/DefaultSingleSelectionModel.java (getListeners):
Genericized.
* javax/swing/DefaultListSelectionModel.java (getListeners):
Genericized.
* javax/swing/DefaultButtonModel.java (getListeners): Genericized.
* javax/swing/DefaultBoundedRangeModel.java (getListeners):
Genericized.
* javax/swing/AbstractSpinnerModel.java (getListeners): Genericized.
* javax/swing/event/EventListenerList.java (add): Genericized.
(getListeners): Likewise.
(remove): Likewise.
* java/awt/dnd/DragSource.java (getListeners): Genericized.
* java/awt/TextField.java (getListeners): Genericized.
* java/awt/Window.java (getListeners): Genericized.
* java/awt/Scrollbar.java (getListeners): Genericized.
* java/awt/List.java (getListeners): Genericized.
* java/awt/Choice.java (getListeners): Genericized.
* java/awt/TextComponent.java (getListeners): Genericized.
* java/awt/CheckboxMenuItem.java (getListeners): Genericized.
* java/awt/Button.java (getListeners): Genericized.
* java/awt/Container.java (getListeners): Genericized.
Index: java/awt/Button.java
===
RCS file: /cvsroot/classpath/classpath/java/awt/Button.java,v
retrieving revision 1.13.2.9
diff -u -r1.13.2.9 Button.java
--- java/awt/Button.java20 Sep 2005 18:46:25 - 1.13.2.9
+++ java/awt/Button.java6 Oct 2005 00:29:30 -
@@ -352,11 +352,11 @@
*
* @since 1.3
*/
- public EventListener[] getListeners(Class listenerType)
+ public T extends EventListener T[] getListeners(ClassT listenerType)
{
if (listenerType == ActionListener.class)
- return getActionListeners();
-return (EventListener[]) Array.newInstance(listenerType, 0);
+ return (T[]) getActionListeners();
+return (T[]) Array.newInstance(listenerType, 0);
}
/*/
Index: java/awt/CheckboxMenuItem.java
===
RCS file: /cvsroot/classpath/classpath/java/awt/CheckboxMenuItem.java,v
retrieving revision 1.12.2.7
diff -u -r1.12.2.7 CheckboxMenuItem.java
--- java/awt/CheckboxMenuItem.java 20 Sep 2005 18:46:25 - 1.12.2.7
+++ java/awt/CheckboxMenuItem.java 6 Oct 2005 00:29:30 -
@@ -313,11 +313,11 @@
* @exception ClassCastException If listenerType doesn't specify a class or
* interface that implements java.util.EventListener.
*/
- public EventListener[] getListeners (Class listenerType)
+ public T extends EventListener T[] getListeners (ClassT listenerType)
{
if (listenerType == ItemListener.class)
return AWTEventMulticaster.getListeners (item_listeners, listenerType);
-
+
return super.getListeners (listenerType);
}
Index: java/awt/Choice.java
===
RCS file: /cvsroot/classpath/classpath/java/awt/Choice.java,v
retrieving revision 1.15.2.6
diff -u -r1.15.2.6 Choice.java
--- java/awt/Choice.java2 Aug 2005 20:12:14 - 1.15.2.6
+++ java/awt/Choice.java6 Oct 2005 00:29:30 -
@@ -604,11 +604,11 @@
*
* @since 1.3
*/
- public EventListener[] getListeners (Class listenerType)
+ public T extends EventListener T[] getListeners (ClassT listenerType)
{
if (listenerType == ItemListener.class)
return AWTEventMulticaster.getListeners (item_listeners, listenerType);
-
+
return super.getListeners (listenerType);
}
Index: java/awt/Container.java
===
RCS file: /cvsroot/classpath/classpath/java/awt/Container.java,v
retrieving revision 1.37.2.15
diff -u -r1.37.2.15 Container.java
--- java/awt/Container.java 20 Sep 2005 18:46:25 - 1.37.2.15
+++ java/awt/Container.java 6 Oct 2005 00:29:31 -
@@ -884,10 +884,10 @@
*
* @since 1.3
*/
- public EventListener[] getListeners(Class
[cp-patches] [generics] Patch: FYI: japi bug in java.util.zip
I'm checking this in on the generics branch.
This fixes a java.util.zip buglet pointed out by japi.
Tom
2005-10-05 Tom Tromey [EMAIL PROTECTED]
* java/util/zip/ZipFile.java (entries): Fixed return type.
Index: java/util/zip/ZipFile.java
===
RCS file: /cvsroot/classpath/classpath/java/util/zip/ZipFile.java,v
retrieving revision 1.16.2.8
diff -u -r1.16.2.8 ZipFile.java
--- java/util/zip/ZipFile.java 27 Sep 2005 16:52:59 - 1.16.2.8
+++ java/util/zip/ZipFile.java 6 Oct 2005 00:39:58 -
@@ -368,7 +368,7 @@
*
* @exception IllegalStateException when the ZipFile has already been closed
*/
- public EnumerationZipEntry entries()
+ public Enumeration? extends ZipEntry entries()
{
checkClosed();
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] Patch: FYI: generics in java.util.prefs
I'm checking this in on the generics branch.
This genericizes a couple of methods in java.util.prefs.
Tom
2005-10-05 Tom Tromey [EMAIL PROTECTED]
* java/util/prefs/Preferences.java (systemNodeForPackage): Genericized.
(userNodeForPackage): Likewise.
Index: java/util/prefs/Preferences.java
===
RCS file: /cvsroot/classpath/classpath/java/util/prefs/Preferences.java,v
retrieving revision 1.8.2.4
diff -u -r1.8.2.4 Preferences.java
--- java/util/prefs/Preferences.java20 Sep 2005 18:46:30 - 1.8.2.4
+++ java/util/prefs/Preferences.java6 Oct 2005 00:37:00 -
@@ -242,7 +242,7 @@
* @exception SecurityException when a security manager is installed and
* the caller does not have codeRuntimePermission(preferences)/code.
*/
-public static Preferences systemNodeForPackage(Class c)
+public static Preferences systemNodeForPackage(Class? c)
throws SecurityException
{
return nodeForPackage(c, systemRoot());
@@ -261,7 +261,7 @@
* @exception SecurityException when a security manager is installed and
* the caller does not have codeRuntimePermission(preferences)/code.
*/
-public static Preferences userNodeForPackage(Class c)
+public static Preferences userNodeForPackage(Class? c)
throws SecurityException
{
return nodeForPackage(c, userRoot());
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] [generics] Patch: FYI: datatransfer -vs- generics
I'm checking this in on the gcjx branch.
This fixes some generics-related bugs in datatransfer pointed out by
japi.
Tom
2005-10-05 Tom Tromey [EMAIL PROTECTED]
* java/awt/datatransfer/SystemFlavorMap.java (getNativesForFlavors):
Genericized.
(getFlavorsForNatives): Likewise.
(getFlavorsForNative): Likewise.
(getNativesForFlavor): Likewise.
* java/awt/datatransfer/DataFlavor.java (DataFlavor): Genericized.
(getDefaultRepresentationClass): Likewise.
(getRepresentationClass): Likewise.
(tryToLoadClass): Likewise.
(representationClass): Likewise.
* java/awt/datatransfer/FlavorTable.java (getNativesForFlavor):
Genericized.
(getFlavorsForNative): Likewise.
* java/awt/datatransfer/FlavorMap.java (getFlavorsForNatives):
Genericized.
(getNativesForFlavors): Likewise.
Index: java/awt/datatransfer/DataFlavor.java
===
RCS file: /cvsroot/classpath/classpath/java/awt/datatransfer/DataFlavor.java,v
retrieving revision 1.20.2.4
diff -u -r1.20.2.4 DataFlavor.java
--- java/awt/datatransfer/DataFlavor.java 7 Aug 2005 18:34:10 -
1.20.2.4
+++ java/awt/datatransfer/DataFlavor.java 6 Oct 2005 00:57:40 -
@@ -146,7 +146,7 @@
private final String mimeType;
// The representation class for this flavor
-private final Class representationClass;
+private final Class? representationClass;
// The human readable name of this flavor
private String humanPresentableName;
@@ -169,7 +169,7 @@
*
* @exception ClassNotFoundException If the class cannot be loaded.
*/
-protected static final Class
+protected static final Class?
tryToLoadClass(String className, ClassLoader classLoader)
throws ClassNotFoundException
{
@@ -256,7 +256,7 @@
* @param humanPresentableName The display name of the object.
*/
public
-DataFlavor(Class representationClass, String humanPresentableName)
+DataFlavor(Class? representationClass, String humanPresentableName)
{
this(representationClass,
application/x-java-serialized-object
@@ -381,7 +381,7 @@
*
* @return The representation class for this flavor.
*/
-public Class
+public Class?
getRepresentationClass()
{
return(representationClass);
@@ -885,7 +885,7 @@
*
* @since 1.3
*/
-public final Class
+public final Class?
getDefaultRepresentationClass()
{
return(java.io.InputStream.class);
Index: java/awt/datatransfer/FlavorMap.java
===
RCS file: /cvsroot/classpath/classpath/java/awt/datatransfer/FlavorMap.java,v
retrieving revision 1.7.2.1
diff -u -r1.7.2.1 FlavorMap.java
--- java/awt/datatransfer/FlavorMap.java2 Aug 2005 20:12:15 -
1.7.2.1
+++ java/awt/datatransfer/FlavorMap.java6 Oct 2005 00:57:40 -
@@ -58,7 +58,7 @@
*
* @return A codeMap/code of native data types.
*/
- Map getNativesForFlavors (DataFlavor[] flavors);
+ MapDataFlavor, String getNativesForFlavors (DataFlavor[] flavors);
/**
* Maps the specified native type names to codeDataFlavor/code's.
@@ -71,5 +71,5 @@
*
* @return A codeMap/code of data flavors.
*/
- Map getFlavorsForNatives (String[] natives);
+ MapString, DataFlavor getFlavorsForNatives (String[] natives);
}
Index: java/awt/datatransfer/FlavorTable.java
===
RCS file: /cvsroot/classpath/classpath/java/awt/datatransfer/FlavorTable.java,v
retrieving revision 1.1.2.3
diff -u -r1.1.2.3 FlavorTable.java
--- java/awt/datatransfer/FlavorTable.java 2 Aug 2005 20:12:15 -
1.1.2.3
+++ java/awt/datatransfer/FlavorTable.java 6 Oct 2005 00:57:40 -
@@ -59,7 +59,7 @@
* @param flavor the flavor to look up, or null to return all natives
* @return the sorted list of natives
*/
- List getNativesForFlavor(DataFlavor flavor);
+ ListString getNativesForFlavor(DataFlavor flavor);
/**
* Returns a list of flavors corresponding to the given String native. The
@@ -69,5 +69,5 @@
* @param name the native name to look up, or null to return all flavors
* @return the sorted list of flavors
*/
- List getFlavorsForNative(String name);
+ ListDataFlavor getFlavorsForNative(String name);
}
Index: java/awt/datatransfer/SystemFlavorMap.java
===
RCS file:
/cvsroot/classpath/classpath/java/awt/datatransfer/SystemFlavorMap.java,v
retrieving revision 1.4.2.2
diff -u -r1.4.2.2 SystemFlavorMap.java
--- java/awt/datatransfer/SystemFlavorMap.java 2 Aug 2005 20:12:15 -
1.4.2.2
+++ java/awt/datatransfer/SystemFlavorMap.java 6 Oct 2005 00:57:40 -
@@ -76,9 +76,9 @@
*
* @return A codeMap/code of native data types to data flavors.
*/
- public Map getNativesForFlavors (DataFlavor[] flavors)
+ public MapDataFlavor,
[cp-patches] [generics] Patch: FYI: java.util.jar -vs- generics
I'm checking this in on the generics branch.
This fixes the generics-related problems in java.util.jar as pointed
out by japi.
Tom
2005-10-05 Tom Tromey [EMAIL PROTECTED]
* java/util/jar/Attributes.java: Implements MapObject,Object.
(map): Changed type.
(entrySet): Changed return type.
(keySet): Likewise.
(putAll): Changed argument type.
(values): Changed return type.
* java/util/jar/Manifest.java (getEntries): Genericized.
(Manifest): Updated.
(entries): Changed type.
(read_individual_sections): Updated.
(read_section_name): Likewise.
(write_main_attributes): Likewise.
(write_attribute_entry): Likewise.
(write_individual_sections): Likewise.
(write_entry_attributes): Likewise.
* java/util/jar/JarFile.java (entries): Genericized.
(JarEnumeration): Implements EnumerationJarEntry.
(JarEnumeration.nextElement): Changed return type.
(JarEnumeration.entries): Changed type.
Index: java/util/jar/Attributes.java
===
RCS file: /cvsroot/classpath/classpath/java/util/jar/Attributes.java,v
retrieving revision 1.9.2.3
diff -u -r1.9.2.3 Attributes.java
--- java/util/jar/Attributes.java 2 Aug 2005 20:12:31 - 1.9.2.3
+++ java/util/jar/Attributes.java 6 Oct 2005 02:57:51 -
@@ -65,7 +65,7 @@
* @see java.util.jar.Attributes.Name
* @author Mark Wielaard ([EMAIL PROTECTED])
*/
-public class Attributes implements Cloneable, Map
+public class Attributes implements Cloneable, MapObject, Object
{
// Fields
@@ -75,7 +75,7 @@
* implementation it is actually a Hashtable, but that can be different in
* other implementations.
*/
- protected Map map;
+ protected MapObject, Object map;
// Inner class
@@ -493,7 +493,7 @@
*
* @return a set of attribute name value pairs
*/
- public Set entrySet()
+ public SetMap.EntryObject, Object entrySet()
{
return map.entrySet();
}
@@ -559,7 +559,7 @@
/**
* Gives a Set of all the values of defined attribute names.
*/
- public Set keySet()
+ public SetObject keySet()
{
return map.keySet();
}
@@ -588,7 +588,7 @@
* @exception ClassCastException if the supplied map is not an instance of
* Attributes
*/
- public void putAll(Map attr)
+ public void putAll(Map?, ? attr)
{
if (!(attr instanceof Attributes))
{
@@ -623,7 +623,7 @@
* Returns all the values of the defined attribute name/value pairs as a
* Collection.
*/
- public Collection values()
+ public CollectionObject values()
{
return map.values();
}
Index: java/util/jar/JarFile.java
===
RCS file: /cvsroot/classpath/classpath/java/util/jar/JarFile.java,v
retrieving revision 1.10.2.5
diff -u -r1.10.2.5 JarFile.java
--- java/util/jar/JarFile.java 10 Sep 2005 15:31:47 - 1.10.2.5
+++ java/util/jar/JarFile.java 6 Oct 2005 02:57:52 -
@@ -304,7 +304,7 @@
*
* @exception IllegalStateException when the JarFile is already closed
*/
- public Enumeration entries() throws IllegalStateException
+ public EnumerationJarEntry entries() throws IllegalStateException
{
return new JarEnumeration(super.entries(), this);
}
@@ -313,13 +313,13 @@
* Wraps a given Zip Entries Enumeration. For every zip entry a
* JarEntry is created and the corresponding Attributes are looked up.
*/
- private static class JarEnumeration implements Enumeration
+ private static class JarEnumeration implements EnumerationJarEntry
{
-private final Enumeration entries;
+private final Enumeration? extends ZipEntry entries;
private final JarFile jarfile;
-JarEnumeration(Enumeration e, JarFile f)
+JarEnumeration(Enumeration? extends ZipEntry e, JarFile f)
{
entries = e;
jarfile = f;
@@ -330,7 +330,7 @@
return entries.hasMoreElements();
}
-public Object nextElement()
+public JarEntry nextElement()
{
ZipEntry zip = (ZipEntry) entries.nextElement();
JarEntry jar = new JarEntry(zip);
Index: java/util/jar/Manifest.java
===
RCS file: /cvsroot/classpath/classpath/java/util/jar/Manifest.java,v
retrieving revision 1.8.2.2
diff -u -r1.8.2.2 Manifest.java
--- java/util/jar/Manifest.java 20 Sep 2005 18:46:30 - 1.8.2.2
+++ java/util/jar/Manifest.java 6 Oct 2005 02:57:52 -
@@ -64,7 +64,7 @@
private final Attributes mainAttr;
/** A map of atrributes for all entries described in this Manifest. */
- private final Map entries;
+ private final MapString, Attributes entries;
// Constructors
@@ -74,7 +74,7 @@
public Manifest()
{
mainAttr = new Attributes();
-entries = new Hashtable();
+entries = new HashtableString, Attributes();
}
Re: RFC: add --enable-libjava-build option
On Tue, 2005-10-04 at 06:57 +0200, Andreas Tobler wrote: as mentioned by Mark and Tom, this should be discussed on the list. When we build classpath inside libgcj we 'need' some gcc specific bits to build qt-peers for example. Other areas might benefit too. To build c++ stuff we need the just bootstrapped g++, its include its libraries. To make these known to the classpath machinery it would be good to have the option mentionend in the subject. Then we can add the includes and the library to the QT_CFLAGS/QT_LIBS with simply cheking for ENABLE_LIBJAVA_BUILD=yes and add them. (We would have to extend the configury to check for this later, yes) So far I see no possibility to pass them down from libjava build into classpath build without the option below. What are your comments, thoughts on this? Is there a better possibility? I am a bit afraid having such a --enable-libjava-build will mean that lots and lots of tiny hacks are introduced all over the place especially for the integrating inside gcc case. Which is important. But we have other projects also integrating classpath. And hopefully we can share the integration workarounds with such project, such as kaffe. So I am much more in favor of introducing generic solutions for the individual problems instead of one catch all configure flag. Could you post your solution for the above QT_CFLAGS/QT_LIBS check using this ENABLE_LIBJAVA_BUILD? Then we can see if the solution as a whole can be made generic. 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
Re: japi and protected field declaring classes
Hi Stuart, On Tue, 2005-10-04 at 13:22 -0400, Stuart Ballard wrote: It appears that Sun have a field numBands in java.awt.image that's exactly like Implementation 2 above (declared in both ComponentSampleModel and SampleModel), except that it's protected. (someone fixed classpath to conform to this, gmane isn't helping me find out who actually did it right now though). You are looking for the following thread by the two Toms: http://lists.gnu.org/archive/html/classpath-patches/2005-10/msg7.html If it really doesn't matter, I'm sorry to the person who made the awt.image fix based on this misinformation out of japi... :( Changing things just because japi doesn't give a full green bar is wrong to start with anyway. Japi can contain bugs. And it doesn't tell you anything about the why. In the end the why is much more important. As is getting real programs to work with our library and you do that by studying what they actually need our library to provide, not just by going through a list of names and constants. I do hope someone packages japitools for Debian so that it can be used easily by the packagers. Running japi on two versions of a library written in java will be a real help to actually see if an upgrade might break applications depending on it. It was one of the complaints the packagers had about a lot of libraries out there. Lots of libraries actually break binary or source compatibility between minor releases. Japi could really help people not to make such mistakes between releases. 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
Re: japi and public references to non-public types
Hi, On Tue, 2005-10-04 at 13:05 -0400, Stuart Ballard wrote: I'm wondering if it would be better for Japitools to catch this kind of situation and treat the impl field as if it's package-private itself - that is, ignore it entirely since japi only deals with public and protected members. I can't think of any reasons why any such field (or a method taking a non-public type as a parameter or returning one) should ever matter in practice for compatibility, but I'd like to see if other people feel the same way before trying to implement skipping them. This looks like something the compiler should warn against public/protected field/return with package/private type (inner classes could be private). Tom are you taking notes for gcjx? I think japi should also warn against it not hide it, except when explicitly told to. 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
[Bug awt/24211] New: Another Graphics2D segfault
With Graphics2D enabled, one of my test apps dies with the following segfault (classpath cvs head 2005.10.05, jamvm 1.3.2, linux-x86, GTK 2.4, cairo 0.5.1). I have no small testcase yet... does anybody know an open-source application that uses RenderingHints (BILINEAR and ANTIALIASING)? Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 147466 (LWP 16307)] cairo_pattern_set_filter (pattern=0x0, filter=CAIRO_FILTER_FAST) at cairo-pattern.c:489 489 if (pattern-status) (gdb) where #0 cairo_pattern_set_filter (pattern=0x0, filter=CAIRO_FILTER_FAST) at cairo-pattern.c:489 #1 0x4483628c in Java_gnu_java_awt_peer_gtk_GdkGraphics2D_cairoSurfaceSetFilter Unlocked (env=0x8061794, obj=0x4106d7f8, filter=1) at gnu_java_awt_peer_gtk_GdkGraphics2D.c:1965 #2 0x44836330 in Java_gnu_java_awt_peer_gtk_GdkGraphics2D_cairoSurfaceSetFilter (env=0x0, obj=0x0, filter=0) at gnu_java_awt_peer_gtk_GdkGraphics2D.c:1941 #3 0x0805d875 in callJNIMethod (env=0x8061794, class=0x0, sig=0x8070a10 (I)V, ret_type=0, ostack=0x83b0c60, f=0x44836300 U\211åSè|µÿÿ\201ÃK\002\002, args=2) at dll_md.c:64 #4 0x0804e931 in callJNIWrapper (class=0x0, mb=0x82301e4, ostack=0x0) at dll.c:325 #5 0x08051856 in executeJava () at interp.c:2236 #6 0x0804f557 in executeMethodVaList (ob=Variable ob is not available. ) at execute.c:66 #7 0x0804f5f9 in executeMethodArgs (ob=0x0, class=0x0, mb=0x0) at execute.c:38 #8 0x0805b251 in threadStart (arg=0x839a510) at thread.c:257 #9 0x4002dc60 in pthread_start_thread () from /lib/libpthread.so.0 #10 0x4002dcdf in pthread_start_thread_event () from /lib/libpthread.so.0 #11 0x4018eb77 in clone () from /lib/libc.so.6 -- Summary: Another Graphics2D segfault Product: classpath Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: awt AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hendrich at informatik dot uni-hamburg dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24211 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: RFC: add --enable-libjava-build option
Mark Wielaard wrote:
On Tue, 2005-10-04 at 06:57 +0200, Andreas Tobler wrote:
as mentioned by Mark and Tom, this should be discussed on the list.
When we build classpath inside libgcj we 'need' some gcc specific bits
to build qt-peers for example. Other areas might benefit too.
To build c++ stuff we need the just bootstrapped g++, its include its
libraries. To make these known to the classpath machinery it would be
good to have the option mentionend in the subject.
Then we can add the includes and the library to the QT_CFLAGS/QT_LIBS
with simply cheking for ENABLE_LIBJAVA_BUILD=yes and add them. (We would
have to extend the configury to check for this later, yes)
So far I see no possibility to pass them down from libjava build into
classpath build without the option below.
What are your comments, thoughts on this? Is there a better possibility?
I am a bit afraid having such a --enable-libjava-build will mean that
lots and lots of tiny hacks are introduced all over the place especially
for the integrating inside gcc case. Which is important. But we have
other projects also integrating classpath. And hopefully we can share
the integration workarounds with such project, such as kaffe. So I am
much more in favor of introducing generic solutions for the individual
problems instead of one catch all configure flag.
I have no problem with that. Even better when we can have a generic
approach.
Could you post your solution for the above QT_CFLAGS/QT_LIBS check using
this ENABLE_LIBJAVA_BUILD? Then we can see if the solution as a whole
can be made generic.
This is the snippet I have in cp inside gcc. Basically nothing special.
+ dnl This is a hacky situation. The build compiler needs the flags from
+ dnl the build tree and not from the installation. So we have to set
+ dnl libstc++ bits here.
+ if test x${ENABLE_LIBJAVA_BUILD} = xyes; then
+QT_CFLAGS=$QT_CFLAGS -I../../../../../libstdc++-v3/include
+QT_CFLAGS=$QT_CFLAGS -I../../../../../libstdc++-v3/include/${target}
+QT_CFLAGS=$QT_CFLAGS -I\$(top_srcdir)/../../libstdc++-v3/libsupc++
+QT_LIBS=$QT_LIBS ../../../../../libstdc++-v3/src/libstdc++.la
fi
We may find a better solution here too, but it is done in a similar way
for xlib peers inside gcc/libjava. W/o the above flags passed, build
fails miserably.
Thanks,
Andreas
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
RE: japi and public references to non-public types
Mark Wielaard wrote: This looks like something the compiler should warn against public/protected field/return with package/private type (inner classes could be private). Tom are you taking notes for gcjx? I think japi should also warn against it not hide it, except when explicitly told to. I agree. We're never going to get a 100% score on Japi anyway [1], so hiding this stuff doesn't do any good in my opinion. Regards, Jeroen [1] One example I can think of is the non-constant serialVersionUID fields in some classes (that compute their serialVersionUID based on some runtime setting or such) ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: japi and protected field declaring classes
Hi Mark, hi Stuart, Mark Wielaard wrote: I do hope someone packages japitools for Debian so that it can be used easily by the packagers. Got the message :-) I can have a look. However which version should be packaged. The last available from the website (0.9.5), or is there somewhere a newer one ? Wolfgang ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Has someone experimented with jedit?
Hi guys, A week ago I experimented with jedit on an up-to-date Fedora Core 4 box (I used the included java instruments - the included GNU classpath and gij) The development version 4.3pre2 did not want to start at all, while 4.2 started with way too many warnings for AWT things and way too many artifacts in repainting things - most of the widgets showed only briefly when the mouse cursor was on top of them. My friend with a Debian unstable - with up-to-date classpath (0.18) and gij did not manage to start jedit at all. Are Swing-hackers experimenting with jedit? It is a nice app with many layouts and widgets and it may be a nice test case. Plus - I am using it and hoped I could use it under entirely free java. ;-) Best regards: al_shopov ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Has someone experimented with jedit?
Hi Alexander, Alexander Shopov wrote: Are Swing-hackers experimenting with jedit? I'm not, yet, but I suspect others are. The only real world application I've tested so far is JUnit's TestRunner, which is working but subject to some issues. Here is a screen shot (slightly out of date, the icon alignment on the tabs has been dealt with, for example, as well as the bugs that caused the five test failures): http://www.object-refinery.com/classpath/junit-free.png After I finish my current task (a first pass through implementing the javax.swing.plaf.metal.* package, which is close to 90% API coverage now, with MetalFileChooserUI being the biggest remaining piece of work), I'll start looking at some more real Swing applications. It is a nice app with many layouts and widgets and it may be a nice test case. Absolutely. I expect running JEdit will help to flush out a lot of bugs in our implementation, and getting it working properly will be a *major* milestone. Plus - I am using it and hoped I could use it under entirely free java. ;-) Me too! I encourage you to join in and help make this happen. Regards, Dave Gilbert Best regards: al_shopov ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Has someone experimented with jedit?
Hi, Me and Mark and some other guys have already experimented with JEdit. It is a quite demanding application, so there will be alot to do before it works nicely. The most important missing pieces are: - JEdit depends on Java2D, which is not implemented completely and efficiently so far, and is also not enabled by default. This is very likely the reason why JEdit does not come up on some distros at all: they have Java2D support disabled - JEdit makes heavy use of the javax.swing.text package, which is also very incomplete and buggy. This is currently beeing worked on by me and Tony We (especially Mark) usually test JEdit before making a release, but since this app is not usable at all with Classpath, it is not a showstopper. We focus on fixing Classpath with simpler apps first (like the TestRunner that David mentioned, or the BeanShell JConsole), this will also improve the complex application to a certain degree. Of course it would be nice if you could regularily test JEdit against GNU Classpath (keep in mind, you need a build with Java2D/Cairo enabled) and post results (and/or bugreports). Best regards, Roman signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Has someone experimented with jedit?
Roman Kennke wrote: showstopper. We focus on fixing Classpath with simpler apps first (like the TestRunner that David mentioned, or the BeanShell JConsole), this will also improve the complex application to a certain degree. Pointers to other Free-and-not-overly-complex Swing applications are welcome too. I'm happy to try running a few things and fixing some bugs (at least the easy ones). Regards, Dave ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: japi and protected field declaring classes
On 10/5/05, Wolfgang Baer [EMAIL PROTECTED] wrote: Hi Mark, hi Stuart, Mark Wielaard wrote: I do hope someone packages japitools for Debian so that it can be used easily by the packagers. Got the message :-) I can have a look. Wow, cool :) However which version should be packaged. The last available from the website (0.9.5), or is there somewhere a newer one ? The only newer is CVS currently. I'd like to finish up the remaining issues in 1.5 compatibility (basically full annotation support) and hash out what's the right thing to do with the open issues that are being debated right now before I make another new version. At the current rate of progress that probably won't take long. But it's probably true that the CVS version gives much better results than the released version right now. I'm not sure what to propose, except be aware of the tradeoffs and make whichever decision you think is right for Debian... (btw, if there are changes that you'd like to see in japitools to make it easier to package let me know; I'm more than willing to give CVS access too) Stuart. -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: japi and protected field declaring classes
On 10/5/05, Mark Wielaard [EMAIL PROTECTED] wrote: Changing things just because japi doesn't give a full green bar is wrong to start with anyway. Japi can contain bugs. This statement works two ways. Blindly changing Classpath because japi doesn't give a full green bar is certainly a bad idea and understanding the why is very important indeed. That's why I didn't, for example, submit a patch which added the package-private NameImpl class just so we could get compatibility with the useless impl field in the JDK, but opened up a debate about what japi should do instead. On the other hand I do think it should be possible to get full green for everything in Classpath; in places where that's not currently possible without doing stupid stuff, or requires matching Sun on something that truly is an implementation detail and not part of the public API, I consider that a japi bug, and I'm committed to fixing any such japi bugs that are found. Hence the reason for starting this thread, and several others in the past, about what the right behavior for japitools in particular situations is. By the way, I noticed another situation japitools shouldn't care about declaring location of fields: if the field is final, it can't be modified by any outside code. I've implemented this in my local copy and it will be picked up by tonight's run. But I'd still really like feedback about whether I've missed any cases where it is, or isn't, important. Stuart. -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: japi and public references to non-public types
(oops, forgot to CC the list first try - thanks for catching that, Jeroen) On 10/5/05, Jeroen Frijters [EMAIL PROTECTED] wrote: Mark Wielaard wrote: This looks like something the compiler should warn against public/protected field/return with package/private type (inner classes could be private). I absolutely agree it should be a compiler warning (and as Jeroen's said before, it really should never have been permitted by the language in the first place). Is there a Java equivalent to C#'s FxCop tool? I think japi should also warn against it not hide it, except when explicitly told to. I'm wondering exactly how to do this. You'd want to warn when this happens in Classpath, I think, but not when it happens in the JDK (unless you're actually testing the JDK for compatibility with something). (Currently I believe Classpath only does it for GridBagLayout, but the zip I was testing against was old). Actually, I think an API lint like this is kind of outside the scope of Japitools, or rather, outside the scope of japicompat. Perhaps japilint should be a separate tool sharing a lot of code with Japize... any volunteers to write it? :) Obvious things to catch: - This one: accessibility of class / method / field greater than accessibility of its type or arguments or thrown exceptions or type parameter bounds - Blank final serialVersionUID fields - serialVersionUID fields in non-serializable classes - serialVersionUID that's not static final - serialVersionUID in an interface - RCS keywords in public constants :) Anything else? I agree. We're never going to get a 100% score on Japi anyway [1], so hiding this stuff doesn't do any good in my opinion. [1] One example I can think of is the non-constant serialVersionUID fields in some classes (that compute their serialVersionUID based on some runtime setting or such) Why would we get japi failures here? As long as we do the same thing the JDK does, japi won't report any errors. This is already the way it works (although I'm thinking about making the error message more accurate; right now it will say serialVersionUID=0 which isn't quite true). Honestly, I don't see any reason why we shouldn't get to zero japi errors; having a bunch of false positive results just makes it harder to find what the real errors are that need to be fixed, especially once we get to the point where the false positives outnumber the real errors. I honestly believe that's part of why it took so long to get to zero errors against 1.1 - until relatively recently the very few remaining real errors were dwarfed by the false positives caused by later JDK versions being incompatible with 1.1 themselves. The japi report against 1.1 was all but useless until the false positives were removed. If you guys still feel differently then feel free to try to persuade me :) Stuart. -- http://sab39.dev.netreach.com/ -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Has someone experimented with jedit?
David Gilbert wrote: Pointers to other Free-and-not-overly-complex Swing applications are welcome too. I'm happy to try running a few things and fixing some bugs (at least the easy ones). Haven't tried it with Classpath myself, but here's one that might be worth trying: http://pollo.sourceforge.net/ Pollo is a graphical XML editor. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RE: japi and public references to non-public types
Stuart Ballard wrote: [1] One example I can think of is the non-constant serialVersionUID fields in some classes (that compute their serialVersionUID based on some runtime setting or such) Why would we get japi failures here? As long as we do the same thing the JDK does, japi won't report any errors. This is already the way it works (although I'm thinking about making the error message more accurate; right now it will say serialVersionUID=0 which isn't quite true). I misremembered. It may have been an IKVM specific thing (where ikvmstub was using reflection to get the value of serialVersionUID and thus it reported the runtime value). Honestly, I don't see any reason why we shouldn't get to zero japi errors; Possibly. Maybe we can use annotations (in the -- hopefully near -- future) to mark code that differs from Sun for a valid reason? Regards, Jeroen ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
[Bug swing/24214] JTree performance problems with large model
--- Comment #3 from langel at redhat dot com 2005-10-05 13:55 --- It seems to be the actual painting of the tree is very inefficent. I will fix this. There is way too much recursion going on. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24214 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: japi and public references to non-public types
On 10/5/05, Jeroen Frijters [EMAIL PROTECTED] wrote: Possibly. Maybe we can use annotations (in the -- hopefully near -- future) to mark code that differs from Sun for a valid reason? Perhaps I have too little faith in my fellow developers, but this idea scares me ;) So far I haven't seen any situations where we need to differ from Sun that aren't detectable and ignorable by japi without needing annotations... Stuart. -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RE: japi and public references to non-public types
Stuart Ballard wrote: On 10/5/05, Jeroen Frijters [EMAIL PROTECTED] wrote: Possibly. Maybe we can use annotations (in the -- hopefully near -- future) to mark code that differs from Sun for a valid reason? Perhaps I have too little faith in my fellow developers, but this idea scares me ;) As long as you list the annotations in the report (in a special section), I don't see any problems. So far I haven't seen any situations where we need to differ from Sun that aren't detectable and ignorable by japi without needing annotations... What about the NameImpl issue? Regards, Jeroen ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: japi and public references to non-public types
On 10/5/05, Jeroen Frijters [EMAIL PROTECTED] wrote: What about the NameImpl issue? Definitely detectable and ignorable. Check out http://www.kaffe.org/~stuart/japi/htmlout/cvs/h-jdk13-classpath.html It's already being detected and ignored. The code needs a little refinement but the basic structure is there. A separate report of broken things in the API is an excellent idea (I'm trying to avoid volunteering to write japilint, especially as I can't believe the Java world doesn't already have an FxCop equivalent, but I have a funny feeling I'm going to write it anyway ;) ). APIs that are fundamentally broken and unimplementable are outside the scope of japicompat, though, I think. If we do find a situation where we need to differ from the JDK but there's absolutely no way to distinguish that situation to make it ignorable in japicompat then annotations are probably the way to go, but I think it's a last resort... Stuart. -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: japi and public references to non-public types
On Wednesday 05 October 2005 16:18, Jeroen Frijters wrote: So far I haven't seen any situations where we need to differ from Sun that aren't detectable and ignorable by japi without needing annotations... What about the NameImpl issue? Funny suggestion; annotating something that is not there... -- Thomas Zander pgpczz1X7IDVp.pgp Description: PGP signature ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: japi and public references to non-public types
On Wed, 2005-10-05 at 09:57 -0400, Stuart Ballard wrote: On 10/5/05, Jeroen Frijters [EMAIL PROTECTED] wrote: Possibly. Maybe we can use annotations (in the -- hopefully near -- future) to mark code that differs from Sun for a valid reason? Perhaps I have too little faith in my fellow developers, but this idea scares me ;) An annotation like that might be useful like a deprecation annotation is useful. Then the compiler can warn that you are possibly using an implementation specific or not-forward/backward non-abi-compatible thing from a library. Library implementers do make mistakes. If they do there might not be a way back, but it would be good to warn the user/developer about 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
Re: Has someone experimented with jedit?
Hi, On Wed, 2005-10-05 at 14:29 +0200, Roman Kennke wrote: We (especially Mark) usually test JEdit before making a release, but since this app is not usable at all with Classpath, it is not a showstopper. We focus on fixing Classpath with simpler apps first (like the TestRunner that David mentioned, or the BeanShell JConsole), this will also improve the complex application to a certain degree. I always make sure jedit at least starts up when we are doing a new release. And with each release it does become more and more usable. You can now actually open a document, edit a bit, search and replace, etc. But there are certainly still a lot of drawing/refresh bugs. Also the embedded beanshell used to not work properly, but this might now be fixed. Of course it would be nice if you could regularily test JEdit against GNU Classpath (keep in mind, you need a build with Java2D/Cairo enabled) and post results (and/or bugreports). You need to compile classpath with the --enable-cairo-gtk option to configure and run jedit with -Dgnu.java.awt.peer.gtk.Graphics=Graphics2D defined. Unfortunately GdkGraphics2D is broken in current CVS. With the patch of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24099 you can get it to work a bit again though. 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
Re: Has someone experimented with jedit?
Hi, On Wed, 2005-10-05 at 08:49 -0500, Archie Cobbs wrote: Haven't tried it with Classpath myself, but here's one that might be worth trying: http://pollo.sourceforge.net/ Pollo is a graphical XML editor. It does start up, you can partially use the dialog, about, help, etc. I did find (and already fixed) a bug in our JOptionPane. But I have not yet been able to actually edit any documents. The screenshots look cool though. 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
Re: japi and public references to non-public types
Stuart == Stuart Ballard [EMAIL PROTECTED] writes: Stuart Is there a Java equivalent to C#'s FxCop tool? I'm not sure what exactly FxCop does, but there is FindBugs and a couple of similar tools. One nice thing about enhancing these tools is that they already have IDE plugins, so you get that for free. Stuart - serialVersionUID that's not static final I think Eclipse will check for this one. Not sure about the other serialVersionUID things you listed. One problem with our current Eclipse setup is that we actually have too many warnings enabled. To work my way through them I have to filter by package so that the list isn't too overwhelming. Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Has someone experimented with jedit?
On Wednesday 05 October 2005 19:03, Mark Wielaard wrote: You need to compile classpath with the --enable-cairo-gtk option to configure and run jedit with -Dgnu.java.awt.peer.gtk.Graphics=Graphics2D defined. A little off topic; does the Qt peers doe Graphics2D ? And do you need any config options for that? -- Thomas Zander pgpCzbIf9jJDh.pgp Description: PGP signature ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
request for testing AWT/SWING
Hello all, may I ask for a minimal test sequence when you dear AWT/SWING coders submit/commit a patch for AWT/SWING? Simply launch the demos in swing and awt and click through to see if something has changed. The reason I ask is simple, I often try the included samples from classpath and see some improvements but also, and this is the reason, some backsteps. Sure, some backsteps can result due to the reason that things were not done properly up to now. But what I'd like to see is a note if something really changes in a demo we have. This could save others a lot of time if they don't have to revert everything and find out, ouch, it's the same behavior without my patch. I do not want to upset anyone, I highly appreciate the effort you put into this project, but it may help to coordinate a bit and reduce side noise about potential 'no faults'. Best Regards, Andreas ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: request for testing AWT/SWING
Hi Andreas, list. On Wed, 2005-10-05 at 22:08 +0200, Andreas Tobler wrote: may I ask for a minimal test sequence when you dear AWT/SWING coders submit/commit a patch for AWT/SWING? Or more automated and requiring less manual effort, a periodic regression check against mauve? For example daily mauve regression run gave the following on 30/09/2005: Regressions: +FAIL: gnu.testlet.javax.swing.AbstractButton.constructor (number 2) +FAIL: gnu.testlet.javax.swing.AbstractButton.init: AbstractButton.text is per default (number 1) followed on 04/10/2005: Fixes: -FAIL: gnu.testlet.javax.swing.AbstractButton.constructor (number 2) -FAIL: gnu.testlet.javax.swing.AbstractButton.init: AbstractButton.text is per default (number 1) (Picked one instance at random as example - no other reason for picking this above any other recent regression and subsequent fix) This shows a fix went in quickly and the nature of active development is (sometimes necessary) breakage followed by better implementation to fix before next stable release. However I wonder if cross reference against daily mauve regressions would help identify and fix these more quickly? Paul -- Paul Jenner [EMAIL PROTECTED] ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Wrong exception thrown in AccessContoller
Hi,
On Sat, 2005-09-17 at 09:47 -0600, Tom Tromey wrote:
Nicolas == Nicolas Geoffray [EMAIL PROTECTED] writes:
Nicolas I attached a patch (it's patched against 0.13, but it's ok for 0.18)
Nicolas and a java program which execution is different between sun and gnu
Nicolas classpath.
Could you turn this into a Mauve test?
I created the attached Mauve test for it. And tested that without the
patch we have one failure, with the patch all pass.
Cheers,
Mark
// Copyright (C) 2005, Free Software Foundation, Inc.
//
// This file is part of Mauve.
//
// Mauve is free software; you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation; either version 2, or (at your option)
// any later version.
//
// Mauve is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with Mauve; see the file COPYING. If not, write to
// the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
// Boston, MA, 02110-1301 USA.
//
// Tags: JDK1.2
package gnu.testlet.java.security.AccessController;
import gnu.testlet.Testlet;
import gnu.testlet.TestHarness;
import java.security.*;
/**
* Checks that unchecked exceptions are properly thrown and checked
* exceptions are properly wrapped.
*
* Written by Mark J. Wielaard. Suggested by Nicolas Geoffray.
*/
public class doPrivileged implements Testlet, PrivilegedExceptionAction
{
// The thing to throw.
private Throwable t;
public void test(TestHarness harness)
{
doPrivileged pea = new doPrivileged();
pea.t = new NullPointerException();
try
{
AccessController.doPrivileged(pea);
}
catch (NullPointerException npe)
{
harness.check(true);
}
catch (Throwable tt)
{
harness.debug(tt);
harness.check(false);
}
pea.t = new java.io.IOException();
try
{
AccessController.doPrivileged(pea);
}
catch (PrivilegedActionException pae)
{
harness.check(pea.t, pae.getCause());
}
catch (Throwable tt)
{
harness.debug(tt);
harness.check(false);
}
pea.t = new ThreadDeath();
try
{
AccessController.doPrivileged(pea);
}
catch (ThreadDeath td)
{
harness.check(true);
}
catch (Throwable tt)
{
harness.debug(tt);
harness.check(false);
}
}
public Object run() throws Exception
{
if (t instanceof Error)
throw (Error) t;
else
throw (Exception) t;
}
}
signature.asc
Description: This is a digitally signed message part
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: request for testing AWT/SWING
Paul == Paul Jenner [EMAIL PROTECTED] writes: Paul However I wonder if cross reference against daily mauve regressions Paul would help identify and fix these more quickly? Yes. The GCC community has a number of auto-builders that send email (using the ChangeLog) to anybody who breaks the build (including regression tests). Something like that may be helpful. I've got a bunch of test code running atm, though I'm not sending the output anywhere yet. Specifically right now my tester: * builds gcj * runs its test suite including mauve and jacks * builds gcjx * builds classpath with both gcj and gcjx * builds jamvm Next step is to run mauve against the just-built jamvm. I'd also like to set it up to build and test some applications (hopefully ones that are relatively simple to set up -- for larger things I would like to see us more actively involved with Gump). Anyway, the question is, what to do with the info? The reason I turned off my nightly tests the last time was that only I could see the results, and I didn't have time to track down regressions. Should we set up a new list? Try to implement some gcc-like solution? Send them to an existing list? Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
[commit-cp] classpath ./ChangeLog javax/swing/table/JTableH...
CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Roman Kennke [EMAIL PROTECTED]05/10/05 14:17:14 Modified files: . : ChangeLog javax/swing/table: JTableHeader.java Log message: 2005-10-05 Roman Kennke [EMAIL PROTECTED] * javax/swing/table/JTableHeader.java (accessibleContext): Removed unneeded field. The protected field with the same name should be used instead. (JTableHeader): Moved field initialization to new method initializeLocalVars(). (setColumnModel): Add and remove this to the old and new model. (columnAdded): New listener method. (columnMarginChanged): New listener method. (columnMoved): New listener method. (columnRemoved): New listener method. (columnSelectionChanged): New listener method. (resizeAndRepaint): New method. (initializeLocalVars): New method. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.5119tr2=1.5120r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/javax/swing/table/JTableHeader.java.diff?tr1=1.12tr2=1.13r1=textr2=text
[commit-cp] classpath ./ChangeLog javax/swing/text/Abstract...
CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Anthony Balkissoon [EMAIL PROTECTED] 05/10/05 15:19:47 Modified files: . : ChangeLog javax/swing/text: AbstractDocument.java GapContent.java Log message: 2005-10-05 Anthony Balkissoon [EMAIL PROTECTED] * javax/swing/text/AbstractDocument.java: (remove): If removing content returns an UndoableEdit, then add an ElementEdit to the DocumentEvent before firing. * javax/swing/text/GapContent.java: (UndoRemove): New class to implement UndoableEdit for remove operation. (remove): Return an UndoableEdit instead of null. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.5121tr2=1.5122r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/javax/swing/text/AbstractDocument.java.diff?tr1=1.31tr2=1.32r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/javax/swing/text/GapContent.java.diff?tr1=1.29tr2=1.30r1=textr2=text
[commit-cp] classpath ./ChangeLog gnu/CORBA/CDR/cdrInput.ja...
CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Audrius MeÂkauskas [EMAIL PROTECTED] 05/10/05 16:25:43 Modified files: . : ChangeLog gnu/CORBA/CDR : cdrInput.java gnu/CORBA : EmptyExceptionHolder.java ForwardRequestHelper.java Functional_ORB.java Minor.java _PolicyImplBase.java gnuAny.java universalHolder.java gnu/CORBA/Poa : gnuServantObject.java org/omg/CORBA : BAD_OPERATION.java CompletionStatus.java MARSHAL.java NO_RESOURCES.java NameValuePairHelper.java ObjectHelper.java PolicyHelper.java PolicyListHelper.java ServiceDetailHelper.java StringValueHelper.java WStringValueHelper.java org/omg/CosNaming: BindingHelper.java BindingIteratorHelper.java BindingIteratorPOA.java BindingTypeHelper.java NameComponentHelper.java NameHelper.java NamingContextExtHelper.java NamingContextExtPOA.java NamingContextHelper.java NamingContextPOA.java _BindingIteratorImplBase.java _NamingContextImplBase.java org/omg/CosNaming/NamingContextPackage: AlreadyBoundHelper.java CannotProceedHelper.java InvalidNameHelper.java NotEmptyHelper.java NotFoundHelper.java NotFoundReasonHelper.java org/omg/DynamicAny/DynAnyFactoryPackage: InconsistentTypeCodeHelper.java org/omg/DynamicAny/DynAnyPackage: InvalidValueHelper.java TypeMismatchHelper.java org/omg/DynamicAny: DynAnySeqHelper.java NameDynAnyPairHelper.java NameDynAnyPairSeqHelper.java NameValuePairHelper.java NameValuePairSeqHelper.java org/omg/IOP/CodecFactoryPackage: UnknownEncodingHelper.java org/omg/IOP/CodecPackage: FormatMismatchHelper.java InvalidTypeForEncodingHelper.java TypeMismatchHelper.java org/omg/IOP: IORHelper.java MultipleComponentProfileHelper.java ServiceContextHelper.java ServiceContextListHelper.java TaggedComponentHelper.java TaggedProfileHelper.java org/omg/PortableInterceptor: ForwardRequestHelper.java InvalidSlotHelper.java org/omg/PortableInterceptor/ORBInitInfoPackage: DuplicateNameHelper.java InvalidNameHelper.java org/omg/PortableServer/CurrentPackage: NoContextHelper.java org/omg/PortableServer: ForwardRequestHelper.java IdAssignmentPolicyValue.java IdUniquenessPolicyValue.java ImplicitActivationPolicyValue.java LifespanPolicyValue.java RequestProcessingPolicyValue.java Servant.java ServantLocatorHelper.java ServantRetentionPolicyValue.java ThreadPolicyValue.java org/omg/PortableServer/POAManagerPackage: AdapterInactiveHelper.java State.java org/omg/PortableServer/POAPackage: AdapterAlreadyExistsHelper.java AdapterNonExistentHelper.java InvalidPolicyHelper.java NoServantHelper.java ObjectAlreadyActiveHelper.java ObjectNotActiveHelper.java ServantAlreadyActiveHelper.java ServantNotActiveHelper.java WrongAdapterHelper.java WrongPolicyHelper.java Log message: 2005-10-05
[commit-cp] classpath ./ChangeLog javax/swing/JOptionPane.java
CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Mark Wielaard [EMAIL PROTECTED] 05/10/05 17:32:23 Modified files: . : ChangeLog javax/swing: JOptionPane.java Log message: * javax/swing/JOptionPane.java (showInputDialog(Component,Object,String,int,Icon,Object[],Object)): Don't cast return value. (internalShowInputDialog(Component,Object,String,int,Icon,Object[], Object)): Likewise. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.5124tr2=1.5125r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/javax/swing/JOptionPane.java.diff?tr1=1.19tr2=1.20r1=textr2=text
[commit-cp] classpath ./ChangeLog ./configure.ac native/fdl...
CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Tom Tromey [EMAIL PROTECTED] 05/10/05 19:19:00 Modified files: . : ChangeLog configure.ac native/fdlibm : java-assert.h native/jni/java-lang: java_lang_reflect_Array.c Added files: m4 : acattribute.m4 Log message: 2005-10-05 Christian Thalinger [EMAIL PROTECTED] * m4/acattribute.m4: Added. * configure.ac: Added AC_C_ATTRIBUTE. * native/fdlibm/java-assert.h: Added missing config.h include, changed comments to C comments. * native/jni/java-lang/java_lang_reflect_Array.c: Added missing config.h include. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.5126tr2=1.5127r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/configure.ac.diff?tr1=1.109tr2=1.110r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/m4/acattribute.m4?rev=1.1 http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/native/fdlibm/java-assert.h.diff?tr1=1.1tr2=1.2r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/native/jni/java-lang/java_lang_reflect_Array.c.diff?tr1=1.10tr2=1.11r1=textr2=text
[commit-cp] classpath ./ChangeLog javax/swing/text/GapConte...
CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Roman Kennke [EMAIL PROTECTED]05/10/05 20:24:46 Modified files: . : ChangeLog javax/swing/text: GapContent.java Log message: 2005-10-05 Roman Kennke [EMAIL PROTECTED] * javax/swing/text/GapContent.java (setPositionsInRange): Changed check for interval end to actually check for the position offsets. (adjustPositionsInRange): Changed check for interval end to actually check for the position offsets. (dump): New method for debugging. (dumpPositions): New method for debugging. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.5127tr2=1.5128r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/javax/swing/text/GapContent.java.diff?tr1=1.30tr2=1.31r1=textr2=text
[commit-cp] classpath ./ChangeLog java/security/AccessContr...
CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Mark Wielaard [EMAIL PROTECTED] 05/10/05 21:21:43 Modified files: . : ChangeLog java/security : AccessController.java Log message: Reported by Nicolas Geoffray [EMAIL PROTECTED] * java/security/AccessController.java (doPrivileged(PrivilegedExceptionAction)): If the Exception is a Runtime exception, then throw the exception directly, otherwise wrap it. (doPrivileged(PrivilegedExceptionAction,AccessControlContext)): Likewise. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.5128tr2=1.5129r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/security/AccessController.java.diff?tr1=1.10tr2=1.11r1=textr2=text
[commit-cp] classpath ./ChangeLog javax/swing/text/BoxView....
CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Roman Kennke [EMAIL PROTECTED]05/10/05 21:46:41 Modified files: . : ChangeLog javax/swing/text: BoxView.java ParagraphView.java View.java Log message: 2005-10-05 Roman Kennke [EMAIL PROTECTED] * javax/swing/text/BoxView.java (baselineLayout): New method. (calculateMajorAxisRequirements): Reimplemented to use the SizeRequirements utility methods. (calculateMinorAxisRequirements): Reimplemented to use the SizeRequirements utility methods. (layout): Use the new baselineLayout method. (layoutMajorAxis): Reimplemented to use the new getChildRequirements method. (layoutMinorAxis): Reimplemented to use the new getChildRequirements method. (getChildRequirements): New method. (getSpan): New method. (getOffset): New method. (getAlignment): New method. * javax/swing/text/ParagraphView.java (Row.getAlignment): New method. (getAlignment): New method. * javax/swing/text/View.java (getContainer): Improved error message in assertion a little. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.5130tr2=1.5131r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/javax/swing/text/BoxView.java.diff?tr1=1.4tr2=1.5r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/javax/swing/text/ParagraphView.java.diff?tr1=1.2tr2=1.3r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/javax/swing/text/View.java.diff?tr1=1.19tr2=1.20r1=textr2=text
[commit-cp] classpath ./ChangeLog javax/swing/plaf/basic/Ba...
CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Lillian Angel [EMAIL PROTECTED] 05/10/05 21:50:17 Modified files: . : ChangeLog javax/swing/plaf/basic: BasicTreeUI.java Log message: 2005-10-05 Lillian Angel [EMAIL PROTECTED] * javax/swing/plaf/basic/BasicTreeUI.java (paintRow): Fixed indentation. (updateCurrentVisiblePath): Added FIXME comment. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.5131tr2=1.5132r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/javax/swing/plaf/basic/BasicTreeUI.java.diff?tr1=1.85tr2=1.86r1=textr2=text
[commit-cp] classpath java/awt/Container.java java/awt/Butt... [generics-branch]
CVSROOT:/cvsroot/classpath Module name:classpath Branch: generics-branch Changes by: Tom Tromey [EMAIL PROTECTED] 05/10/06 00:32:41 Modified files: java/awt : Container.java Button.java List.java TextComponent.java Window.java Scrollbar.java Choice.java CheckboxMenuItem.java TextField.java javax/swing: DefaultListSelectionModel.java JComponent.java Timer.java DefaultSingleSelectionModel.java AbstractListModel.java DefaultBoundedRangeModel.java AbstractSpinnerModel.java DefaultButtonModel.java javax/swing/table: AbstractTableModel.java DefaultTableColumnModel.java javax/swing/tree: DefaultTreeSelectionModel.java DefaultTreeModel.java javax/swing/text: StyleContext.java AbstractDocument.java DefaultCaret.java javax/swing/event: EventListenerList.java . : ChangeLog java/awt/dnd : DragSource.java Log message: * javax/swing/tree/DefaultTreeSelectionModel.java (getListeners): Genericized. * javax/swing/tree/DefaultTreeModel.java (getListeners): Genericized. * javax/swing/Timer.java (getListeners): Genericized. * javax/swing/text/StyleContext.java (getListeners): Genericized. * javax/swing/text/DefaultCaret.java (getListeners): Genericized. * javax/swing/text/AbstractDocument.java (getListeners): Genericized. * javax/swing/table/DefaultTableColumnModel.java (getListeners): Genericized. * javax/swing/table/AbstractTableModel.java (getListeners): Genericized. * javax/swing/JComponent.java (getListeners): Genericized. * javax/swing/DefaultSingleSelectionModel.java (getListeners): Genericized. * javax/swing/DefaultListSelectionModel.java (getListeners): Genericized. * javax/swing/DefaultButtonModel.java (getListeners): Genericized. * javax/swing/DefaultBoundedRangeModel.java (getListeners): Genericized. * javax/swing/AbstractSpinnerModel.java (getListeners): Genericized. * javax/swing/event/EventListenerList.java (add): Genericized. (getListeners): Likewise. (remove): Likewise. * java/awt/dnd/DragSource.java (getListeners): Genericized. * java/awt/TextField.java (getListeners): Genericized. * java/awt/Window.java (getListeners): Genericized. * java/awt/Scrollbar.java (getListeners): Genericized. * java/awt/List.java (getListeners): Genericized. * java/awt/Choice.java (getListeners): Genericized. * java/awt/TextComponent.java (getListeners): Genericized. * java/awt/CheckboxMenuItem.java (getListeners): Genericized. * java/awt/Button.java (getListeners): Genericized. * java/awt/Container.java (getListeners): Genericized. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/awt/Container.java.diff?only_with_tag=generics-branchtr1=1.37.2.15tr2=1.37.2.16r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/awt/Button.java.diff?only_with_tag=generics-branchtr1=1.13.2.9tr2=1.13.2.10r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/awt/List.java.diff?only_with_tag=generics-branchtr1=1.18.2.5tr2=1.18.2.6r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/awt/TextComponent.java.diff?only_with_tag=generics-branchtr1=1.15.2.6tr2=1.15.2.7r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/awt/Window.java.diff?only_with_tag=generics-branchtr1=1.35.2.12tr2=1.35.2.13r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/awt/Scrollbar.java.diff?only_with_tag=generics-branchtr1=1.18.2.7tr2=1.18.2.8r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/awt/Choice.java.diff?only_with_tag=generics-branchtr1=1.15.2.6tr2=1.15.2.7r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/awt/CheckboxMenuItem.java.diff?only_with_tag=generics-branchtr1=1.12.2.7tr2=1.12.2.8r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/awt/TextField.java.diff?only_with_tag=generics-branchtr1=1.12.2.4tr2=1.12.2.5r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/javax/swing/DefaultListSelectionModel.java.diff?only_with_tag=generics-branchtr1=1.7.2.6tr2=1.7.2.7r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/javax/swing/JComponent.java.diff?only_with_tag=generics-branchtr1=1.20.2.14tr2=1.20.2.15r1=textr2=text
[commit-cp] classpath ./ChangeLog java/util/prefs/Preferenc... [generics-branch]
CVSROOT:/cvsroot/classpath Module name:classpath Branch: generics-branch Changes by: Tom Tromey [EMAIL PROTECTED] 05/10/06 00:38:45 Modified files: . : ChangeLog java/util/prefs: Preferences.java Log message: * java/util/prefs/Preferences.java (systemNodeForPackage): Genericized. (userNodeForPackage): Likewise. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?only_with_tag=generics-branchtr1=1.2386.2.152tr2=1.2386.2.153r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/util/prefs/Preferences.java.diff?only_with_tag=generics-branchtr1=1.8.2.4tr2=1.8.2.5r1=textr2=text
[commit-cp] classpath java/util/jar/Attributes.java java/ut... [generics-branch]
CVSROOT:/cvsroot/classpath Module name:classpath Branch: generics-branch Changes by: Tom Tromey [EMAIL PROTECTED] 05/10/06 03:03:21 Modified files: java/util/jar : Attributes.java Manifest.java JarFile.java . : ChangeLog Log message: * java/util/jar/Attributes.java: Implements MapObject,Object. (map): Changed type. (entrySet): Changed return type. (keySet): Likewise. (putAll): Changed argument type. (values): Changed return type. * java/util/jar/Manifest.java (getEntries): Genericized. (Manifest): Updated. (entries): Changed type. (read_individual_sections): Updated. (read_section_name): Likewise. (write_main_attributes): Likewise. (write_attribute_entry): Likewise. (write_individual_sections): Likewise. (write_entry_attributes): Likewise. * java/util/jar/JarFile.java (entries): Genericized. (JarEnumeration): Implements EnumerationJarEntry. (JarEnumeration.nextElement): Changed return type. (JarEnumeration.entries): Changed type. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/util/jar/Attributes.java.diff?only_with_tag=generics-branchtr1=1.9.2.3tr2=1.9.2.4r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/util/jar/Manifest.java.diff?only_with_tag=generics-branchtr1=1.8.2.2tr2=1.8.2.3r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/util/jar/JarFile.java.diff?only_with_tag=generics-branchtr1=1.10.2.5tr2=1.10.2.6r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?only_with_tag=generics-branchtr1=1.2386.2.155tr2=1.2386.2.156r1=textr2=text
