[cp-patches] [generics] Patch: FYI: genericization fixes
I'm checking this in on the generics branch.
After the recent merge to the branch, we needed a couple minor
genericization fixes.
Tom
2006-01-14 Tom Tromey <[EMAIL PROTECTED]>
* javax/swing/text/html/HTMLDocument.java (parseBuffer): Genericized.
* javax/swing/text/StyleContext.java (removeAttributes): Genericized.
* java/beans/PersistenceDelegate.java (initialize): Genericized.
* java/beans/Encoder.java (getPersistenceDelegate): Genericized.
(setPersistenceDelegate): Likewise.
Index: java/beans/Encoder.java
===
RCS file: /cvsroot/classpath/classpath/java/beans/Encoder.java,v
retrieving revision 1.1.2.1
diff -u -r1.1.2.1 Encoder.java
--- java/beans/Encoder.java 10 Jan 2006 15:59:40 - 1.1.2.1
+++ java/beans/Encoder.java 16 Jan 2006 00:45:36 -
@@ -212,7 +212,7 @@
return exceptionListener;
}
- public PersistenceDelegate getPersistenceDelegate(Class type)
+ public PersistenceDelegate getPersistenceDelegate(Class type)
{
// This is not specified but the JDK behaves like this.
if (type == null)
@@ -246,7 +246,8 @@
* access is thread safe.
*
*/
- public void setPersistenceDelegate(Class type, PersistenceDelegate delegate)
+ public void setPersistenceDelegate(Class type,
+ PersistenceDelegate delegate)
{
// If the argument is null this will cause a NullPointerException
// which is expected behavior.
Index: java/beans/PersistenceDelegate.java
===
RCS file: /cvsroot/classpath/classpath/java/beans/PersistenceDelegate.java,v
retrieving revision 1.1.2.1
diff -u -r1.1.2.1 PersistenceDelegate.java
--- java/beans/PersistenceDelegate.java 10 Jan 2006 15:59:40 - 1.1.2.1
+++ java/beans/PersistenceDelegate.java 16 Jan 2006 00:45:36 -
@@ -52,8 +52,8 @@
public abstract class PersistenceDelegate
{
- protected void initialize(Class type, Object oldInstance, Object newInstance,
-Encoder out)
+ protected void initialize(Class type, Object oldInstance,
+Object newInstance, Encoder out)
{
if (type != Object.class)
{
Index: javax/swing/text/StyleContext.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/text/StyleContext.java,v
retrieving revision 1.2.2.10
diff -u -r1.2.2.10 StyleContext.java
--- javax/swing/text/StyleContext.java 10 Jan 2006 15:59:43 - 1.2.2.10
+++ javax/swing/text/StyleContext.java 16 Jan 2006 00:45:37 -
@@ -673,7 +673,7 @@
return removeAttributes(old, attributes.getAttributeNames());
}
- public AttributeSet removeAttributes(AttributeSet old, Enumeration names)
+ public AttributeSet removeAttributes(AttributeSet old, Enumeration names)
{
if (old instanceof MutableAttributeSet)
{
Index: javax/swing/text/html/HTMLDocument.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/text/html/HTMLDocument.java,v
retrieving revision 1.1.2.4
diff -u -r1.1.2.4 HTMLDocument.java
--- javax/swing/text/html/HTMLDocument.java 10 Jan 2006 15:59:43 -
1.1.2.4
+++ javax/swing/text/html/HTMLDocument.java 16 Jan 2006 00:45:37 -
@@ -527,7 +527,7 @@
/** Holds the current character attribute set **/
protected MutableAttributeSet charAttr = new SimpleAttributeSet();
-protected Vector parseBuffer = new Vector();
+protected Vector parseBuffer = new Vector();
/** A stack for character attribute sets **/
Stack charAttrStack = new Stack();
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] [generics] FYI: New Instrumentation parameter to VMInstrumentationImpl.redefineClasses
Hi Nicolas, On Sun, 2006-01-15 at 13:58 +0100, Nicolas Geoffray wrote: > OK, I thought the generics branch was the equivalent of the 1.5 branch > of sun. But if it's not the case, I have no problem commiting > instrumentation code to HEAD. I do have one question though : the (sun) > API of instrumentation has generics code (for example > http://java.sun.com/j2se/1.5.0/docs/api/java/lang/instrument/ClassDefinition.html), > > does it make sense (and I'm OK if you think it does) to modify the API > in order to fit for a non-generics code? It is probably easier to just have only the generic version on the branch for now. Otherwise you have to maintain (and merge) two slightly different versions. I assume that users that really want instrumentation will find a way to use the generic branch version (we do now release a snapshot of that). 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 (revised) for PR25202
On Jan 15, 2006, at 12:36 AM, Raif S. Naffah wrote: hello there, this is a revised version of the previous patch. the differences are: * Configuration: removed documentation. * GnuConfiguration: (processSecurityProperties) surrounded code in try/catch * `ConfigFileParser: fixed the top comment line. Great, I think this is fine to check in. Thanks for doing this! I suppose we still differ in opinion about permissions and access control, but it isn't a sore spot for me -- we need the code! i could not get logging happening so i kept the DEBUG statements. I'll try to take a look at that. I suspect that there may be something buggy/missing in our logging implementation, so the SystemLogger stuff doesn't work properly. ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] FYI: Render null as the empty cell in JTable
If the JTable model returns null, our recent implementation does not set
the value at all. The visible content
of such cell replicates the value of the adjacent cell. Sun's
implementation renders the null value as the
empty cell. With one user application I have observed the strange
content replication for the cells that should
be displayed as empty. This path sets the empty string value for the
renderer is such case, making our
behavior identical with Sun's.
2006-01-15 Audrius Meskauskas <[EMAIL PROTECTED]>
* javax/swing/table/DefaultTableCellRenderer.java
(getTableCellRendererComponent):
Render null as the empty cell.
Index: javax/swing/table/DefaultTableCellRenderer.java
===
RCS file:
/cvsroot/classpath/classpath/javax/swing/table/DefaultTableCellRenderer.java,v
retrieving revision 1.23
diff -u -r1.23 DefaultTableCellRenderer.java
--- javax/swing/table/DefaultTableCellRenderer.java 24 Nov 2005 20:26:35
- 1.23
+++ javax/swing/table/DefaultTableCellRenderer.java 15 Jan 2006 17:24:08
-
@@ -127,7 +127,8 @@
* Get the string value of the object and pass it to setText().
*
* @param table the JTable
- * @param value the value of the object
+ * @param value the value of the object. For the text content,
+ *null is rendered as an empty cell.
* @param isSelected is the cell selected?
* @param hasFocus has the cell the focus?
* @param row the row to render
@@ -146,6 +147,9 @@
return new JTextField(((JTextField)value).getText());
super.setText(value.toString());
}
+else
+ // null is rendered as an empty cell.
+ super.setText("");
setOpaque(true);
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] [FYI]: Patch for javax.print.attribute.standard package
Hi Wolfgang, On Fri, 2006-01-13 at 23:44 +0100, Wolfgang Baer wrote: > > It took me a while to realize what was going on here. I think a comment > > is in place (and how do you guarantee that all the other inner classes > > are registered? Like MediaSize.ISO.A4 for example.). > > All the static instances in the inner container classes like ISO or > OTHER should be automatically added as they are static. Or do I miss > something ? At least every instance is added as far as I can see. > > Evrything I do here is to call one instance of every container class > so it gets loaded and everyone of its static MediaSize objects are > instantiated. Should I put a comment here ? Please do. I see now how initializing one static field makes sure all static fields are initialized, but since I had to ask it wasn't immediately obvious (at least to me). > > Are you sure that every newly created MediaSize object should > > automagically be added to the mediaCache and not just the standard > > MediaSizes? I see there is no other method to register a new "standard" > > MediaSize, but adding it through the public constructor seems asking for > > confusion. > > The just commited mauve test "userClass" shows that user constructed > MediaSize subclass instances are added to the cache used by findMedia > and the other static methods. So I am think I am right here. I still think this is kind of strange. It means any user can "register" new MediaSizes even by accident. Please also add a good comment about this to the MediaSize constructor. Thanks, 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] [generics] RFC: Genericize return type in PrinterStateReasons
Hi,
Andrew John Hughes wrote:
On Sat, 2006-01-14 at 11:54 +0100, Wolfgang Baer wrote:
The patch looks fine to me; I think I already did some similiar edits on
this particular file when merging, so please make sure your patch is
against the latest version before committing.
Done.
Generally, I think these kind of edits are okay, but I'd save the
majority of it, where possible, to after the generics branch is
re-merged. There are cases where it has to be done, and I also don't
see any problem with fixing the bits that are part of the API (this is
especially important for those who worship JAPI). Additionally, it
could possibly catch the odd bug... though I've not seen it yet.
So I only committing the part of the API and just ignore the eclipse
warning for the stuff inside the method.
2006-01-15 Wolfgang Baer <[EMAIL PROTECTED]>
* javax/print/attribute/standard/PrinterStateReasons.java:
(printerStateReasonSet): Genericize the return type.
Thanks,
Wolfgang
Index: PrinterStateReasons.java
===
RCS file: /cvsroot/classpath/classpath/javax/print/attribute/standard/PrinterStateReasons.java,v
retrieving revision 1.2.2.5
diff -u -r1.2.2.5 PrinterStateReasons.java
--- PrinterStateReasons.java 10 Jan 2006 15:59:42 - 1.2.2.5
+++ PrinterStateReasons.java 15 Jan 2006 13:39:47 -
@@ -139,7 +139,7 @@
* @param severity the severity level for the constructed set.
* @return The set of printer state reasons.
*/
- public Set printerStateReasonSet(Severity severity)
+ public Set printerStateReasonSet(Severity severity)
{
if (severity == null)
throw new NullPointerException("severity is null");
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] [generics] RFC: Genericize return type in PrinterStateReasons
> "Andrew" == Andrew John Hughes <[EMAIL PROTECTED]> writes: Andrew> Generally, I think these kind of edits are okay, but I'd save the Andrew> majority of it, where possible, to after the generics branch is Andrew> re-merged. Generally speaking, outside of java.util I've been pretty much doing a shallow genericization -- only the API and not the contents. There are a few exceptions to this, but not many. My thinking here is, a shallow one makes merges simpler, and we can fix up all the warnings when we're closer to closing down the branch. However, as you are doing the merges, feel free to set the policy here to what is convenient for you. Andrew> Additionally, it Andrew> could possibly catch the odd bug... though I've not seen it yet. There was one bug on the trunk that was caught by inspection, but which would have been caught by genericization. I forget what it was exactly... something in ClassLoader or System or something like that. There were a number of javax.imageio bugs that were caught by genericization. I think that might be all I've found. I suspect that when we do the deeper genericization we may find a couple more. Tom ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] [generics] FYI: New Instrumentation parameter to VMInstrumentationImpl.redefineClasses
Andrew John Hughes wrote: Instrumentation is a 1.5 package feature. It's not part of the 1.4 specification. That's why the files are only in the branch. Nicolas But the branch isn't for 1.5 features as such. It's for stuff that will only compile when used with a compiler supporting the 1.5 features (generics, enums, annotations and a few bits of syntactic sugar). So, if you can actually compile and run all the instrumentation stuff with a 1.4 suite, it should be on HEAD, IMHO. At least, that was my understanding of this and why it's called a generics branch and not a 1.5 branch -- someone correct me if I'm wrong. There are quite a few 1.5 package features on HEAD already. OK, I thought the generics branch was the equivalent of the 1.5 branch of sun. But if it's not the case, I have no problem commiting instrumentation code to HEAD. I do have one question though : the (sun) API of instrumentation has generics code (for example http://java.sun.com/j2se/1.5.0/docs/api/java/lang/instrument/ClassDefinition.html), does it make sense (and I'm OK if you think it does) to modify the API in order to fit for a non-generics code? Nicolas ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] [generics] FYI: New Instrumentation parameter to VMInstrumentationImpl.redefineClasses
> "Andrew" == Andrew John Hughes <[EMAIL PROTECTED]> writes: Andrew> At least, that was my understanding of this and why it's Andrew> called a generics branch and not a 1.5 branch -- someone Andrew> correct me if I'm wrong. Yeah. It kinda started as an "all things 1.5" branch but quickly became a "things needing a 1.5 compiler" branch, since folks wanted new methods and classes on the trunk. Tom ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] patch (revised) for PR25202
hello there,
this is a revised version of the previous patch. the differences are:
* Configuration: removed documentation.
* GnuConfiguration: (processSecurityProperties) surrounded code in
try/catch
* `ConfigFileParser: fixed the top comment line.
i could not get logging happening so i kept the DEBUG statements.
cheers;
rsn
Index: ChangeLog
===
RCS file: /cvsroot/classpath/classpath/ChangeLog,v
retrieving revision 1.6064
diff -u -r1.6064 ChangeLog
--- ChangeLog 14 Jan 2006 11:14:43 - 1.6064
+++ ChangeLog 14 Jan 2006 20:03:38 -
@@ -1,3 +1,15 @@
+2006-01-15 Raif S. Naffah <[EMAIL PROTECTED]>
+
+ * gnu/javax/security/auth/login/ConfigFileTokenizer.java: New class.
+ * gnu/javax/security/auth/login/ConfigFileParser.java: New class.
+ * gnu/javax/security/auth/login/GnuConfiguration.java: New class.
+ * javax/security/auth/login/AppConfigurationEntry.java: Updated
+ copyright year.
+ (toString): Added method implementation.
+ (LoginModuleControlFlag.toString): Removed class name from result.
+ * javax/security/auth/login/Configuration.java: Updated copyright year.
+ (getConfig(): replaced calls to NullConfiguration with GnuConfiguration.
+
2006-01-14 Wolfgang Baer <[EMAIL PROTECTED]>
Fixes bug #25387
Index: ConfigFileParser.java
===
RCS file: ConfigFileParser.java
diff -N ConfigFileParser.java
--- /dev/null 1 Jan 1970 00:00:00 -
+++ ConfigFileParser.java 15 Jan 2006 05:39:16 -
@@ -0,0 +1,338 @@
+/* ConfigFileParser.java -- JAAS Login Configuration default syntax parser
+ Copyright (C) 2006 Free Software Foundation, Inc.
+
+This file is part of GNU Classpath.
+
+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.
+
+Linking this library statically or dynamically with other modules is
+making a combined work based on this library. Thus, the terms and
+conditions of the GNU General Public License cover the whole
+combination.
+
+As a special exception, the copyright holders of this library give you
+permission to link this library with independent modules to produce an
+executable, regardless of the license terms of these independent
+modules, and to copy and distribute the resulting executable under
+terms of your choice, provided that you also meet, for each linked
+independent module, the terms and conditions of the license of that
+module. An independent module is a module which is not derived from
+or based on this library. If you modify this library, you may extend
+this exception to your version of the library, but you are not
+obligated to do so. If you do not wish to do so, delete this
+exception statement from your version. */
+
+
+package gnu.javax.security.auth.login;
+
+import java.io.IOException;
+import java.io.Reader;
+import java.util.ArrayList;
+import java.util.HashMap;
+import java.util.List;
+import java.util.Map;
+
+import javax.security.auth.login.AppConfigurationEntry;
+
+/**
+ * A parser that knows how to interpret JAAS Login Module Configuration files
+ * written in the default syntax which is interpreted as adhering to
+ * the following grammar:
+ *
+ *
+ * CONFIG ::= APP_OR_OTHER_ENTRY+
+ * APP_OR_OTHER_ENTRY ::= APP_NAME_OR_OTHER JAAS_CONFIG_BLOCK
+ * APP_NAME_OR_OTHER ::= APP_NAME
+ * | 'other'
+ * JAAS_CONFIG_BLOCK ::= '{' (LOGIN_MODULE_ENTRY ';')+ '}' ';'
+ * LOGIN_MODULE_ENTRY ::= MODULE_CLASS FLAG MODULE_OPTION* ';'
+ * FLAG::= 'required'
+ * | 'requisite'
+ * | 'sufficient'
+ * | 'optional'
+ * MODULE_OPTION ::= PARAM_NAME '=' PARAM_VALUE
+ *
+ * APP_NAME ::= JAVA_IDENTIFIER
+ * MODULE_CLASS ::= JAVA_IDENTIFIER ('.' JAVA_IDENTIFIER)*
+ * PARAM_NAME ::= STRING
+ * PARAM_VALUE ::= '"' STRING '"' | ''' STRING ''' | STRING
+ *
+ *
+ * This parser handles UTF-8 entities when used as APP_NAME and PARAM_VALUE.
+ * It also checks for the use of Java identifiers used in MODULE_CLASS, thus
+ * minimizing the risks of having [EMAIL PROTECTED] java.lang.ClassCastException}s thrown
+ * at runtime due to syntactically invalid names.
+ *
+ * In the above context, a JAVA_IDENTIFIER is a sequence of tokens,
+ * separated
