[patch] merging classpath 0.97.2

[patch] merging classpath 0.97.2

[Matthias Klose]

not posting a complete patch; the current merge can be found in the
branches/gcj/classpath-0961-import-branch branch. Documenting the changes which
were necessary to get a working trunk, which doesn't show regressions when
running the libjava testsuite.  I did an earlier merge of 0.96.1, which is
included there.

  Matthias

The diff can be produced with:

svn diff \
  svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/classpath-0961-import-branch\
  svn+ssh://gcc.gnu.org/svn/gcc/trunk@136533

The toplevel Makefile.in diff doesn't belong to the merge

libjava/

2008-06-07  Matthias Klose  <doko@ubuntu.com>

        Import GNU Classpath (classpath-0_97_2-release).

	* configure.ac: Set JAVAC, pass --disable-regen-headers
	to the classpath configure.
        * Regenerate class and header files.
        * Regenerate auto* files.

2008-01-27  Matthias Klose  <doko@ubuntu.com>

        * gcj/javaprims.h: Define jobjectRefType.
        * jni.cc (_Jv_JNI_GetObjectRefType): New (stub only).
        (_Jv_JNIFunctions): Initialize GetObjectRefType.

2008-01-27  Matthias Klose  <doko@ubuntu.com>

        Import GNU Classpath (classpath-0_96_1-release).

        * Regenerate class and header files.
        * Regenerate auto* files.

        * gnu/classpath/jdwp/VMVirtualMachine.java,
        java/security/VMSecureRandom.java: Merge from classpath.

        * HACKING: Fix typo.


libjava/classpath/

2008-06-07  Matthias Klose  <doko@ubuntu.com>

        * native/jni/gstreamer-peer/Makefile.am: Do not link with
        libclasspathnative.
        * native/jni/gstreamer-peer/Makefile.in: Regenerate.

Re: [patch] merging classpath 0.97.2

[David Daney]

Matthias Klose wrote:
> not posting a complete patch; the current merge can be found in the
> branches/gcj/classpath-0961-import-branch branch. Documenting the changes which
> were necessary to get a working trunk, which doesn't show regressions when
> running the libjava testsuite.  I did an earlier merge of 0.96.1, which is
> included there.
>
>   

Does this include the CPStringBuilder changes?

If so we will need to add libgcj support so that we do a direct call to 
the String constructor, and not use the default reflection based 
implementation.

David Daney

>   Matthias
>
> The diff can be produced with:
>
> svn diff \
>   svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/classpath-0961-import-branch\
>   svn+ssh://gcc.gnu.org/svn/gcc/trunk@136533
>
> The toplevel Makefile.in diff doesn't belong to the merge
>
> libjava/
>
> 2008-06-07  Matthias Klose  <doko@ubuntu.com>
>
>         Import GNU Classpath (classpath-0_97_2-release).
>
> 	* configure.ac: Set JAVAC, pass --disable-regen-headers
> 	to the classpath configure.
>         * Regenerate class and header files.
>         * Regenerate auto* files.
>
> 2008-01-27  Matthias Klose  <doko@ubuntu.com>
>
>         * gcj/javaprims.h: Define jobjectRefType.
>         * jni.cc (_Jv_JNI_GetObjectRefType): New (stub only).
>         (_Jv_JNIFunctions): Initialize GetObjectRefType.
>
> 2008-01-27  Matthias Klose  <doko@ubuntu.com>
>
>         Import GNU Classpath (classpath-0_96_1-release).
>
>         * Regenerate class and header files.
>         * Regenerate auto* files.
>
>         * gnu/classpath/jdwp/VMVirtualMachine.java,
>         java/security/VMSecureRandom.java: Merge from classpath.
>
>         * HACKING: Fix typo.
>
>
> libjava/classpath/
>
> 2008-06-07  Matthias Klose  <doko@ubuntu.com>
>
>         * native/jni/gstreamer-peer/Makefile.am: Do not link with
>         libclasspathnative.
>         * native/jni/gstreamer-peer/Makefile.in: Regenerate.
>
>   

Re: [patch] merging classpath 0.97.2

[Matthias Klose]

David Daney schrieb:
> Matthias Klose wrote:
>> not posting a complete patch; the current merge can be found in the
>> branches/gcj/classpath-0961-import-branch branch. Documenting the
>> changes which
>> were necessary to get a working trunk, which doesn't show regressions
>> when
>> running the libjava testsuite.  I did an earlier merge of 0.96.1,
>> which is
>> included there.
>>
>>   
> 
> Does this include the CPStringBuilder changes?
> 
> If so we will need to add libgcj support so that we do a direct call to
> the String constructor, and not use the default reflection based
> implementation.

It just has this, nothing from the pending 0.98 release.

2008-02-05  Ian Rogers  <ian.rogers@manchester.ac.uk>

        * gnu/java/lang/reflect/TypeSignature.java
        * java/io/BufferedReader.java
        * java/io/DataInputStream.java
        * java/lang/StackTraceElement.java
        * java/lang/Throwable.java
        * java/lang/reflect/Proxy.java
        * java/net/URI.java
        * java/net/URLClassLoader.java
        * java/net/URLEncoder.java
        * java/text/SimpleDateFormat.java
        * java/util/AbstractMap.java
        * java/util/Calendar.java
        * java/util/Date.java
        * java/util/Hashtable.java
        Use StringBuilder in preference to StringBuffer

Re: [patch] merging classpath 0.97.2

[Andrew John Hughes]

On 09/06/2008, David Daney <ddaney@avtrex.com> wrote:
> Matthias Klose wrote:
>
> > not posting a complete patch; the current merge can be found in the
> > branches/gcj/classpath-0961-import-branch branch.
> Documenting the changes which
> > were necessary to get a working trunk, which doesn't show regressions when
> > running the libjava testsuite.  I did an earlier merge of 0.96.1, which is
> > included there.
> >
> >
> >
>
>  Does this include the CPStringBuilder changes?
>
>  If so we will need to add libgcj support so that we do a direct call to the
> String constructor, and not use the default reflection based implementation.
>
>  David Daney
>

No, 0.97.2 is just 0.97 plus a number of bug fixes.  New features like
the CPStringBuilder material, gjdoc and the native BigInteger
implementation will be in 0.98 when released.

When CPStringBuilder is merged, I'd suggest looking at whether this
can be merged with the GCJ implementation it is based on in terms of
the native support and using one unified implementation across GCJ.

Thanks for doing this,
-- 
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: [patch] merging classpath 0.97.2

[Tom Tromey]

>>>>> "Matthias" == Matthias Klose <doko@ubuntu.com> writes:

Matthias> The diff can be produced with:

I didn't look at the diff, but I assume it is all ok.
Did you try running Mauve?

Matthias>         * gcj/javaprims.h: Define jobjectRefType.

AFAIK, there is no reason for jobjectRefType not to simply always be
defined in Classpath's jni.h.  Assuming I'm not missing something, I'd
rather we do that.  I'll send a patch there.

Matthias>         * jni.cc (_Jv_JNI_GetObjectRefType): New (stub only).

It is better to just leave this slot as NULL, until a real
implementation is written.

If we need an implementation for some Classpath library, then let me
know and I will write one.

Otherwise this is ok by me.  Could you send a note to the main GCC
list before merging?  If someone else is doing a big merge it would be
nice not to hold off a little until those results stabilize.

Tom

Re: [patch] merging classpath 0.97.2

[Matthias Klose]

Tom Tromey schrieb:
>>>>>> "Matthias" == Matthias Klose <doko@ubuntu.com> writes:
> If we need an implementation for some Classpath library, then let me
> know and I will write one.

not needed, but I didn't implement new methods found in VMFile.java either
(getTotalSpace, getFreeSpace, getUsableSpace). I'll file bug reports about these.

> Otherwise this is ok by me.  Could you send a note to the main GCC
> list before merging?  If someone else is doing a big merge it would be
> nice not to hold off a little until those results stabilize.

Traveling this weekend; I'm trying to do this on Monday.

  Matthias