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] 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)
- throw new IOException(malformed GeneralName);
+int tagClass = name.getTagClass();
+
[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: 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 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
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] 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] 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
