From Alan.Bateman at oracle.com Sat Feb 1 00:08:56 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 01 Feb 2014 08:08:56 +0000 Subject: JDK 9 RFR of JDK-8033181: Fix doclint missing issues in java.awt.{peer, im[.spi]} In-Reply-To: <52EBECF6.9080102@oracle.com> References: <52E9553F.4030606@oracle.com> <52EBECF6.9080102@oracle.com> Message-ID: <52ECAB98.70000@oracle.com> On 31/01/2014 18:35, Joe Darcy wrote: > *ping* > > Thanks, > > -Joe I've skimmed through the changes and don't see anything obviously wrong. All the @returns are okay. For the @param then it requires a bit of domain knowledge (and I don't know this area). For InputMethodContext.dispatchInputMethodEvent then I see it comes from InputMethodEvent so I think that is okay (btw: I think technically the input method area is i18n-awt rather than awt-dev). To my knowledge then the peer API is not in the generated javadoc but it looks okay to me too. One thing to consider is keeping the formatting consistent (where possible) for what seems to be the norm in this area. I see that there is typically a blank line between the method description and the @param or @return tags. The wrapping when descriptions go into two or more lines is another one. This type of thing is more obvious in a webrev or patch because it doesn't have color coding. This doesn't impact the generated javadoc of course. -Alan. From Alan.Bateman at oracle.com Sat Feb 1 00:11:59 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 01 Feb 2014 08:11:59 +0000 Subject: JDK 9 RFR of JDK-8033222: Fix serial lint warnings in sun.awt.* In-Reply-To: <52EBED13.6040106@oracle.com> References: <52E9E8BF.1050003@oracle.com> <52EBED13.6040106@oracle.com> Message-ID: <52ECAC4F.6050605@oracle.com> On 31/01/2014 18:36, Joe Darcy wrote: > *ping* > > Thanks, > > -Joe This update looks okay to me. It would be good for someone working in this area to re-visit these at some point to see if any of these are actually serialized (indirectly) and whether any other actions should be taken. -Alan From Alan.Bateman at oracle.com Sun Feb 2 03:51:46 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 02 Feb 2014 11:51:46 +0000 Subject: Should changes to client libraries be pushed to jdk9/dev instead of jdk9/client In-Reply-To: <52EC35BF.60505@oracle.com> References: <52E40C2C.8070503@oracle.com> <52E4D5A4.4040104@oracle.com> <52EB67F2.7030800@oracle.com> <52EB754C.6040904@oracle.com> <52EC35BF.60505@oracle.com> Message-ID: <52EE3152.6020006@oracle.com> On 31/01/2014 23:46, Joseph Darcy wrote: > : > > Discussions are on going as to which forest client libraries fixes > should go into, the client forest (where closed-source deployment > changes happen to be going) or to the dev forest where all the other > libraries work is going; FWIW, I favor the latter. I would too but I assume it depends on whether the changes require any special pre-integration testing that would prohibit weekly or more frequent integrations into master. > > In any case, for all the forests which will be integrating into dev, > including the client and hotspot forests, the maintainers of those > forests are responsible for regularly pulling down changes from dev > and merging them in. In my estimation, unless there is a reason for > temporary isolation, the frequency of syncing with dev should be > closer to daily than weekly or monthly. The dev forest was open for > business on Dec. 13, 2013, and fixes started going into it that day. > From my reading of the JDK 9 master > (http://hg.openjdk.java.net/jdk9/jdk9/jdk/), the tag for jdk9-b01 was > added about three weeks ago. So if the first sync from dev into client > has only done in the last day or two, that would seem to be tardy to me. I assume that since this is a new structure that it will take time to get used to. While I'm not too concerned about jdk9/client being behind for a bit, I do wonder about the changes backing up in jdk9/client. I don't think there has been any client->dev push yet and some of the changes in jdk9/client were pushed in December. Hopefully that will be sorted out soon. > > The goal for dev is to have integrations into master no less than > weekly, but I'd like us to transition to having smaller and more > frequent integrations. We are laying the foundational work, cleaning > up intermittent test failures, etc. to allow that to happen. Indeed, and I expect that the test work will continue for a long time. -Alan. From anton.tarasov at oracle.com Mon Feb 3 06:36:48 2014 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Mon, 03 Feb 2014 18:36:48 +0400 Subject: [OpenJDK 2D-Dev] [9] Review Request: JDK-8029455 JLightweightFrame: support scaled painting In-Reply-To: <52EC4F5E.7060906@oracle.com> References: <52A723B8.7090705@oracle.com> <52A7A319.80001@oracle.com> <52A82DE8.4070707@oracle.com> <52A840AE.2010000@oracle.com> <52A9D341.2070008@oracle.com> <52AA0C32.504@oracle.com> <52AA0E11.3060706@oracle.com> <52AA39A2.4060503@oracle.com> <52AA3E92.7040302@oracle.com> <52B09644.6050201@oracle.com> <52B0F447.2020207@oracle.com> <52DE761E.2000201@oracle.com> <52E192F0.7010107@oracle.com> <52E27CDA.40703@oracle.com> <52E31866.3010508@oracle.com> <52E7CE5B.4070101@oracle.com> <52EAD304.2090809@oracle.com> <52EBB516.70906@oracle.com> <52EC4F5E.7060906@oracle.com> Message-ID: <52EFA980.6000404@oracle.com> Hi Jim, Please look at the updated version: http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.4 On 01.02.2014 5:35, Jim Graham wrote: > Hi Anton, > > On 1/31/14 6:37 AM, Anton V. Tarasov wrote: >> My understanding is that, unless the fix is absolutely irrelevant (whic >> I hope it isn't), we should integrate it into 9/8u20 to support >> SwingNode in its current implementation on Retina displays. >> >> What do you think? > > I agree with this sentiment. My suggestion for reducing its footprint aside (which it looks like > you are investigating), the main thing I will be looking for is whether or not we return an object > to a developer (i.e. it isn't just managed internally to our own code) where they can do > "instanceof BufferedImage" and then see something odd coming from its width/height. > > It looks like if we simply use getLayoutWH() internally then they would never ever see anything > odd from getWidthHeight() anyway. The only additional "gotcha" would be if they grab the image and > render it directly and it comes out an unexpected size to them (because, for instance, they didn't > check the layout dims like we do internally). That's a pretty minor issue, though, and I think we > could live with it. I've refactored the fix with this concern in mind. Here is what I've done: - eliminated the new OffscreenHiDPIImage class (as you suggested) and put all of its "scale" logic into the OffscreenImage. - made the scaled OffscreenImage return the physical size (like an ordinary BufferredImage does) by default . - renamed the "set/isHiDPIEnabled" method to "set/isReturnLayoutSize". - made the setReturnLayoutSize(true) be called internally (where we don't leak the OffscreenImage). In SG2D, the drawHiDPIImage, for instance, makes a call to op.filter(img, null); where the img is expected to return its layout size. That's why I still prefer to use the setReturnLayoutSize "switcher", in order not to go deep into the 2D rendering code, casting here and there to OffscreenImage and calling getLayoutWidth/Height. > > For 9.0 perhaps we could add the LayoutWH() as new API on BufferedImage and then most of this > would be public? I'd have to mull over if that makes sense and I'm not entirely sure of the > naming yet... That's a good idea, however we need a 8u working solution as well... As to the naming, I'm ready for any suggestions. Thanks, Anton. > > ...jim From artem.ananiev at oracle.com Mon Feb 3 07:47:25 2014 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 03 Feb 2014 19:47:25 +0400 Subject: Setting a component orientation in JRSUI In-Reply-To: <52DFE254.7040408@oracle.com> References: <52DFE254.7040408@oracle.com> Message-ID: <52EFBA0D.9090409@oracle.com> Adding java-dev at apple alias to CC. Artem On 1/22/2014 7:23 PM, Alexander Scherbatiy wrote: > > Hello, > > Below is the code that shows that setting a component orientation for > the JProgressBar in Aqua L&F does not work. > > My assumption was that the Direction should be properly set to the > painter state in the AquaProgressBarUI like: > ----------------------------- > public void paint(final Graphics g, final JComponent c) { > ... > painter.state.set(c.getComponentOrientation().isLeftToRight() ? > Direction.RIGHT : Direction.LEFT); > } > ----------------------------- > but it does not work. > > The painter calls the JRSUI library to show components on Mac OS X. > > Is there any specification for the JRSUI library? > What is the right way to set the component direction in the JRSUI. > > Thanks, > Alexandr. > > > ------------------ Code Sample ---------- > import java.awt.*; > import java.awt.event.*; > import javax.swing.*; > > public class JProgressBarOrientationTest { > > static boolean leftToRight = true; > > public static void main(String[] args) throws Exception { > > SwingUtilities.invokeLater(new Runnable() { > > @Override > public void run() { > JFrame frame = new JFrame(); > frame.setSize(300, 200); > > final JProgressBar progressBar = new JProgressBar(0, 100); > progressBar.setValue(30); > progressBar.setComponentOrientation(ComponentOrientation.LEFT_TO_RIGHT); > > JButton button = new JButton("Change orientation"); > button.addActionListener(new ActionListener() { > > @Override > public void actionPerformed(ActionEvent e) { > leftToRight = !leftToRight; > progressBar.setComponentOrientation(leftToRight ? > ComponentOrientation.LEFT_TO_RIGHT : ComponentOrientation.RIGHT_TO_LEFT); > } > }); > > JPanel panel = new JPanel(new BorderLayout()); > panel.add(progressBar, BorderLayout.CENTER); > panel.add(button, BorderLayout.SOUTH); > frame.getContentPane().add(panel); > frame.setVisible(true); > } > }); > } > } > ------------------------------------- From omajid at redhat.com Mon Feb 3 09:43:27 2014 From: omajid at redhat.com (Omair Majid) Date: Mon, 3 Feb 2014 12:43:27 -0500 Subject: RFR: Allow using a system installed libpng Message-ID: <20140203174327.GA9174@redhat.com> Hi, The following webrevs modify the build system to allow building against the system-installed copy of libpng as well as using the bundled copy of libpng ROOT: http://cr.openjdk.java.net/~omajid/webrevs/system-libpng/01/ JDK: http://cr.openjdk.java.net/~omajid/webrevs/system-libpng/01-jdk/ A new configure option `--with-libpng` is introduced which defaults to `bundled` but can be set to `system` to use the system-installed copy of libpng. This patch (with minor differences) has been used in Fedora builds for a while now [1]. Thanks, Omair [1] http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/commit/system-libpng.patch?id=ff9254ee03799a98689692ee9ae060b3a31af213 -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From magnus.ihse.bursie at oracle.com Mon Feb 3 11:41:52 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 03 Feb 2014 20:41:52 +0100 Subject: RFR: Allow using a system installed libpng In-Reply-To: <20140203174327.GA9174@redhat.com> References: <20140203174327.GA9174@redhat.com> Message-ID: <52EFF100.8000004@oracle.com> On 2014-02-03 18:43, Omair Majid wrote: > Hi, > > The following webrevs modify the build system to allow building against > the system-installed copy of libpng as well as using the bundled copy of > libpng > > ROOT: http://cr.openjdk.java.net/~omajid/webrevs/system-libpng/01/ > JDK: http://cr.openjdk.java.net/~omajid/webrevs/system-libpng/01-jdk/ > > A new configure option `--with-libpng` is introduced which defaults to > `bundled` but can be set to `system` to use the system-installed copy of > libpng. Thank you for the patch! Looks good to me (but I'm no formal reviewer), apart from this line in libraries.m4: with_libpng=${DEFAULT_libpng} which should be DEFAULT_LIBPNG, I assume, otherwise the default case will not work. Due to this, I'd like to ask you to please double check that --with-libpng=system | bundled | invalid-value | , and no flag at all, all work as expected. /Magnus From omajid at redhat.com Mon Feb 3 12:44:41 2014 From: omajid at redhat.com (Omair Majid) Date: Mon, 3 Feb 2014 15:44:41 -0500 Subject: RFR: Allow using a system installed libpng In-Reply-To: <52EFF100.8000004@oracle.com> References: <20140203174327.GA9174@redhat.com> <52EFF100.8000004@oracle.com> Message-ID: <20140203204441.GC9174@redhat.com> * Magnus Ihse Bursie [2014-02-03 14:42]: > > On 2014-02-03 18:43, Omair Majid wrote: > >Hi, > > > >The following webrevs modify the build system to allow building against > >the system-installed copy of libpng as well as using the bundled copy of > >libpng > > > >ROOT: http://cr.openjdk.java.net/~omajid/webrevs/system-libpng/01/ > >JDK: http://cr.openjdk.java.net/~omajid/webrevs/system-libpng/01-jdk/ > > > >A new configure option `--with-libpng` is introduced which defaults to > >`bundled` but can be set to `system` to use the system-installed copy of > >libpng. > > Thank you for the patch! > > Looks good to me (but I'm no formal reviewer), apart from this line > in libraries.m4: > with_libpng=${DEFAULT_libpng} > > which should be DEFAULT_LIBPNG, I assume, otherwise the default case > will not work. Whoops. Updated webrevs: root: http://cr.openjdk.java.net/~omajid/webrevs/system-libpng/02/ jdk: http://cr.openjdk.java.net/~omajid/webrevs/system-libpng/02-jdk/ > Due to this, I'd like to ask you to please double check that > --with-libpng=system | bundled | invalid-value | , and no > flag at all, all work as expected. I re-ran all these 4 options. system builds with system, bundled and build a bundled copy and invalid-value fails during configure. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From magnus.ihse.bursie at oracle.com Mon Feb 3 13:51:20 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 03 Feb 2014 22:51:20 +0100 Subject: RFR: Allow using a system installed libpng In-Reply-To: <20140203204441.GC9174@redhat.com> References: <20140203174327.GA9174@redhat.com> <52EFF100.8000004@oracle.com> <20140203204441.GC9174@redhat.com> Message-ID: <52F00F58.4060404@oracle.com> On 2014-02-03 21:44, Omair Majid wrote: > Whoops. Updated webrevs: > root: http://cr.openjdk.java.net/~omajid/webrevs/system-libpng/02/ > jdk: http://cr.openjdk.java.net/~omajid/webrevs/system-libpng/02-jdk/ > >> Due to this, I'd like to ask you to please double check that >> --with-libpng=system | bundled | invalid-value | , and no >> flag at all, all work as expected. > I re-ran all these 4 options. system builds with system, bundled and > build a bundled copy and invalid-value fails during configure. Great, thank you. The fix looks good. /Magnus From swingler at apple.com Mon Feb 3 15:10:53 2014 From: swingler at apple.com (Mike Swingler) Date: Mon, 03 Feb 2014 15:10:53 -0800 Subject: Setting a component orientation in JRSUI In-Reply-To: <52DFE254.7040408@oracle.com> References: <52DFE254.7040408@oracle.com> Message-ID: <763D7A5E-FBD6-47C1-B5B0-E6E7DA8A7309@apple.com> On Jan 22, 2014, at 7:23 AM, Alexander Scherbatiy wrote: > Hello, > > Below is the code that shows that setting a component orientation for the JProgressBar in Aqua L&F does not work. > > My assumption was that the Direction should be properly set to the painter state in the AquaProgressBarUI like: > ----------------------------- > public void paint(final Graphics g, final JComponent c) { > ... > painter.state.set(c.getComponentOrientation().isLeftToRight() ? Direction.RIGHT : Direction.LEFT); > } > ----------------------------- > but it does not work. > > The painter calls the JRSUI library to show components on Mac OS X. > > Is there any specification for the JRSUI library? > What is the right way to set the component direction in the JRSUI. > > Thanks, > Alexandr. > > > ------------------ Code Sample ---------- > import java.awt.*; > import java.awt.event.*; > import javax.swing.*; > > public class JProgressBarOrientationTest { > > static boolean leftToRight = true; > > public static void main(String[] args) throws Exception { > > SwingUtilities.invokeLater(new Runnable() { > > @Override > public void run() { > JFrame frame = new JFrame(); > frame.setSize(300, 200); > > final JProgressBar progressBar = new JProgressBar(0, 100); > progressBar.setValue(30); > progressBar.setComponentOrientation(ComponentOrientation.LEFT_TO_RIGHT); > > JButton button = new JButton("Change orientation"); > button.addActionListener(new ActionListener() { > > @Override > public void actionPerformed(ActionEvent e) { > leftToRight = !leftToRight; > progressBar.setComponentOrientation(leftToRight ? ComponentOrientation.LEFT_TO_RIGHT : ComponentOrientation.RIGHT_TO_LEFT); > } > }); > > JPanel panel = new JPanel(new BorderLayout()); > panel.add(progressBar, BorderLayout.CENTER); > panel.add(button, BorderLayout.SOUTH); > frame.getContentPane().add(panel); > frame.setVisible(true); > } > }); > } > } > ------------------------------------- There is no spec for the JRSUI library, since it's generally a passthrough to underlying undocumented API. In this case, there is no right-to-left version of the progress bar in OS X. You can confirm this by building a sample app in Xcode, and running it in an RTL language like Hebrew or Arabic. The code above looks like it should do the right thing if/when the underlying OS does the right thing. Regards, Mike Swingler Apple Inc. From joe.darcy at oracle.com Mon Feb 3 21:25:10 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 03 Feb 2014 21:25:10 -0800 Subject: JDK 9 RFR of JDK-8033526: Fix serial lint warnings in java.awt.* Message-ID: <52F079B6.1010501@oracle.com> Hello, Please review the patch below to address JDK-8033526: Fix serial lint warnings in java.awt.* http://cr.openjdk.java.net/~darcy/8033526.0/ The patch just adds serialVersionUID values to various serializable classes that have long been in java.awt.*. I've verified the serialver computation matched on both JDK 6 and JDK 8. Thanks, -Joe --- old/src/share/classes/java/awt/color/CMMException.java 2014-02-03 21:21:08.000000000 -0800 +++ new/src/share/classes/java/awt/color/CMMException.java 2014-02-03 21:21:08.000000000 -0800 @@ -47,6 +47,7 @@ */ public class CMMException extends java.lang.RuntimeException { + private static final long serialVersionUID = 5775558044142994965L; /** * Constructs a CMMException with the specified detail message. --- old/src/share/classes/java/awt/color/ProfileDataException.java 2014-02-03 21:21:09.000000000 -0800 +++ new/src/share/classes/java/awt/color/ProfileDataException.java 2014-02-03 21:21:09.000000000 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1997, 2000, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -31,6 +31,7 @@ */ public class ProfileDataException extends java.lang.RuntimeException { + private static final long serialVersionUID = 7286140888240322498L; /** * Constructs a ProfileDataException with the specified detail message. --- old/src/share/classes/java/awt/datatransfer/FlavorEvent.java 2014-02-03 21:21:10.000000000 -0800 +++ new/src/share/classes/java/awt/datatransfer/FlavorEvent.java 2014-02-03 21:21:10.000000000 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2006, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -38,6 +38,8 @@ * @since 1.5 */ public class FlavorEvent extends EventObject { + private static final long serialVersionUID = -5842664112252414548L; + /** * Constructs a FlavorEvent object. * --- old/src/share/classes/java/awt/geom/IllegalPathStateException.java 2014-02-03 21:21:11.000000000 -0800 +++ new/src/share/classes/java/awt/geom/IllegalPathStateException.java 2014-02-03 21:21:10.000000000 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1997, 1999, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -35,6 +35,8 @@ */ public class IllegalPathStateException extends RuntimeException { + private static final long serialVersionUID = -5158084205220481094L; + /** * Constructs an IllegalPathStateException with no * detail message. --- old/src/share/classes/java/awt/geom/NoninvertibleTransformException.java 2014-02-03 21:21:11.000000000 -0800 +++ new/src/share/classes/java/awt/geom/NoninvertibleTransformException.java 2014-02-03 21:21:11.000000000 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1997, 1999, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -33,6 +33,8 @@ */ public class NoninvertibleTransformException extends java.lang.Exception { + private static final long serialVersionUID = 6137225240503990466L; + /** * Constructs an instance of * NoninvertibleTransformException --- old/src/share/classes/java/awt/image/ImagingOpException.java 2014-02-03 21:21:12.000000000 -0800 +++ new/src/share/classes/java/awt/image/ImagingOpException.java 2014-02-03 21:21:12.000000000 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1997, 1998, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -32,6 +32,7 @@ * process the image. */ public class ImagingOpException extends java.lang.RuntimeException { + private static final long serialVersionUID = 8026288481846276658L; /** * Constructs an ImagingOpException object with the --- old/src/share/classes/java/awt/image/RasterFormatException.java 2014-02-03 21:21:13.000000000 -0800 +++ new/src/share/classes/java/awt/image/RasterFormatException.java 2014-02-03 21:21:13.000000000 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1997, 1998, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -31,6 +31,7 @@ * invalid layout information in the {@link Raster}. */ public class RasterFormatException extends java.lang.RuntimeException { + private static final long serialVersionUID = 96598996116164315L; /** * Constructs a new RasterFormatException with the --- old/src/share/classes/java/awt/image/renderable/ParameterBlock.java 2014-02-03 21:21:13.000000000 -0800 +++ new/src/share/classes/java/awt/image/renderable/ParameterBlock.java 2014-02-03 21:21:13.000000000 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1998, 2004, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1998, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -93,6 +93,8 @@ * * */ public class ParameterBlock implements Cloneable, Serializable { + private static final long serialVersionUID = -7577115551785240750L; + /** A Vector of sources, stored as arbitrary Objects. */ protected Vector