[cp-patches] State of Jikes RVM patches waiting to go into Classpath
Hi, currently there are 3 patches waiting to go into GNU Classpath from Jikes RVM: 1) Thread Local improvements: http://jira.codehaus.org/browse/RVM-185 http://jikesrvm.svn.sourceforge.net/viewvc/jikesrvm/rvmroot/trunk/build/components/patches/classpath-cvs.RVM-185.patch?revision=13369view=markup I believe this is stalled waiting for Daniel's FSF paper work. This patch would be a big performance win for many VMs. 2) ZipEntry improvements: http://jira.codehaus.org/browse/RVM-392 http://jikesrvm.svn.sourceforge.net/viewvc/jikesrvm/rvmroot/trunk/build/components/patches/classpath-cvs.RVM-392.patch?revision=14005view=markup This patch cleans up the use of Calendar in ZipEntry and avoids unnecessary bouncing between UNIX and DOS time formats. Possible bootstrap issues were raised by Tom Tromey, so the patch is still pending. Here's the e-mail thread: http://www.nabble.com/RFC%3A-tweaks-to-java.util.zip.ZipEntry-to15289313.html#a15289313 3) AIX build fix: http://jira.codehaus.org/browse/RVM-526 http://jikesrvm.svn.sourceforge.net/viewvc/jikesrvm/rvmroot/trunk/build/components/patches/classpath-cvs.RVM-526.patch?revision=14551view=markup This is a small patch that fixes a problem for builds on AIX, I believe it would be safe to commit it. I'd like to push these patches up stream. For 2 and 3 please could people complain if they think they are an issue for their VM, I believe they are both steps in the right direction. For 1 could someone chase up the paper work? Thanks, Ian Rogers
Re: [cp-patches] [rvm-core] State of Jikes RVM patches waiting to go into Classpath
On 18/08/2008, Ian Rogers [EMAIL PROTECTED] wrote: Hi, currently there are 3 patches waiting to go into GNU Classpath from Jikes RVM: Note that 0.98 is very imminent i.e. I'd like it to be released this week and most of it has already been merged to GCJ. 1) Thread Local improvements: http://jira.codehaus.org/browse/RVM-185 http://jikesrvm.svn.sourceforge.net/viewvc/jikesrvm/rvmroot/trunk/build/components/patches/classpath-cvs.RVM-185.patch?revision=13369view=markup I believe this is stalled waiting for Daniel's FSF paper work. This patch would be a big performance win for many VMs. The assignment is still pending. The last e-mail I have is Daniel's assignment form on 11th June. I've pinged to see what's going on. 2) ZipEntry improvements: http://jira.codehaus.org/browse/RVM-392 http://jikesrvm.svn.sourceforge.net/viewvc/jikesrvm/rvmroot/trunk/build/components/patches/classpath-cvs.RVM-392.patch?revision=14005view=markup This patch cleans up the use of Calendar in ZipEntry and avoids unnecessary bouncing between UNIX and DOS time formats. Possible bootstrap issues were raised by Tom Tromey, so the patch is still pending. Here's the e-mail thread: http://www.nabble.com/RFC%3A-tweaks-to-java.util.zip.ZipEntry-to15289313.html#a15289313 I'm sceptical about committing this one for 0.98 if there may be issues. I assume the gain is it not using a synchronized method to initialise the Calendar? Have you considered the initialization on demand holder idiom instead? http://en.wikipedia.org/wiki/Initialization_on_demand_holder_idiom It's also mentioned in the JSR166 book by Doug Lea et. al. I can see why initialising Calendar as a prerequisite for zip support might cause a lot of problems and I don't think we have time to test it well enough for this release. 3) AIX build fix: http://jira.codehaus.org/browse/RVM-526 http://jikesrvm.svn.sourceforge.net/viewvc/jikesrvm/rvmroot/trunk/build/components/patches/classpath-cvs.RVM-526.patch?revision=14551view=markup This is a small patch that fixes a problem for builds on AIX, I believe it would be safe to commit it. I think I've seen this before. Seems fine. Can you forward it for discussion on cp-patches? I'd like to push these patches up stream. For 2 and 3 please could people complain if they think they are an issue for their VM, I believe they are both steps in the right direction. For 1 could someone chase up the paper work? Thanks, Ian Rogers - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Jikesrvm-core mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jikesrvm-core -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: [cp-patches] [rvm-core] State of Jikes RVM patches waiting to go into Classpath
On 18/08/2008, Ian Rogers [EMAIL PROTECTED] wrote: Thanks Andrew, Andrew John Hughes wrote: On 18/08/2008, Ian Rogers [EMAIL PROTECTED] wrote: Hi, currently there are 3 patches waiting to go into GNU Classpath from Jikes RVM: Note that 0.98 is very imminent i.e. I'd like it to be released this week and most of it has already been merged to GCJ. 1) Thread Local improvements: http://jira.codehaus.org/browse/RVM-185 http://jikesrvm.svn.sourceforge.net/viewvc/jikesrvm/rvmroot/trunk/build/components/patches/classpath-cvs.RVM-185.patch?revision=13369view=markup I believe this is stalled waiting for Daniel's FSF paper work. This patch would be a big performance win for many VMs. The assignment is still pending. The last e-mail I have is Daniel's assignment form on 11th June. I've pinged to see what's going on. Great! Getting this into 0.98 would be a real feature. I hope your luck's in then and the assignment has been done... :) 2) ZipEntry improvements: http://jira.codehaus.org/browse/RVM-392 http://jikesrvm.svn.sourceforge.net/viewvc/jikesrvm/rvmroot/trunk/build/components/patches/classpath-cvs.RVM-392.patch?revision=14005view=markup This patch cleans up the use of Calendar in ZipEntry and avoids unnecessary bouncing between UNIX and DOS time formats. Possible bootstrap issues were raised by Tom Tromey, so the patch is still pending. Here's the e-mail thread: http://www.nabble.com/RFC%3A-tweaks-to-java.util.zip.ZipEntry-to15289313.html#a15289313 I'm sceptical about committing this one for 0.98 if there may be issues. I assume the gain is it not using a synchronized method to initialise the Calendar? Have you considered the initialization on demand holder idiom instead? http://en.wikipedia.org/wiki/Initialization_on_demand_holder_idiom It's also mentioned in the JSR166 book by Doug Lea et. al. I can see why initialising Calendar as a prerequisite for zip support might cause a lot of problems and I don't think we have time to test it well enough for this release. Sorry, this change is a bit more involved than initialization on demand. Basically the normal use for a ZipEntry is for reading. In the current code to read an entry we must also convert the date (that is in DOS form in a ZIP) into a canonical unix time form, hence the requirement for a Calendar (and boot strap problems if the Calendar is in the zip). The main point of the patch is that we only really need the canonical time if we are writing the ZipEntry or if someone is querying it, in such a circumstance calling Calendar.getInstance() is fine and any caching can be done there. The patch is necessary for Jikes RVM as it avoids a boot strap issue (we don't need a Calendar to be in the boot image before we start reading a zip). I *really* don't want Calendars in Jikes RVM's boot image as I have to hand code conversion code between the different JDK and Classpath formats, hence initialization on demand is definitely not a solution. This patch is a good thing in my opinion and hasn't caused any issues for Jikes RVM, I would like to see it included in 0.98. It will help other VMs with the same bootstrap issue. Your discussion made no sense at first, until I realised you were linking to your first attempt at a patch. The real one is completely different: http://www.nabble.com/Re%3A-RFC%3A-tweaks-to-java.util.zip.ZipEntry-p15331002.html and now your comments make sense... ;) Have you tested with any other VMs? 3) AIX build fix: http://jira.codehaus.org/browse/RVM-526 http://jikesrvm.svn.sourceforge.net/viewvc/jikesrvm/rvmroot/trunk/build/components/patches/classpath-cvs.RVM-526.patch?revision=14551view=markup This is a small patch that fixes a problem for builds on AIX, I believe it would be safe to commit it. I think I've seen this before. Seems fine. Can you forward it for discussion on cp-patches? Maybe Dave can, he's assigned the issue to himself. The patch seems trivial enough, just breaking the process up presumably due to resource constraints on AIX. But I don't think it has been posted to the Classpath list at all so far. Thanks, Ian -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
[cp-patches] RFC: AIX build fix - paths too long in check_jni.sh
Dave Grove fixed an AIX build issue for the Jikes RVM with the attached patch. Jikes RVM tracker here: http://jira.codehaus.org/browse/RVM-526 Regards, Ian Rogers Index: scripts/check_jni_methods.sh.in === RCS file: /sources/classpath/classpath/scripts/check_jni_methods.sh.in,v retrieving revision 1.5 diff -u -r1.5 check_jni_methods.sh.in --- scripts/check_jni_methods.sh.in 11 Jun 2008 21:37:49 - 1.5 +++ scripts/check_jni_methods.sh.in 23 Jun 2008 20:03:20 - @@ -6,12 +6,16 @@ TMPFILE=/tmp/check-jni-methods.$$.1 TMPFILE2=/tmp/check-jni-methods.$$.2 TMPFILE3=/tmp/check-jni-methods.$$.3 +TMPFILE4=/tmp/check-jni-methods.$$.4 # Find all methods defined in the header files generated # from the java source files. -grep -h '^JNIEXPORT .* Java_' @abs_top_builddir@/include/*.h @abs_top_srcdir@/include/*.h | \ -LC_ALL=C sed -e 's,.*JNICALL \(Java_[a-z_A-Z0-9]*\).*$,\1,' | \ - sort -u $TMPFILE +grep -h '^JNIEXPORT .* Java_' @abs_top_srcdir@/include/*.h | \ +LC_ALL=C sed -e 's,.*JNICALL \(Java_[a-z_A-Z0-9]*\).*$,\1,' $TMPFILE +grep -h '^JNIEXPORT .* Java_' @abs_top_builddir@/include/*.h | \ +LC_ALL=C sed -e 's,.*JNICALL \(Java_[a-z_A-Z0-9]*\).*$,\1,' $TMPFILE +sort -u $TMPFILE $TMPFILE4 +mv $TMPFILE4 $TMPFILE # Find all methods in the JNI C source files. find @abs_top_srcdir@/native/jni -name \*.c | \
Re: [cp-patches] [rvm-core] State of Jikes RVM patches waiting to go into Classpath
Andrew John Hughes wrote: On 18/08/2008, Ian Rogers [EMAIL PROTECTED] wrote: Thanks Andrew, Andrew John Hughes wrote: On 18/08/2008, Ian Rogers [EMAIL PROTECTED] wrote: Hi, currently there are 3 patches waiting to go into GNU Classpath from Jikes RVM: Note that 0.98 is very imminent i.e. I'd like it to be released this week and most of it has already been merged to GCJ. 1) Thread Local improvements: http://jira.codehaus.org/browse/RVM-185 http://jikesrvm.svn.sourceforge.net/viewvc/jikesrvm/rvmroot/trunk/build/components/patches/classpath-cvs.RVM-185.patch?revision=13369view=markup I believe this is stalled waiting for Daniel's FSF paper work. This patch would be a big performance win for many VMs. The assignment is still pending. The last e-mail I have is Daniel's assignment form on 11th June. I've pinged to see what's going on. Great! Getting this into 0.98 would be a real feature. I hope your luck's in then and the assignment has been done... :) 2) ZipEntry improvements: http://jira.codehaus.org/browse/RVM-392 http://jikesrvm.svn.sourceforge.net/viewvc/jikesrvm/rvmroot/trunk/build/components/patches/classpath-cvs.RVM-392.patch?revision=14005view=markup This patch cleans up the use of Calendar in ZipEntry and avoids unnecessary bouncing between UNIX and DOS time formats. Possible bootstrap issues were raised by Tom Tromey, so the patch is still pending. Here's the e-mail thread: http://www.nabble.com/RFC%3A-tweaks-to-java.util.zip.ZipEntry-to15289313.html#a15289313 I'm sceptical about committing this one for 0.98 if there may be issues. I assume the gain is it not using a synchronized method to initialise the Calendar? Have you considered the initialization on demand holder idiom instead? http://en.wikipedia.org/wiki/Initialization_on_demand_holder_idiom It's also mentioned in the JSR166 book by Doug Lea et. al. I can see why initialising Calendar as a prerequisite for zip support might cause a lot of problems and I don't think we have time to test it well enough for this release. Sorry, this change is a bit more involved than initialization on demand. Basically the normal use for a ZipEntry is for reading. In the current code to read an entry we must also convert the date (that is in DOS form in a ZIP) into a canonical unix time form, hence the requirement for a Calendar (and boot strap problems if the Calendar is in the zip). The main point of the patch is that we only really need the canonical time if we are writing the ZipEntry or if someone is querying it, in such a circumstance calling Calendar.getInstance() is fine and any caching can be done there. The patch is necessary for Jikes RVM as it avoids a boot strap issue (we don't need a Calendar to be in the boot image before we start reading a zip). I *really* don't want Calendars in Jikes RVM's boot image as I have to hand code conversion code between the different JDK and Classpath formats, hence initialization on demand is definitely not a solution. This patch is a good thing in my opinion and hasn't caused any issues for Jikes RVM, I would like to see it included in 0.98. It will help other VMs with the same bootstrap issue. Your discussion made no sense at first, until I realised you were linking to your first attempt at a patch. The real one is completely different: http://www.nabble.com/Re%3A-RFC%3A-tweaks-to-java.util.zip.ZipEntry-p15331002.html and now your comments make sense... ;) Have you tested with any other VMs? Sorry about that, it's the same thread just at the end rather than the initial patch. What are these other VMs you speak of ;-) Can I apply it and see if something somewhere falls over then fix it, rather than pre-emptively finding things out about VMs I don't use. 3) AIX build fix: http://jira.codehaus.org/browse/RVM-526 http://jikesrvm.svn.sourceforge.net/viewvc/jikesrvm/rvmroot/trunk/build/components/patches/classpath-cvs.RVM-526.patch?revision=14551view=markup This is a small patch that fixes a problem for builds on AIX, I believe it would be safe to commit it. I think I've seen this before. Seems fine. Can you forward it for discussion on cp-patches? Maybe Dave can, he's assigned the issue to himself. The patch seems trivial enough, just breaking the process up presumably due to resource constraints on AIX. But I don't think it has been posted to the Classpath list at all so far. Posted. Thanks, Ian
Re: [cp-patches] [rvm-core] State of Jikes RVM patches waiting to go into Classpath
On 18/08/2008, Ian Rogers [EMAIL PROTECTED] wrote: Andrew John Hughes wrote: On 18/08/2008, Ian Rogers [EMAIL PROTECTED] wrote: Thanks Andrew, Andrew John Hughes wrote: On 18/08/2008, Ian Rogers [EMAIL PROTECTED] wrote: Hi, currently there are 3 patches waiting to go into GNU Classpath from Jikes RVM: Note that 0.98 is very imminent i.e. I'd like it to be released this week and most of it has already been merged to GCJ. 1) Thread Local improvements: http://jira.codehaus.org/browse/RVM-185 http://jikesrvm.svn.sourceforge.net/viewvc/jikesrvm/rvmroot/trunk/build/components/patches/classpath-cvs.RVM-185.patch?revision=13369view=markup I believe this is stalled waiting for Daniel's FSF paper work. This patch would be a big performance win for many VMs. The assignment is still pending. The last e-mail I have is Daniel's assignment form on 11th June. I've pinged to see what's going on. Great! Getting this into 0.98 would be a real feature. I hope your luck's in then and the assignment has been done... :) 2) ZipEntry improvements: http://jira.codehaus.org/browse/RVM-392 http://jikesrvm.svn.sourceforge.net/viewvc/jikesrvm/rvmroot/trunk/build/components/patches/classpath-cvs.RVM-392.patch?revision=14005view=markup This patch cleans up the use of Calendar in ZipEntry and avoids unnecessary bouncing between UNIX and DOS time formats. Possible bootstrap issues were raised by Tom Tromey, so the patch is still pending. Here's the e-mail thread: http://www.nabble.com/RFC%3A-tweaks-to-java.util.zip.ZipEntry-to15289313.html#a15289313 I'm sceptical about committing this one for 0.98 if there may be issues. I assume the gain is it not using a synchronized method to initialise the Calendar? Have you considered the initialization on demand holder idiom instead? http://en.wikipedia.org/wiki/Initialization_on_demand_holder_idiom It's also mentioned in the JSR166 book by Doug Lea et. al. I can see why initialising Calendar as a prerequisite for zip support might cause a lot of problems and I don't think we have time to test it well enough for this release. Sorry, this change is a bit more involved than initialization on demand. Basically the normal use for a ZipEntry is for reading. In the current code to read an entry we must also convert the date (that is in DOS form in a ZIP) into a canonical unix time form, hence the requirement for a Calendar (and boot strap problems if the Calendar is in the zip). The main point of the patch is that we only really need the canonical time if we are writing the ZipEntry or if someone is querying it, in such a circumstance calling Calendar.getInstance() is fine and any caching can be done there. The patch is necessary for Jikes RVM as it avoids a boot strap issue (we don't need a Calendar to be in the boot image before we start reading a zip). I *really* don't want Calendars in Jikes RVM's boot image as I have to hand code conversion code between the different JDK and Classpath formats, hence initialization on demand is definitely not a solution. This patch is a good thing in my opinion and hasn't caused any issues for Jikes RVM, I would like to see it included in 0.98. It will help other VMs with the same bootstrap issue. Your discussion made no sense at first, until I realised you were linking to your first attempt at a patch. The real one is completely different: http://www.nabble.com/Re%3A-RFC%3A-tweaks-to-java.util.zip.ZipEntry-p15331002.html and now your comments make sense... ;) Have you tested with any other VMs? Sorry about that, it's the same thread just at the end rather than the initial patch. What are these other VMs you speak of ;-) Can I apply it and see if something somewhere falls over then fix it, rather than pre-emptively finding things out about VMs I don't use. Normally, that would be okay, but we don't really want to do that so near a release. I'll try and test it with the ones I have to hand (JamVM, CACAO, GCJ) and if everything seems okay, I'll commit it. The second patch doesn't look anywhere near as bad as the first (where there was an obvious bootstrap issue with creating a Calendar instance early). 3) AIX build fix: http://jira.codehaus.org/browse/RVM-526 http://jikesrvm.svn.sourceforge.net/viewvc/jikesrvm/rvmroot/trunk/build/components/patches/classpath-cvs.RVM-526.patch?revision=14551view=markup This is a small patch that fixes a problem for builds on
[cp-patches] FYI: Fix typo in gst_native_pipeline.c
Compiling the GStreamer peer as part of GCJ spotted the following typo: ChangeLog: 2008-08-18 Andrew John Hughes [EMAIL PROTECTED] * native/jni/gstreamer-peer/gst_native_pipeline.c: (get_free_space(int)): Use #else not #elif when there is no condition. Okay for GCJ too? -- Andrew :) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 Index: native/jni/gstreamer-peer/gst_native_pipeline.c === RCS file: /sources/classpath/classpath/native/jni/gstreamer-peer/gst_native_pipeline.c,v retrieving revision 1.3 diff -u -u -r1.3 gst_native_pipeline.c --- native/jni/gstreamer-peer/gst_native_pipeline.c 27 Sep 2007 19:22:01 - 1.3 +++ native/jni/gstreamer-peer/gst_native_pipeline.c 18 Aug 2008 15:29:27 - @@ -509,7 +509,7 @@ result = GST_DETECTED_PIPE_CAPACITY - result; -#elif +#else g_warning(IMPLEMENT ME!!! - !defined (FIONSPACE), !defined (FIONREAD); #endif
Re: [cp-patches] FYI: Fix typo in gst_native_pipeline.c
Andrew John Hughes wrote: Compiling the GStreamer peer as part of GCJ spotted the following typo: ChangeLog: 2008-08-18 Andrew John Hughes [EMAIL PROTECTED] * native/jni/gstreamer-peer/gst_native_pipeline.c: (get_free_space(int)): Use #else not #elif when there is no condition. Okay for GCJ too? Yes. You didn't have to ask: trivial/obvious. Andrew.
[cp-patches] RFC: Avoid back references in java.lang.reflect VMXXX classes
This patch is part of Jikes RVM JIRA issue 443:
http://jira.codehaus.org/browse/RVM-443
committed here:
http://jikesrvm.svn.sourceforge.net/viewvc/jikesrvm?view=revrevision=14905
The patch avoids back references in java.lang.reflect.VM* classes and
instead passes the parent object as a parameter. This means that
constant parents can be propagated rather than in the current code where
the parent must be loaded from a non-final field (breaking potential
optimization without pointer analysis).
The patch changes the internal reflection API and therefore would need a
number of changes in other Classpath VMs to match the interface.
Regards,
Ian
Index: java/lang/reflect/Constructor.java
===
RCS file: /sources/classpath/classpath/java/lang/reflect/Constructor.java,v
retrieving revision 1.10
diff -u -r1.10 Constructor.java
--- java/lang/reflect/Constructor.java 23 Jun 2008 20:59:35 - 1.10
+++ java/lang/reflect/Constructor.java 18 Aug 2008 17:14:28 -
@@ -95,7 +95,6 @@
Constructor(VMConstructor cons)
{
this.cons = cons;
-cons.cons = this;
}
private Constructor()
@@ -316,7 +315,7 @@
{
// Inescapable as the VM layer is 1.4 based.
@SuppressWarnings(unchecked)
- T ins = (T) cons.construct(args);
+ T ins = (T) cons.construct(args, this);
return ins;
}
Index: java/lang/reflect/Field.java
===
RCS file: /sources/classpath/classpath/java/lang/reflect/Field.java,v
retrieving revision 1.10
diff -u -r1.10 Field.java
--- java/lang/reflect/Field.java23 Jun 2008 20:59:35 - 1.10
+++ java/lang/reflect/Field.java18 Aug 2008 17:14:28 -
@@ -96,7 +96,6 @@
Field(VMField f)
{
this.f = f;
-f.f = this;
}
/**
@@ -257,7 +256,7 @@
public Object get(Object o)
throws IllegalAccessException
{
-return f.get(o);
+return f.get(this, o);
}
/**
@@ -280,7 +279,7 @@
public boolean getBoolean(Object o)
throws IllegalAccessException
{
-return f.getBoolean(o);
+return f.getBoolean(this, o);
}
/**
@@ -303,7 +302,7 @@
public byte getByte(Object o)
throws IllegalAccessException
{
-return f.getByte(o);
+return f.getByte(this, o);
}
/**
@@ -324,7 +323,7 @@
public char getChar(Object o)
throws IllegalAccessException
{
-return f.getChar(o);
+return f.getChar(this, o);
}
/**
@@ -347,7 +346,7 @@
public short getShort(Object o)
throws IllegalAccessException
{
-return f.getShort(o);
+return f.getShort(this, o);
}
/**
@@ -370,7 +369,7 @@
public int getInt(Object o)
throws IllegalAccessException
{
-return f.getInt(o);
+return f.getInt(this, o);
}
/**
@@ -393,7 +392,7 @@
public long getLong(Object o)
throws IllegalAccessException
{
-return f.getLong(o);
+return f.getLong(this, o);
}
/**
@@ -416,7 +415,7 @@
public float getFloat(Object o)
throws IllegalAccessException
{
-return f.getFloat(o);
+return f.getFloat(this, o);
}
/**
@@ -440,7 +439,7 @@
public double getDouble(Object o)
throws IllegalAccessException
{
-return f.getDouble(o);
+return f.getDouble(this, o);
}
/**
@@ -491,7 +490,7 @@
public void set(Object o, Object value)
throws IllegalAccessException
{
-f.set(o, value);
+f.set(this, o, value);
}
/**
@@ -514,7 +513,7 @@
public void setBoolean(Object o, boolean value)
throws IllegalAccessException
{
-f.setBoolean(o, value);
+f.setBoolean(this, o, value);
}
/**
@@ -537,7 +536,7 @@
public void setByte(Object o, byte value)
throws IllegalAccessException
{
-f.setByte(o, value);
+f.setByte(this, o, value);
}
/**
@@ -560,7 +559,7 @@
public void setChar(Object o, char value)
throws IllegalAccessException
{
-f.setChar(o, value);
+f.setChar(this, o, value);
}
/**
@@ -583,7 +582,7 @@
public void setShort(Object o, short value)
throws IllegalAccessException
{
-f.setShort(o, value);
+f.setShort(this, o, value);
}
/**
@@ -606,7 +605,7 @@
public void setInt(Object o, int value)
throws IllegalAccessException
{
-f.setInt(o, value);
+f.setInt(this, o, value);
}
/**
@@ -629,7 +628,7 @@
public void setLong(Object o, long value)
throws IllegalAccessException
{
-f.setLong(o, value);
+f.setLong(this, o, value);
}
/**
@@ -652,7 +651,7 @@
public void setFloat(Object o, float value)
throws IllegalAccessException
{
-f.setFloat(o, value);
+f.setFloat(this, o, value);
}
/**
@@ -675,7 +674,7 @@
public void setDouble(Object o, double value)
throws IllegalAccessException
{
-f.setDouble(o, value);
+f.setDouble(this, o, value);
}
/**
Index:
Re: [cp-patches] FYI: Fix typo in gst_native_pipeline.c
Il giorno lun, 18/08/2008 alle 17.36 +0100, Andrew John Hughes ha scritto: Compiling the GStreamer peer as part of GCJ spotted the following typo: ChangeLog: 2008-08-18 Andrew John Hughes [EMAIL PROTECTED] * native/jni/gstreamer-peer/gst_native_pipeline.c: (get_free_space(int)): Use #else not #elif when there is no condition. Okay for GCJ too? Cool, so this thingy is used now! I have many pending fixes there (and some new stuff), hopefully I will work on this in the next days time permitting, but if you spot errors, please ping me. Mario -- Mario Torre, Software Developer, http://www.jroller.com/neugens/ aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-53 pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim Geschäftsführer: Dr. James J. Hunt Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/
Re: [cp-patches] [rvm-core] State of Jikes RVM patches waiting to go into Classpath
Ian == Ian Rogers [EMAIL PROTECTED] writes: Ian Sorry about that, it's the same thread just at the end rather than the Ian initial patch. What are these other VMs you speak of ;-) Can I apply Ian it and see if something somewhere falls over then fix it, rather than Ian pre-emptively finding things out about VMs I don't use. The problem case had to do with extended time stamps in zip files. My memory of this stuff has faded, but here's the note: http://gcc.gnu.org/ml/java/2003-03/msg00267.html If this remains a non-problem then I would not worry much. In any case we can always back out or otherwise fix changes that cause problems. Tom
Re: [cp-patches] RFC: AIX build fix - paths too long in check_jni.sh
Ian == Ian Rogers [EMAIL PROTECTED] writes: Ian Dave Grove fixed an AIX build issue for the Jikes RVM with the Ian attached patch. Jikes RVM tracker here: Ian http://jira.codehaus.org/browse/RVM-526 It reads slightly strangely to me, but no big deal -- it isn't unclear. Ok with a ChangeLog entry. Tom
