Re: [cp-patches] FYI: Bumped up serialVersionUIDs in javax.swing

[Andrew John Hughes]

On Sat, 2005-05-28 at 09:24 +0200, Michael Koch wrote:
> On Sat, May 28, 2005 at 12:09:00AM +0100, Andrew John Hughes wrote:
> > On Fri, 2005-05-27 at 23:14 +0200, Roman Kennke wrote:
> > > Hi,
> > > 
> > > I updated all serialVersionUIDs in the javax.swing package to be
> > > compatible with JDK1.4. I intentionally left out some cases where I
> > > would probably break build with GCJ3 (accessible stuff). Have me made
> > > any progress on this issue?
> > > 
> > > 2005-05-27  Roman Kennke  <address@hidden>
> > > 
> > >         * javax/swing/AbstractButton.java:
> > >         Bumped up serialVersionUID(s) to JDK1.4 compatibility.
> > >         * javax/swing/ImageIcon.java: Likewise.
> > >         * javax/swing/JFileChooser.java: Likewise.
> > >         * javax/swing/JInternalFrame.java: Likewise.
> > >         * javax/swing/JMenu.java: Likewise.
> > >         * javax/swing/JRadioButton.java: Likewise.
> > >         * javax/swing/JScrollPane.java: Likewise.
> > >         * javax/swing/JSpinner.java: Likewise.
> > >         * javax/swing/JTabbedPane.java: Likewise.
> > >         * javax/swing/ImageIcons.java: Likewise.
> > >         * javax/swing/JToggleButton.java: Likewise.
> > >         * javax/swing/JToolTip.java: Likewise.
> > >         * javax/swing/JViewPort.java: Likewise.
> > >         * javax/swing/LayoutFocusTraversalPolicy.java: Likewise.
> > >         * javax/swing/SpinnerDateModel.java: Likewise.
> > >         * javax/swing/TransferHandler.java: Likewise.
> 
> We had decided in the past to ignore this stuff in Swing.
> 
I agree to an extent as these change rapidly.  But I also think the
presence of models in the Swing classes make this less black and white
than this implies.  I imagine its reasonable to suggest supporting RMI
(which requires serialization) for e.g. the SpinnerDateModel, but I
don't see why we need it for the components (perhaps someone wants to
enlighten me?)

> > From what I recall, we decided to drop pre-GCJ 4 support,
> > which presumably means the accessibility stuff can now
> > go through.
> 
> Afaik there was no decision yet. We still support GCJ 3.3 and up.
> 

Sorry, I couldn't ascertain this either way, and the discussion of
configure changes suggested that a positive decision was reached.

> > However, I haven't seen any movement on this, and I don't recall a patch
> > to the configure process going through.  Can anyone provide
> > more definite info on the status of this?
> 
> Without some decision on what to depend now? Mark still wants to support
> GCJ 3.4 for next release which is kind of pointless in my eyes.
> 

As I say above, I didn't realise this was the case.  Supporting GCJ
3.4's *bugs* (which is what this really means) also seems pointless to
me.  I doubt classes changes would be backported to 3.4 anyway, so it's
just an issue of compiling Classpath with GCJ 3.4, rather than the
result being used in some future micro version of GCJ 3.4.  Perhaps Mark
would care to explain his reasoning, as I don't recall seeing this on
the list.  As a counterexample, we support only the most recent version
of GTK+ now, for example.  I presume Debian would be one issue, as 4
won't make Sarge.

> 
> Michael

Cheers,
-- 
Andrew :-)

Please avoid sending me Microsoft Office (e.g. Word, PowerPoint)
attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html

No software patents in Europe -- http://nosoftwarepatents.com

"Value your freedom, or you will lose it, teaches history.
`Don't bother us with politics' respond those who don't want to learn."
-- Richard Stallman

Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
public class gcj extends Freedom implements Java { ... }

signature.asc
Description: This is a digitally signed message part