Re: [cp-patches] Patch: Implementing non-abstract members on abstract X509Certificate and correcting GeneralName OtherName parsing
On Dec 1, 2005, at 8:05 AM, Rafael Teixeira wrote: 2005-12-01 Rafael Teixeira <[EMAIL PROTECTED]> * gnu/java/security/der/DERValue.java Clearer information returned by toString() to help debugging * gnu/java/security/x509/ext/GeneralNames.java Fix the parsing of the OtherName choice and the tagClass checking * gnu/java/security/x509/X509Certificate.java Static helpers to retrofit inheritable behaviour on the once (before 1.4) purely abstract superclass. BouncyCastle X509 certificates, for example, depend on this inherited behaviour to work properly * java/security/cert/X509Certificate.java 2005-10-19 18:37:16.0 -0200 Implement added non-abstract behaviour by delegating to gnu.java.security.x509.X509Certificate This patch looks good to me. Do you have a copyright assignment on file for Classpath? ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Patch: fix alsa configury for systems with multilibs
Hi Anthony, On Thu, 2005-12-01 at 08:59 -0800, Anthony Green wrote: > It's not enough to test that the alsa headers exist. We also need to > make sure the libraries are there. > > 2005-12-01 Anthony Green <[EMAIL PROTECTED]> > >* configure.ac: Make sure we have an alsa library in addition to >the headers. This extra test is required for systems with >multilibs. >* configure: Rebuilt. > > Ok for everywhere? Looks fine to me. (Note that configure isn't in CVS for classpath.) 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] FYI: Removed javaio from CVS.
Hi, On Sat, 2005-11-26 at 14:25 +0100, Guilhem Lavaux wrote: > It looks like javaio.[ch] is unused. So I am removing these files. Thanks, you are right. All this functionality moved to the nio implementation. Note to others, you do need te rerun autogen.sh after updating with this change 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] [generics] RFC : implementation of jjava.lang.instrument package
Hi Nicolas,
On Thu, 2005-12-01 at 17:51 +0100, Nicolas Geoffray wrote:
> >Also if something went wrong with the transformation
> >of any of them we might want to have a cancelRedefineClass() to let
> the
> >VM know we won't be applying any prepared classes.
> >
> I had in mind that the VM wouldn't need a cancel method. The
> prepareRedefineClass gives a vm internal representation
> of a class, and if redefinition is canceled this representation would
> be garbage collected and forgotten by the vm. But maybe some vm
> would like to be noticed. I added the method since it might be
> usefull.
My idea was even that a VM might only want to have one redefine
prepare/apply cycle running at the same time. Then it can easily cleanup
anything not used. But this might be optimizing for an unusual case. We
can probably assume that transformers will actually transform correctly.
> >Why does the private callTransformers() implementation take a
> >ProtectionDomain? Isn't that
> classBeingRedefined.getProtectionDomain()?
> >
> Yes, but the classBeingRedefined might be null, if the method is
> called
> by the vm from the native ClassLoader.defineClass method. Therefore,
> the vm gives as arguments the protectionDomain it has.
Aha. Sorry I missed the dual nature of the
ClassFileTransFormer.transform() method. I see you documented this in
your original patch. In that case I really do think we should move these
to vm/reference/java/lang and make this method package private.
> >Normally we like to provide some default/noop implementation for the
> VM
> >reference classes. Is it possible to provide the necessary hooks in
> >ClassLoader/VMClassLoader to call the transformers just before
> >defineClass() is called?
> >
> It's possible, but it could break all existing vms lying on the vm
> reference classes.
> The VMClassLoader would need an extra defineClass method and an extra
> field
> for an InstrumentationImpl object. The extra defineClass method would
> check if the
> InstrumentationImpl is null and if not, call the
> InstrumentationImpl.callTransformers
> method.
Right, I see we need to break the VM interface for this :{
Probably best not to do that for the first release (0.20) but lets
suggest how we would like to change the interface for 0.21 so runtime
implementers can prepare and scream about it. On the other hand this is
the generics branch only, not very many VMs depend on it yet. But not
very urgent I guess before we have this working with at least one VM.
> Yeah, documentation to write! :). I will create a documentation file
> for the java.lang.instrument package,
> and change the vm integration guide (should I create a new paragraph
> for generics?)
Just make a new paragraph for Instrumentation. Then mention that it
currently only is on the generics branch since it uses some new language
features.
Cheers,
Mark
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] Patch: fix alsa configury for systems with multilibs
It's not enough to test that the alsa headers exist. We also need to
make sure the libraries are there. This was a problem for x86-64 linux.
Ok for everywhere?
AG
2005-12-01 Anthony Green <[EMAIL PROTECTED]>
* configure.ac: Make sure we have an alsa library in addition to
the headers. This extra test is required for systems with
multilibs.
* configure: Rebuilt.
Index: libjava/classpath/configure.ac
===
--- libjava/classpath/configure.ac (revision 107822)
+++ libjava/classpath/configure.ac (working copy)
@@ -112,7 +112,9 @@
no) COMPILE_ALSA=no ;;
*) COMPILE_ALSA=yes ;;
esac],
- [AC_CHECK_HEADERS([alsa/asoundlib.h],COMPILE_ALSA=yes,COMPILE_ALSA=no)])
+ [AC_CHECK_HEADERS([alsa/asoundlib.h],
+[AC_CHECK_LIB([asound], [snd_seq_open], COMPILE_ALSA=yes,COMPILE_ALSA=no)],
+COMPILE_ALSA=no)])
AM_CONDITIONAL(CREATE_ALSA_LIBRARIES, test "x${COMPILE_ALSA}" = xyes)
dnl ---
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] [generics] RFC : implementation of jjava.lang.instrument package
Hi Mark Mark Wielaard wrote: Hi Nicolas, On Mon, 2005-11-28 at 19:08 +0100, Nicolas Geoffray wrote: Here's two files, InstrumentationImpl and VMInstrumentationImpl. I put all native vm specific methods in VMInstrumentationImpl, but if you think it's not necessary, it's ok with me to have all these methods in InstrumentationImpl. This looks pretty good. Thanks! Some comments and questions: InstrumentationImpl should implement Instrumentation (then a couple of methods need to be made public). Oops, so obvious that I forgot it :) I believe the Vector of transformaers is handled correctly even when manipulated by multiple threads. But I like using an ArrayList and Iterator and do explicit synchronization (but in this case that is clearly just a personal preference, so feel free to ignore if you disagree that it is clearer.) OK for an ArrayList, it's just that I'm not really used to generics and Vector seemed easier How atomic do we want applyRedefineClasses() to be? Instead of looping through all classes to redefine and calling applyRedefineClass() on each one, it might be a good idea to have an applyRedefineClasses(Object[]) in VMInstrumentationImpl to redefine them all at the same time after preparing them all. You're right. It's better to apply them all. Also if something went wrong with the transformation of any of them we might want to have a cancelRedefineClass() to let the VM know we won't be applying any prepared classes. I had in mind that the VM wouldn't need a cancel method. The prepareRedefineClass gives a vm internal representation of a class, and if redefinition is canceled this representation would be garbage collected and forgotten by the vm. But maybe some vm would like to be noticed. I added the method since it might be usefull. Why does the private callTransformers() implementation take a ProtectionDomain? Isn't that classBeingRedefined.getProtectionDomain()? Yes, but the classBeingRedefined might be null, if the method is called by the vm from the native ClassLoader.defineClass method. Therefore, the vm gives as arguments the protectionDomain it has. About the calltransformers FIXME. What else can/should we do here? I have no idea for now : the description of Sun doesn't specify which behaviour sould be adopted. At first I wanted to skip the transformer that raises the exception. But then, it might be the transformer called before that returned an illegal class. And so on. We can know if the byte[] given is correct by forcing the vm to read it, but that would not be efficient. I chose to return the initial byte[], because I didn't want to make assumptions on how to treat transformers. I should do some tests with the sun implementation :) Normally we like to provide some default/noop implementation for the VM reference classes. Is it possible to provide the necessary hooks in ClassLoader/VMClassLoader to call the transformers just before defineClass() is called? It's possible, but it could break all existing vms lying on the vm reference classes. The VMClassLoader would need an extra defineClass method and an extra field for an InstrumentationImpl object. The extra defineClass method would check if the InstrumentationImpl is null and if not, call the InstrumentationImpl.callTransformers method. The extra field can only be set by the command parsing method, because it's created when an instrument agent is created. If we do this wouldn't it be slightly easier to have all these classes in vm/reference/java/lang to make package access easier? Probably. I have set private the callTransformers method, but it could be set protected. An example how this is all supposed to work together when a VM implements this VM interface would be nice. I could propose something with my vm (jnjvm). But I have to make sure the generics branch works with it :) Also to make clear whether the premain() method is an instance of static method, what command line extensions/flags are expected, etc. Yeah, documentation to write! :). I will create a documentation file for the java.lang.instrument package, and change the vm integration guide (should I create a new paragraph for generics?) Cheers, Nicolas ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] Re: Patch: Implementing non-abstract members on abstract X509Certificate and correcting GeneralName OtherName parsing
Sorry I hit the send buttom a bit to early, hope it can be grokked Rafael Teixeira ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] Patch: Implementing non-abstract members on abstract X509Certificate and correcting GeneralName OtherName parsing
2005-12-01 Rafael Teixeira <[EMAIL PROTECTED]>
* gnu/java/security/der/DERValue.java
Clearer information returned by toString() to help debugging
* gnu/java/security/x509/ext/GeneralNames.java
Fix the parsing of the OtherName choice and the tagClass checking
* gnu/java/security/x509/X509Certificate.java
Static helpers to retrofit inheritable behaviour on the once
(before 1.4) purely
abstract superclass. BouncyCastle X509 certificates, for
example, depend on
this inherited behaviour to work properly
* java/security/cert/X509Certificate.java 2005-10-19
18:37:16.0 -0200
Implement added non-abstract behaviour by delegating to
gnu.java.security.x509.X509Certificate
On 11/30/05, Anthony Balkissoon <[EMAIL PROTECTED]> wrote:
> I implemented missing parts and improved other parts of
> JFormattedTextField. The changes are accompanied by the following Mauve
> test:
>
> gnu.testlet.javax.swing.JFormattedTextField.JFormattedTextFieldTests
>
> More to come, as JFormattedTextField is still quite buggy.
>
>
> 2005-11-30 Anthony Balkissoon <[EMAIL PROTECTED]>
>
> * javax/swing/JFormattedTextField.java:
> (AbstractFormatter.install): Try to set the text of the formatted text
> field using this formatter.
> (FormatterFactoryWrapper): Removed this unneeded class, this is
> handled
> by DefaultFormatterFactory now.
> (formatter): New field.
> (JFormattedTextField(Format)): Implemented.
> (JFormattedTextField(AbstractFormatter)): Instantiate a
> DefaultFormatterFactory instead of a FormatterFactoryWrapper.
> (JFormattedTextField(AbstractFormatterFactory, Object)): Call setValue
> and setFormatterFactory instead of setting variables directly because
> more needs to be done than just setting the value of the variables.
> (JFormattedTextField(Object value)): Call setValue instead of setting
> the variable directly.
> (getAppropriateFormatterFactory): New implementation method.
> (getFormatter): Don't use the formatter factory here, just return
> the cached formatter.
> (processFocusEvent): Set the formatter to the appropriate one as
> determined by the formatter factory.
> (setFormatter): Don't get the old formatter from the factory, just use
> the cached formatter. Uninstall the old formatter. Install the new
> formatter. Cache the new formatter. Don't create a new formatter
> factory.
> (setFormatterFactory): Set the formatter according to the new
> formatter
> factory.
> (setValue): Moved the setting of the value variable to above the call
> to createFormatter so that an appropriate formatter is created. Cache
> the formatter that is created.
> (createFormatter): If argument is a Number, use a NumberFormatter.
> * javax/swing/text/DefaultFormatter.java:
> (valueToString): If argument is null return empty String.
>
> --Tony
>
>
> ___
> Classpath-patches mailing list
> Classpath-patches@gnu.org
> http://lists.gnu.org/mailman/listinfo/classpath-patches
>
>
>
>
--
Rafael "Monoman" Teixeira
---
I'm trying to become a "Rosh Gadol" before my own eyes.
See http://www.joelonsoftware.com/items/2004/12/06.html for enlightment.
It hurts!
--- gnu/java/security/der/DERValue.java 2005-10-19 18:36:35.0 -0200
+++ classpath-nexus/gnu/java/security/der/DERValue.java 2005-11-30 00:06:24.0 -0200
@@ -38,6 +38,8 @@
package gnu.java.security.der;
+import gnu.java.security.x509.Util;
+
import java.io.ByteArrayOutputStream;
import java.io.IOException;
@@ -164,7 +166,18 @@
public String toString()
{
-return "DERValue [ tag=" + tag + ", class=" + tagClass + ", constructed="
- + constructed + ", value=" + value + " ]";
+String start = "DERValue ( [";
+if (tagClass == DER.UNIVERSAL)
+ start = start + "UNIVERSAL ";
+else if (tagClass == DER.PRIVATE)
+ start = start + "PRIVATE ";
+else if (tagClass == DER.APPLICATION)
+ start = start + "APPLICATION ";
+start = start + tag + "] constructed=" + constructed + ", value=";
+if (constructed)
+ start = start + "\n" + Util.hexDump(getEncoded(), "\t");
+else
+ start = start + value;
+return start + " )";
}
}
--- gnu/java/security/x509/ext/GeneralNames.java 2005-10-19 18:36:37.0 -0200
+++ classpath-nexus/gnu/java/security/x509/ext/GeneralNames.java 2005-11-30 00:32:43.0 -0200
@@ -81,12 +81,14 @@
if (!nameList.isConstructed())
throw new IOException("malformed GeneralNames");
int len = 0;
+int i = 0;
while (len < nameList.getLength())
{
DERValue name = der.read();
List namePair = new ArrayList(2);
-if (name.getTagClass() != DER.APPLICATION)
- t
Re: [cp-patches] [generics] RFC : implementation of jjava.lang.instrument package
Hi Nicolas, On Mon, 2005-11-28 at 19:08 +0100, Nicolas Geoffray wrote: > Here's two files, InstrumentationImpl and VMInstrumentationImpl. > I put all native vm specific methods in VMInstrumentationImpl, but > if you think it's not necessary, it's ok with me to have all these methods > in InstrumentationImpl. This looks pretty good. Thanks! Some comments and questions: InstrumentationImpl should implement Instrumentation (then a couple of methods need to be made public). I believe the Vector of transformaers is handled correctly even when manipulated by multiple threads. But I like using an ArrayList and Iterator and do explicit synchronization (but in this case that is clearly just a personal preference, so feel free to ignore if you disagree that it is clearer.) How atomic do we want applyRedefineClasses() to be? Instead of looping through all classes to redefine and calling applyRedefineClass() on each one, it might be a good idea to have an applyRedefineClasses(Object[]) in VMInstrumentationImpl to redefine them all at the same time after preparing them all. Also if something went wrong with the transformation of any of them we might want to have a cancelRedefineClass() to let the VM know we won't be applying any prepared classes. Why does the private callTransformers() implementation take a ProtectionDomain? Isn't that classBeingRedefined.getProtectionDomain()? About the calltransformers FIXME. What else can/should we do here? Normally we like to provide some default/noop implementation for the VM reference classes. Is it possible to provide the necessary hooks in ClassLoader/VMClassLoader to call the transformers just before defineClass() is called? If we do this wouldn't it be slightly easier to have all these classes in vm/reference/java/lang to make package access easier? An example how this is all supposed to work together when a VM implements this VM interface would be nice. Also to make clear whether the premain() method is an instance of static method, what command line extensions/flags are expected, etc. Cheers, Mark ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] [generics] Patch: FYI: genericize javax.imageio
I'm checking this in on the generics branch.
This genericizes javax.imageio. There are a couple minor bug fixes
that were found when doing this.
I think this is the last set of packages that needed to be
genericized.
Tom
2005-12-01 Tom Tromey <[EMAIL PROTECTED]>
* javax/imageio/spi/RegisterableService.java (onRegistration):
Genericized.
(onDeregistration): Likewise.
* javax/imageio/spi/ServiceRegistry.java (ServiceRegistry):
Genericized.
(deregisterServiceProvider): Likewise.
(getCategories): Likewise.
(getServiceProviderByClass): Likewise.
(getServiceProviders): Likewise.
(lookupProviders): Likewise.
(registerServiceProvider): Likewise.
(registerServiceProviders): Likewise.
(setOrdering): Likewise.
(unsetOrdering): Likewise.
* javax/imageio/spi/ImageOutputStreamSpi.java (outputClass):
Genericized.
(ImageOutputStreamSpi): Likewise.
(getOutputClass): Likewise.
* javax/imageio/spi/ImageInputStreamSpi.java (inputClass):
Genericized.
(ImageInputStreamSpi): Likewise.
(getInputClass): Likewise.
* javax/imageio/metadata/IIOMetadataFormatImpl.java (addAttribute):
Genericized.
(addObjectValue): Likewise.
* javax/imageio/metadata/IIOMetadataFormat.java (getObjectClass):
Genericized.
(getObjectMaxValue): Likewise.
(getObjectMinValue): Likewise.
* javax/imageio/ImageIO.java (getImageReaders): Genericized.
(getImageReadersByFormatName): Likewise.
(getImageReadersByMIMEType): Likewise.
(getImageTranscoders): Likewise.
(getImageWritersByFormatName): Likewise.
(getImageWritersByMIMEType): Likewise.
(getImageWritersBySuffix): Likewise.
(getImageReader): Use getOriginatingProvider.
(getImageWriter): Likewise.
* javax/imageio/ImageWriter.java (progressListeners): Genericized.
(warningListeners): Likewise.
(warningLocales): Likewise.
(prepareInsertEmpty): Likewise.
(prepareWriteEmpty): Likewise.
* javax/imageio/ImageReader.java (progressListeners): Genericized.
(updateListeners): Likewise.
(warningListeners): Likewise.
(warningLocales): Likewise.
(getDestination): Likewise.
(getImageMetadata): Likewise.
(getImageTypes): Likewise.
(getStreamMetadata): Likewise.
(readAll): Likewise.
* javax/imageio/IIOImage.java (IIOImage): Genericized.
(thumbnails): Likewise.
(getThumbnails): Likewise.
(setThumbnails): Likewise.
Index: javax/imageio/IIOImage.java
===
RCS file: /cvsroot/classpath/classpath/javax/imageio/IIOImage.java,v
retrieving revision 1.1.2.3
diff -u -r1.1.2.3 IIOImage.java
--- javax/imageio/IIOImage.java 2 Nov 2005 00:43:38 - 1.1.2.3
+++ javax/imageio/IIOImage.java 1 Dec 2005 14:59:21 -
@@ -79,8 +79,7 @@
/**
* A list of BufferedImage thumbnails of this image.
*/
- // for 1.5 these lists are List
- protected List thumbnails;
+ protected List thumbnails;
/**
* Construct an IIOImage containing raster image data, thumbnails
@@ -92,7 +91,8 @@
*
* @exception IllegalArgumentException if raster is null
*/
- public IIOImage (Raster raster, List thumbnails, IIOMetadata metadata)
+ public IIOImage (Raster raster, List thumbnails,
+ IIOMetadata metadata)
{
if (raster == null)
throw new IllegalArgumentException ("raster may not be null");
@@ -112,7 +112,8 @@
*
* @exception IllegalArgumentException if image is null
*/
- public IIOImage (RenderedImage image, List thumbnails, IIOMetadata metadata)
+ public IIOImage (RenderedImage image, List
thumbnails,
+ IIOMetadata metadata)
{
if (image == null)
throw new IllegalArgumentException ("image may not be null");
@@ -192,7 +193,7 @@
*
* @return a list of thumbnails or null
*/
- public List getThumbnails()
+ public List getThumbnails()
{
return thumbnails;
}
@@ -260,7 +261,7 @@
*
* @param thumbnails a new list of thumbnails or null
*/
- public void setThumbnails (List thumbnails)
+ public void setThumbnails (List thumbnails)
{
this.thumbnails = thumbnails;
}
Index: javax/imageio/ImageIO.java
===
RCS file: /cvsroot/classpath/classpath/javax/imageio/ImageIO.java,v
retrieving revision 1.4.2.7
diff -u -r1.4.2.7 ImageIO.java
--- javax/imageio/ImageIO.java 2 Nov 2005 00:43:38 - 1.4.2.7
+++ javax/imageio/ImageIO.java 1 Dec 2005 14:59:22 -
@@ -436,7 +436,7 @@
*
* @exception IllegalArgumentException if formatName is null
*/
- public static Iterator getImageReadersByFormatName(String formatName)
+ public static Iterator ge
