javah in 0.97+ -> trouble
Hi, from 0.97 onwards, classpath needs a working javah tool. Such a program is provided by classpath' tools.zip but needs a working runtime and class library first. Earlier classpath releases had pre-generated header files and needed no javah program. Someone with less knowledge of the subtile changes in each classpath release wanted to introduce 0.97.1 in OE as the class library which runs the compiler etc. This currently fails because in my previous bootstrap effort I did not care to provide a working javah (it would be from classpath 0.93). I would like to suggest the following way to fix this issue: The build system should allow using the just built javah application being run with a provided java executable. This would be less pain for me and would probably also benefit other cross compilation efforts. E.g. --enable-builtin-javah should set the javah executable to some script which is generated (perhaps from the real gjavah) which is run with the java vm specified by --with-java. Regards Robert signature.asc Description: OpenPGP digital signature
Re: gnu.xml.datatype.JAXPDatatypeFactory not there
2008/5/13 Robert Schuster <[EMAIL PROTECTED]>: > Hi, > javax.xml.datatype.DatatypeFactory declares: > > public static final String DATATYPEFACTORY_IMPLEMENTATION_CLASS = > "gnu.xml.datatype.JAXPDatatypeFactory"; > > The value is a fallback value which is treated as a class which is to be > instantiated. Unfortunately this class does not exist. > > Has this class been renamed or has it really not been written yet? > > Regards > Robert > > The package doesn't seem to exist and I don't recall us having any datatype support. I guess the factory was just added so other factories would be able to operate using GNU Classpath. -- 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
gnu.xml.datatype.JAXPDatatypeFactory not there
Hi, javax.xml.datatype.DatatypeFactory declares: public static final String DATATYPEFACTORY_IMPLEMENTATION_CLASS = "gnu.xml.datatype.JAXPDatatypeFactory"; The value is a fallback value which is treated as a class which is to be instantiated. Unfortunately this class does not exist. Has this class been renamed or has it really not been written yet? Regards Robert signature.asc Description: OpenPGP digital signature
Re: Integer.parseInt("+42") gives -42
[EMAIL PROTECTED] wrote: > The Java documentation only allows a '-' sign, not a '+' sign in > Integer.parseInt and Integer.decode. You've not been reading your mail. In particular, you haven't been reading my replies. :-) Andrew.
Re: Integer.parseInt("+42") gives -42
The Java documentation only allows a '-' sign, not a '+' sign in
Integer.parseInt and Integer.decode.
David R Cok
"Andrew John Hughes" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
05/12/2008 04:46 PM
To
"Nicolas Geoffray" <[EMAIL PROTECTED]>
cc
classpath@gnu.org
Subject
Re: Integer.parseInt("+42") gives -42
On 12/05/2008, Nicolas Geoffray <[EMAIL PROTECTED]> wrote:
> With the following testcase (Test.java attached), the output of jamvm
is:
> -42
>
> It should have thrown an exception.
>
> I attached a patch to correct Integer.java. I could commit it, but I
can't
> find my username/password. Can someone commit it?
>
> (I already wrote to classpath-patches, but I may have a bigger audience
> here)
>
> Thanks,
> Nicolas
>
>
Do you have a copyright assignment? If so, I'll test and commit on your
behalf.
--
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: Building the VM classes
On Tue, 2008-05-13 at 09:45 +0100, Andrew John Hughes wrote: > That was my understanding. Apart from making the code messier, > it doesn't do any harm, it's just difficult to maintain if we don't > build it with > the 1.4 options. OK, I think it's a good idea. - twisti
Re: System.out.printf
OneGuy wrote:
> I tried
>
> System.out.printf("Primes up to %8d %8d\n", m, count);
>
> and it worked fine on GCJ (as far as I remember), but someone else got the
> error
>
> 45: error: Can't find method 'printf(Ljava/lang/String;II)' in type
> 'java.io.PrintStream'.
>System.out.printf("Primes up to %8d %8d\n", m, count);
>
> Is there a reson for this?
Yeah. You need to look at the specification for printf().
Andrew.
Re: Building the VM classes
2008/5/13 Christian Thalinger <[EMAIL PROTECTED]>: > On Sun, 2008-05-11 at 00:08 +0100, Andrew John Hughes wrote: > > Hi all, > > > > I recently noticed that our VM classes had acquired code that uses the > > 1.5 language features. As I believe we agreed to keep these 1.4-clean > > with respect to the language features, I've removed these. I assume > > we wish to keep this policy as the only deficit is in brevity of the > > source code (as we are only talking about 1.4 with respect to the > > language specification). > > > > To prevent this happening again, I suggest we change our build to > > compile these classes separately using -source 1.4 -target 1.4 (as I > > did to find the regressions). In looking through our build > > environment to work out how to do this, I noticed that we compile a > > list of VM classes in vm.add which is then thrown away. The final > > classes list we use doesn't contain the VM classes (they are dragged > > in as dependencies instead). Does anyone know the logic behind our > > gen-classlist.sh script? My suggestion would be to simply keep vm.add > > as well as classes and compile this using the 1.4 options. > > > > What do others think of this proposal? > > What is the reason to keep them 1.4? To be able to bootstrap VMs with > e.g. Jikes? > > - twisti > > That was my understanding. Apart from making the code messier, it doesn't do any harm, it's just difficult to maintain if we don't build it with the 1.4 options. -- 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: Building the VM classes
On Sun, 2008-05-11 at 00:08 +0100, Andrew John Hughes wrote: > Hi all, > > I recently noticed that our VM classes had acquired code that uses the > 1.5 language features. As I believe we agreed to keep these 1.4-clean > with respect to the language features, I've removed these. I assume > we wish to keep this policy as the only deficit is in brevity of the > source code (as we are only talking about 1.4 with respect to the > language specification). > > To prevent this happening again, I suggest we change our build to > compile these classes separately using -source 1.4 -target 1.4 (as I > did to find the regressions). In looking through our build > environment to work out how to do this, I noticed that we compile a > list of VM classes in vm.add which is then thrown away. The final > classes list we use doesn't contain the VM classes (they are dragged > in as dependencies instead). Does anyone know the logic behind our > gen-classlist.sh script? My suggestion would be to simply keep vm.add > as well as classes and compile this using the 1.4 options. > > What do others think of this proposal? What is the reason to keep them 1.4? To be able to bootstrap VMs with e.g. Jikes? - twisti
