GNU Classpath 0.99 Released!
e same default capacity in java.util.HashMap as documented in OpenJDK. - Check for hashcode equality before calling equals in java.util.HashMap.put - Make sure match is within input data limits in java.util.regex.Matcher.find. - Fix misuse of ArrayList.set in javax.swing.text.html.StyleSheet.resolveStyle. - PR48131: java.util.zip.ZipException: incomplete dynamic bit lengths tree - Check for negative capacity in VMDirectByteBuffer's native code. - PR42823: tcp/ip sockets read/write operations causes memory leak - Generate META-INF/INDEX.LST for glibj.zip - Fix issues when building with -Werror and gcc 4.6. - PR40188: javah creates constants using name of superclass - PR45527: gjavah encodes $ as used in inner classes as 00024 where Oracle's javah does not - PR45526: gjavah does not implicitly produce header files for inner classes - Fix NullPointerException for null keys in java.util.HashMap.put. - Fix BEAST security issue in gnu.javax.net.ssl.provider. - RH712013: pdftk crashes with java.lang.ArrayIndexOutOfBoundsException * Updated to libtool 2.x. * Lots of warning fixes / addition of generics. * Fix license headers in tools. * Normalise whitespace. * Maintenance work on javac detection. * Mark plugin as unmaintained and disable by default. The following people helped with this release: * Roland Brand * Gert Brettlecker * Chris Burdess * Ludovic Claude * Pekka Enberg * Jeroen Frijters * Richard Guenther * Andrew Haley * Andrew John Hughes * Ivan Maidanski * Daniel Noll * Rainer Orth * Mike Stump * Tom Tromey * Mark Wielaard * Ralf Wildenhues We would also like to thank the numerous bug reporters and testers! In addition, we'd like to extend our thanks to all those who've contributed over the years and have helped in building a thriving and friendly community around the GNU Classpath project. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 signature.asc Description: Digital signature
Re: classpath configure update?
On 17:45 Mon 28 Nov , Andreas Tobler wrote: > Hi Mark, > > On 28.11.11 17:39, Mark Wielaard wrote: > > > On Mon, 2011-11-28 at 09:50 +0100, Andreas Tobler wrote: > >> I recently pushed a commit to gcc head and gcc-4.6 to fix the detection > >> of FreeBSD-10. > >> > >> http://gcc.gnu.org/ml/gcc-cvs/2011-11/msg00886.html > >> > >> Now I see that I need to do that for libjava/classpath/configure too. > >> > >> My question, how do I do that? Means, can I simply commit the fix to the > >> gcc/libjava/classpath and don't care about upstream classpath? > >> Or how do I proceed? > > > > Upstream classpath doesn't check in generated files like configure, so > > if it is just the generated files, then nothing has to be done. If you > > have a patch against configure.ac then please just post it to > > java-patc...@gcc.gnu.org and/or classpath-patc...@gnu.org and we take it > > from there. For changes that only apply to libjava/gcj there is a > > libjava/classpath/ChangeLog.gcj to track those. > > Well, it is a regenerated configure (which pulls in gcc toplevel > libtool.m4 changes) and the config.rpath. > For the former I need to dive into cp sources to see how it works. For > the latter I guess it is a normal patch. > configure is only present in gcj's copy of GNU Classpath. config.rpath will need patching in GNU Classpath, so please post a patch to classpath-patc...@gnu.org. How does the change to configure persist if you don't change the source configure.ac? > Thanks, > Andreas -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 signature.asc Description: Digital signature
Re: [problem] GNU Classpath build problems on Fedora 15
On 15:31 Tue 27 Sep , Pekka Enberg wrote: > Hi all, > > I'm seeing this on Fedora 15: > > [penberg@tux classpath.cvs]$ sh autogen.sh > configure.ac:505: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but > not m4_defun'd > m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from... > m4/iconv.m4:22: AM_ICONV_LINK is expanded from... > m4/iconv.m4:77: AM_ICONV is expanded from... > configure.ac:505: the top level > configure.ac:505: warning: AC_LIB_RPATH is m4_require'd but not m4_defun'd > m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from... > m4/iconv.m4:22: AM_ICONV_LINK is expanded from... > m4/iconv.m4:77: AM_ICONV is expanded from... > configure.ac:505: the top level > configure.ac:505: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but > not m4_defun'd > m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from... > m4/iconv.m4:22: AM_ICONV_LINK is expanded from... > m4/iconv.m4:77: AM_ICONV is expanded from... > configure.ac:505: the top level > configure.ac:505: warning: AC_LIB_RPATH is m4_require'd but not m4_defun'd > m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from... > m4/iconv.m4:22: AM_ICONV_LINK is expanded from... > m4/iconv.m4:77: AM_ICONV is expanded from... > configure.ac:505: the top level > libtoolize: putting auxiliary files in `.'. > libtoolize: copying file `./ltmain.sh' > libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. > libtoolize: copying file `m4/libtool.m4' > libtoolize: copying file `m4/ltoptions.m4' > libtoolize: copying file `m4/ltsugar.m4' > libtoolize: copying file `m4/ltversion.m4' > libtoolize: copying file `m4/lt~obsolete.m4' > configure.ac:505: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but > not m4_defun'd > m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from... > m4/iconv.m4:22: AM_ICONV_LINK is expanded from... > m4/iconv.m4:77: AM_ICONV is expanded from... > configure.ac:505: the top level > configure.ac:505: warning: AC_LIB_RPATH is m4_require'd but not m4_defun'd > m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from... > m4/iconv.m4:22: AM_ICONV_LINK is expanded from... > m4/iconv.m4:77: AM_ICONV is expanded from... > configure.ac:505: the top level > configure.ac:505: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but > not m4_defun'd > m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from... > m4/iconv.m4:22: AM_ICONV_LINK is expanded from... > m4/iconv.m4:77: AM_ICONV is expanded from... > configure.ac:505: the top level > configure.ac:505: warning: AC_LIB_RPATH is m4_require'd but not m4_defun'd > m4/iconv.m4:11: AM_ICONV_LINKFLAGS_BODY is expanded from... > m4/iconv.m4:22: AM_ICONV_LINK is expanded from... > m4/iconv.m4:77: AM_ICONV is expanded from... > configure.ac:505: the top level > configure:18566: error: possibly undefined macro: AC_LIB_PREPARE_PREFIX > If this token and others are legitimate, please use m4_pattern_allow. > See the Autoconf documentation. > configure:18567: error: possibly undefined macro: AC_LIB_RPATH > configure:18572: error: possibly undefined macro: AC_LIB_LINKFLAGS_BODY > configure:18580: error: possibly undefined macro: AC_LIB_APPENDTOVAR > autoreconf: /usr/bin/autoconf failed with exit status: 1 > > Has anyone built GNU Classpath on Fedora 15 successfully? > >Pekka > No. Can you give the versions of the autotools on this platform? That would be more generally useful. It's likely to be that something has been updated. Personally, I have autoconf 2.68, automake 1.11.1 and libtool 2.4 here on Gentoo. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Using ASM for invokedynamic bytecode generation
On 08:38 Thu 08 Sep , Pekka Enberg wrote: > Hi all, > > I started hacking on invokedynamic again: > > https://github.com/penberg/classpath/commit/21c457f4928678bb5709dfc5a992b80f0d02c4b8 > > https://github.com/penberg/jato/commits/indy > > I'm planning to use ASM for generating bytecode for method handle > chains. Does that sound like a reasonable thing to do? We already > carry the ASM code under tools/external/asm/. Can I just move that > under external/ and rename the package so that it doesn't clash with > the upstream project? > > Pekka > I'd rather we just depended on it. The current version is outdated as it is. As to the code, a number of comments: * Can we keep fields near the top of the class? I don't know about others, but personally I find it hard to track things if fields are hiding at the bottom of a class. * The unimplemented ones should declare and throw gnu.classpath.NotImplementedException so JAPI picks it up, not UnsupportedOperationException which has different semantics. * Why are you redefining toString() as a stub? The default from Object would do. * Indenting is out in VMMethodHandles.java and you need some line breaks on those long definitions. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
FOSDEM 2011 Free Java Movies
They're finally appearing online. Keep an eye on: http://fuseyism.com/#movies -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: disabling jawt
On 16:57 Fri 15 Apr , Paul Blacquiere wrote: > Attempting to build classpath for arm, am using the following config: > > CC=arm-fusion-linux-uclibcgnueabi-gcc ./configure --host=arm-linux > --build=i686-linux --target=arm-linux --prefix=/var/g6/java --without-x > --disable-jawt --disable-plugin --disable-gmp --disable-jni > --with-glibj-zip=/path/to/glibj.zip > > But I get the following when building: > > arm-fusion-linux-uclibcgnueabi-gcc -DHAVE_CONFIG_H -I. -I../../include > -I../../include -I../../native/jni/classpath -I../../native/jni/native-lib > -g -O2 -MT jawt.lo -MD -MP -MF .deps/jawt.Tpo -c jawt.c -fPIC -DPIC -o > .libs/jawt.o > In file included from jawt.c:41: > ../../include/jawt_md.h:44:22: error: X11/Xlib.h: No such file or directory > > Which is no surprise as the target does not have X support, and if it did > not build jawt then I suspect it would not need X... > > What is the option to disable building jawt? > > Thanks for help in advance. > > Blacq.. --disable-gtk-peer. I'm surprised configure passed if you don't have X support. Can you attach your config.log? May be a bug. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: [RFC/PATCH] Invokedynamic API stubs
On 9 February 2011 14:24, Mark Wielaard wrote: > On Tue, 2011-02-08 at 21:52 +, Dr Andrew John Hughes wrote: >> I assume by Mercurial 'branching', you mean what we do with IcedTea6 HEAD >> and the releases at present, not the in-tree support? Because that's worse >> than CVS IME. > > I don't know yet. The in-tree support was bad pre-1.0. But that was > years ago. Are you sure it is still not workable? > I'll try and figure out what savannah supports soon. > No, but I don't really have time to look into it either. Let's just keep with what we know for now. >> > > This patch implements the work-in-progress invokedynamic API stubs >> > > described >> > > here: >> > > >> > > >> > > http://download.oracle.com/javase/7/docs/api/java/dyn/package-summary.html >> > > >> > > The classes don't do anything useful yet and don't even contain all the >> > > specified methods. >> > >> > Might be better to find some other reference to point people at. This >> > screams it isn't finished yet, might move. I don't have a good >> > suggestion though. The java doc in OpenJDK is distributed under the GPL >> > though, but doesn't seem to be online yet. >> >> Is there anything stopping us having the docs generated by IcedTea online? >> Maybe the builder could produce them? > > The builder does already produce them, it just doesn't publish them > anywhere yet :) I'll look into pushing them public somewhere. Probably > to the main icedtea server. > > And as Robert just pointed out John Rose has been keeping a GPL derived > version of the spec/javadoc here: > http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm/ I think we need public ones from both IcedTea 6 & 7 so we know what they are based on. > Cheers, > > Mark > > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) 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: [RFC/PATCH] Invokedynamic API stubs
On 13:28 Tue 08 Feb , Mark Wielaard wrote: > On Mon, 2011-02-07 at 22:01 +0200, Pekka Enberg wrote: > > On Mon, 2011-02-07 at 15:24 +0100, Dr Andrew John Hughes wrote: > > > > I guess I could keep it on my Github mirror until I have something > > > > concrete enough to be merged to trunk. > > > > > > > I'd prefer to have it in HEAD as long as it's clearly marked as stubs > > > (the NotImplementedException I mentioned) and there is work actively > > > taking place. > > > Then there's always the (slim) possibility someone else can work on it :-) > > > > That was my original thinking as well. Does the included patch look > > better to you? Mark, what do you think about this? > > I admit to still just not like stubs, however they are setup. > If creating branches wasn't such a pain with CVS I would really > recommend doing all this on a branch and only merge when ready and it > can actually be used with some VM. I guess it is just time to bite the > bullet and create some time to move to mercurial and setup some rules > about how to create working branches. I won't veto getting this in right > now if that is really what you and Andrew want, but I am not > particularly excited either. > I assume by Mercurial 'branching', you mean what we do with IcedTea6 HEAD and the releases at present, not the in-tree support? Because that's worse than CVS IME. > > This patch implements the work-in-progress invokedynamic API stubs described > > here: > > > > http://download.oracle.com/javase/7/docs/api/java/dyn/package-summary.html > > > > The classes don't do anything useful yet and don't even contain all the > > specified methods. > > Might be better to find some other reference to point people at. This > screams it isn't finished yet, might move. I don't have a good > suggestion though. The java doc in OpenJDK is distributed under the GPL > though, but doesn't seem to be online yet. > Is there anything stopping us having the docs generated by IcedTea online? Maybe the builder could produce them? > Cheers, > > Mark > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: [RFC/PATCH] Invokedynamic API stubs
On 7 February 2011 11:30, Pekka Enberg wrote: > Hi! > > On Thu, 2011-02-03 at 16:47 +0200, Pekka Enberg wrote: >>> I'd like to check in these simple invokedynamic API stubs into CVS HEAD. >>> The APIs are not final but I think now is as good time as any to start >>> working on them especially as it needs work on the VM side. Furthermore, >>> there's already open source projects such as JRuby out there that use >>> invokedynamic so I think GNU Classpath probably needs to support it at >>> some point anyway. >> >>> The classes don't do anything useful yet and don't even contain all >>> the specified methods. > > On Fri, Feb 4, 2011 at 10:11 AM, Mark Wielaard wrote: >> I have to admit that I don't like putting in stubs. In the past we have >> decided to just leave things really unimplemented if we don't support >> it. And as you say it needs a bit more design thinking. So I would >> suggest you do this on a branch first (grmbl CVS...) and/or first try to >> spec it out against a jato VM implementation. > > Sure, I want to start looking at implementing invokedynamic for Jato > which is why I implemented these stubs in the first place. I expect > that to take some time so the question is where to put the > work-in-progress implementation. I don't see any reason to keep it > stashed on my local hard disk but I have to admit I'm not entirely > happy with the idea of using CVS branches for it either... > > I guess I could keep it on my Github mirror until I have something > concrete enough to be merged to trunk. > I'd prefer to have it in HEAD as long as it's clearly marked as stubs (the NotImplementedException I mentioned) and there is work actively taking place. Then there's always the (slim) possibility someone else can work on it :-) > On Fri, Feb 4, 2011 at 10:11 AM, Mark Wielaard wrote: >> BTW. John Rose has lots of background material online: >> http://cr.openjdk.java.net/~jrose/pres/ > > Thanks! > > Pekka > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: [RFC/PATCH] Invokedynamic API stubs
On Fri, Feb 04, 2011 at 09:11:50AM +0100, Mark Wielaard wrote: > Hi Pekka, > > On Thu, 2011-02-03 at 16:47 +0200, Pekka Enberg wrote: > > I'd like to check in these simple invokedynamic API stubs into CVS HEAD. > > The APIs are not final but I think now is as good time as any to start > > working on them especially as it needs work on the VM side. Furthermore, > > there's already open source projects such as JRuby out there that use > > invokedynamic so I think GNU Classpath probably needs to support it at > > some point anyway. > > > The classes don't do anything useful yet and don't even contain all > > the specified methods. > > I have to admit that I don't like putting in stubs. In the past we have > decided to just leave things really unimplemented if we don't support > it. And as you say it needs a bit more design thinking. So I would > suggest you do this on a branch first (grmbl CVS...) and/or first try to > spec it out against a jato VM implementation. > I'd also rather see implementation than stubs :-) Or if you do add stubs, please use the gnu.classpath.NotImplementedException to mark them as such. Also, as JDK7 stuff, I don't think this is 100% final yet. There's lots of JDK6 stuff that needs doing :-D > BTW. John Rose has lots of background material online: > http://cr.openjdk.java.net/~jrose/pres/ > > Cheers, > > Mark > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Future blog
On 10:54 Sun 12 Dec , Pekka Enberg wrote:
> On Thu, 2010-12-09 at 12:45 +, Dr Andrew John Hughes wrote:
> > I disagree. Just because the version in gcj is different doesn't mean
> > it's correct. As far as I'm aware, Pekka already has a testcase for
> > this so it would be good to have it in Mauve.
>
> Sorry for the delay, here's a test case for getSimpleName().
>
> Pekka
>
> >From 3637ab8ec4f866da6fadc092eab1f99ce4adb417 Mon Sep 17 00:00:00 2001
> From: Pekka Enberg
> Date: Sun, 12 Dec 2010 10:52:27 +0200
> Subject: [PATCH] mauve: Add test case for Class.getSimpleName()
>
> Signed-off-by: Pekka Enberg
> ---
> gnu/testlet/java/lang/Class/ClassTest.java | 13 +
> 1 files changed, 13 insertions(+), 0 deletions(-)
>
> diff --git a/gnu/testlet/java/lang/Class/ClassTest.java
> b/gnu/testlet/java/lang/Class/ClassTest.java
> index 71b144c..c5927e8 100644
> --- a/gnu/testlet/java/lang/Class/ClassTest.java
> +++ b/gnu/testlet/java/lang/Class/ClassTest.java
> @@ -577,6 +577,18 @@ public class ClassTest implements Cloneable,
> java.io.Serializable, Testlet
> harness.check(in == null);
>}
>
> + public void test_getSimpleName()
> + {
> +harness.checkPoint("test_getSimpleName");
> +harness.check(int.class.getSimpleName().equals("int"));
> +harness.check(int[].class.getSimpleName().equals("int[]"));
> +harness.check(int[][].class.getSimpleName().equals("int[][]"));
> +harness.check(Object[].class.getSimpleName().equals("Object[]"));
> +harness.check(Object.class.getSimpleName().equals("Object"));
> +harness.check(InnerClass.class.getSimpleName().equals("InnerClass"));
> + }
> + public static class InnerClass { };
> +
>public void testall()
>{
> test_toString();
> @@ -594,6 +606,7 @@ public class ClassTest implements Cloneable,
> java.io.Serializable, Testlet
> // This one doesn't work so well in Mauve.
> // test_getResource();
> test_getResourceAsStream();
> +test_getSimpleName();
>
>}
>
> --
> 1.7.0.4
>
>
>
I've committed this to Mauve as a new test case (rather than extending
ClassTest) as this should make it easier to run. I also added cases
to check anonymous classes which should return "".
This test also unearthed another bug in CACAO which seems to think
that the class of an array of an anonymous class is anonymous, while
gcj, jamvm and OpenJDK all disagree. This causes it to still fail one
of the test cases as it returns "" instead of "[]" for an array class
with a component type that is an anonymous class.
--
Andrew :)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Future blog
On 09:42 Thu 09 Dec , Andrew Haley wrote: > On 12/08/2010 05:17 PM, Dr Andrew John Hughes wrote: > > On 11:13 Wed 08 Dec , Andrew Haley wrote: > >> On 12/08/2010 10:58 AM, Pekka Enberg wrote: > >>> On Wed, Dec 8, 2010 at 12:32 PM, Andrew Haley wrote: > >>>> I hereby offer to review some patches. Please send pointers to the > >>>> list. > >>> > >>> http://developer.classpath.org/pipermail/classpath-patches/2010-November/006511.html > >> > >> This needs a ChangeLog, otherwise OK. > >> > >>> http://developer.classpath.org/pipermail/classpath-patches/2010-November/006513.html > >> > >> This needs a ChangeLog, otherwise OK. > >> > > > > I've already seen these and I agree both seem fine. But Pekka needs a > > copyright > > assignment before any more work can be committed. > > > >>> http://developer.classpath.org/pipermail/classpath-patches/2010-November/006512.html > >> > >> What compatibility problem does this fix? > >> > > > > I'd like to see a test case in Mauve for this before we change this. > > That's not a good reason not to commit: the fix is in other versions, > including gcj. > I disagree. Just because the version in gcj is different doesn't mean it's correct. As far as I'm aware, Pekka already has a testcase for this so it would be good to have it in Mauve. > Andrew. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Future blog
On 11:03 Thu 09 Dec , Andrew Haley wrote: > On 12/08/2010 08:02 PM, Ivan Maidanski wrote: > > > I remember you (or someone else) had pointed me about of > > inconvenience of reading my patches in the form they were attached > > and I had promised to use ".diff.txt" file extension but forgot > > about it after a long delay. (there is such problem in, say, hpl.com > > mailing list where I frequently send my patches to; besides, I have > > no problem in opening the attachment in the link below in Firefox > > which I use). I apologies for the inconvenience and I'll try to keep > > in my mind that it's better to use .txt extension when posting to > > this ML. > > This turns out to be a known Firefox bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=327323 > > The bugzilla shows a way around this problem. I appended the > following line to my .mailcap: > > application/octet-stream;/usr/bin/emacs "%u" > > So, at least it is now possible to see the patches without first > saving them and then opening in an editor as a separate action. > > Note that I am not recommending that anyone use incorrect MIME-types > in future, just that there is at least a workaround. > It also only solves part of the problem. AFAICS, you still have to open the patch in an external application instead of reading it in the mail itself. > Andrew. > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Re[2]: Future blog
2010/12/8 Ivan Maidanski : > Hi Andrew and Pekka, > > Thank you Pekka but there are also some more ones (in June 2010): > - http://article.gmane.org/gmane.comp.java.classpath.patches/12989 (follow > the link in body to get classpath-ivmai-05.diff); > - http://article.gmane.org/gmane.comp.java.classpath.patches/12988 > (classpath-ivmai-06.diff); > - http://article.gmane.org/gmane.comp.java.classpath.patches/12982 > (classpath-ivmai-07.diff); > - http://article.gmane.org/gmane.comp.java.classpath.patches/12983 > (classpath-ivmai-08.diff); > - http://article.gmane.org/gmane.comp.java.classpath.patches/12984 > (classpath-ivmai-09.diff); > - http://article.gmane.org/gmane.comp.java.classpath.patches/12985 > (classpath-ivmai-10.diff); > - http://article.gmane.org/gmane.comp.java.classpath.patches/12986 > (classpath-ivmai-11.diff); > - http://article.gmane.org/gmane.comp.java.classpath.patches/12991 > (classpath-ivmai-12-v3.diff); > - http://article.gmane.org/gmane.comp.java.classpath.patches/12972 > (classpath-ivmai-14.diff, discussed in > http://article.gmane.org/gmane.comp.java.classpath.patches/12975). > > classpath-ivmai-13.diff has just been reviewed by Andrew. > > And, here is the unprocessed ones listed by Pekka: > - > http://developer.classpath.org/pipermail/classpath-patches/2010-June/006438.html > (classpath-ivmai-15.diff); > - > http://developer.classpath.org/pipermail/classpath-patches/2010-June/006439.html > (classpath-ivmai-16.diff); > - > http://developer.classpath.org/pipermail/classpath-patches/2010-June/006440.html > (classpath-ivmai-17.diff); > - > http://developer.classpath.org/pipermail/classpath-patches/2010-June/006441.html > (classpath-ivmai-18.diff); > - > http://developer.classpath.org/pipermail/classpath-patches/2010-June/006442.html > (classpath-ivmai-19.diff); > - > http://developer.classpath.org/pipermail/classpath-patches/2010-June/006443.html > (classpath-ivmai-20.diff); > - > http://developer.classpath.org/pipermail/classpath-patches/2010-June/006444.html > (classpath-ivmai-21.diff); > - > http://developer.classpath.org/pipermail/classpath-patches/2010-June/006445.html > (classpath-ivmai-22.diff); > - > http://developer.classpath.org/pipermail/classpath-patches/2010-June/006446.html > (classpath-ivmai-23.diff); > - > http://developer.classpath.org/pipermail/classpath-patches/2010-June/006447.html > (classpath-ivmai-24.diff); > - > http://developer.classpath.org/pipermail/classpath-patches/2010-June/006448.html > (classpath-ivmai-25.diff); > > And, some more unprocessed ones posted in July: > - http://article.gmane.org/gmane.comp.java.classpath.patches/13009 > (classpath-ivmai-26.diff); > - http://article.gmane.org/gmane.comp.java.classpath.patches/13010 > (classpath-ivmai-27.diff); > - http://article.gmane.org/gmane.comp.java.classpath.patches/13011 > (classpath-ivmai-28.diff); > - http://article.gmane.org/gmane.comp.java.classpath.patches/13012 > (classpath-ivmai-29.diff); > - http://article.gmane.org/gmane.comp.java.classpath.patches/13013 > (classpath-ivmai-30.diff); > - http://article.gmane.org/gmane.comp.java.classpath.patches/13015 > (classpath-ivmai-31.diff); > - http://article.gmane.org/gmane.comp.java.classpath.patches/13016 > (classpath-ivmai-32.diff); > - http://article.gmane.org/gmane.comp.java.classpath.patches/13018 > (classpath-ivmai-33.diff); > - http://article.gmane.org/gmane.comp.java.classpath.patches/13020 > (classpath-ivmai-34.diff); > - http://article.gmane.org/gmane.comp.java.classpath.patches/13021 > (classpath-ivmai-35.diff); > - http://article.gmane.org/gmane.comp.java.classpath.patches/13022 > (classpath-ivmai-36.diff); > - http://article.gmane.org/gmane.comp.java.classpath.patches/13023 > (classpath-ivmai-37.diff). > > and, the recently published ones (and discussed with Pekka): > - http://article.gmane.org/gmane.comp.java.classpath.patches/13052 > (classpath-ivmai-38.diff); > - http://article.gmane.org/gmane.comp.java.classpath.patches/13056 > (classpath-ivmai-39.diff, the test case provided turned out to be irrelevant > to the patch provided as discussed in the thread > http://thread.gmane.org/gmane.comp.java.classpath.patches/13078); > - http://article.gmane.org/gmane.comp.java.classpath.patches/13058 > (classpath-ivmai-40.diff, just adds the test case for > classpath-ivmai-33.diff). > > I really apologies for such huge amount of patches posted :( > Don't! We should be the ones apologising for not reviewing them sooner. > Regards. > > Wed, 8 Dec 2010 13:32:20 +0200 Pekka Enberg : > >> On Wed, Dec 8, 2010 at 1:13 PM, Andrew Haley wrote: >> >> There's also 10-15 patches from Ivan sitting in the archives >> > >> > Hmm, I had seen some discussion around those and thought they were being >> > addressed. Bring them on! >> >> I'm not sure if this is all of it but it's a start anyway: >> ... > > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Co
Re: Future blog
On 08:16 Wed 08 Dec , Pekka Enberg wrote: > On Wed, Dec 8, 2010 at 1:53 AM, Dr Andrew John Hughes > wrote: > >> As soon as I am back I would like us to at least start moving to > >> mercurial on savannah if people don't mind. > > > > Yes, I do mind. > > > > We already discussed this some time back: > > > > http://developer.classpath.org/pipermail/classpath/2008-June/002629.html > > > > and nothing happened. I don't particularly see any huge benefit to > > moving the repository to a different version control system. It would > > make more sense if there were lots of contributors but there aren't. > > As is, if you're going to put some time in, I'd rather it was spent > > reviewing patches than messing about with the VCS. > > > > One of Pekka's motivations is also flawed: > > > > 'how much problems it causes for developers that don't have commit > > rights to the centralized repository!' > > > > Moving it all to Mercurial just so it's easier for someone else to > > create a forked lower-quality copy that accepts unreviewed patches is > > not a good motivation IMHO. > > > > The discussion earlier today: > > > > http://developer.classpath.org/pipermail/classpath-patches/2010-December/006528.html > > > > shows exactly why we do need patch review and discussion. > > No, no, that's not my motivation at all. Have you used Mercurial or > git? CVS make local *development* unnecessary hard. I'm not trying to > bypass the review process (which is a great thing!) with a tool. I > just find it utterly silly that I need to manually create a git mirror > of your CVS repository to make development experience sane. > I've used a number of DVCS including Mercurial and git. In fact, I use Mercurial on a daily basis for OpenJDK & IcedTea. I agree CVS is not ideal, but it's hardly the biggest problem here. On a side note, if you think Classpath CVS is bad, you should try working with GCC SVN. And no, using the git mirror doesn't really help, GCC's repo is just huge. > Pekka > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Future blog
On 13:03 Wed 08 Dec , Andrew Haley wrote: > On 12/08/2010 12:57 PM, Mario Torre wrote: > > Il giorno mer, 08/12/2010 alle 13.45 +0200, Pekka Enberg ha scritto: > > > >> I completely agree. I have Ivan's patches locally and I'm planning to > >> go through them and resend them to the list unless he beats me to it. > >> > >>Pekka > >> > > > > If we were using mecurial we could use review board or webrew. > > We could, but these just introduce extra barriers: it's very easy > to just read a mail. Let's not get obsessed with tools: the issue > here is social, not technical. > I assume you meant webrev. It does indeed make the patch easier to browse, but on the downside it means you have to be able to open a web page (assuming it's stil available) rather than just having everything in the mail (and thus archived). I don't know review board, but I presume it's something similar? Let's keep things simple. > Andrew. > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Future blog
On 11:13 Wed 08 Dec , Andrew Haley wrote: > On 12/08/2010 10:58 AM, Pekka Enberg wrote: > > On Wed, Dec 8, 2010 at 12:32 PM, Andrew Haley wrote: > >> I hereby offer to review some patches. Please send pointers to the > >> list. > > > > http://developer.classpath.org/pipermail/classpath-patches/2010-November/006511.html > > This needs a ChangeLog, otherwise OK. > > > http://developer.classpath.org/pipermail/classpath-patches/2010-November/006513.html > > This needs a ChangeLog, otherwise OK. > I've already seen these and I agree both seem fine. But Pekka needs a copyright assignment before any more work can be committed. > > http://developer.classpath.org/pipermail/classpath-patches/2010-November/006512.html > > What compatibility problem does this fix? > I'd like to see a test case in Mauve for this before we change this. It is something I've been meaning to look at for a while, but haven't got around to. > > There's also 10-15 patches from Ivan sitting in the archives > > Hmm, I had seen some discussion around those and thought they were being > addressed. Bring them on! > > Andrew. > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Future blog
On 10:32 Wed 08 Dec , Andrew Haley wrote: > On 12/08/2010 10:05 AM, Mark Wielaard wrote: > > >> As is, if you're going to put some time in, I'd rather it was spent > >> reviewing patches than messing about with the VCS. > > > > Point taken. In my defense, I like tinkering with "services" around the > > code base. Having autobuilders, a good dvcs integrated with a bug > > database, etc. help me get motivated that the code base is useful and in > > a good shape. > > > >> Moving it all to Mercurial just so it's easier for someone else to > >> create a forked lower-quality copy that accepts unreviewed patches is > >> not a good motivation IMHO. > > > > That would not be the motivation. Getting rid of the pain that is CVS > > would be. > > Replaced with the pain of Mercurial. :-) > > Anyway, I don't mind that as long as someone else does it. (Clearly, > the issue of developers without commit access is a red herring, as > every developer should have commit access.) > Indeed. The problem is not the VCS. It's that the people with commit access are inactive, and new developers are not at the stage where commit access can be given. Pekka has produced a number of patches that are of good quality and I'd be happy for him to have commit access. However, he first has to complete the copyright assignment process required by the FSF. In Ivan's case, I've reviewed a number of the patches and I've had to do work on most of them to get them in a state where they can be committed. This is why I've been hesitant on giving commit access if the result is that it will break things that may be hard to trace later. I'm not saying every patch has to be perfect. But I do think that they should generally be reviewed, especially when the developer is new to Classpath development. Besides, commit access is not the blocker. Most of my time is spent reviewing the patch, not committing it. It takes a couple of minutes to apply and commit a patch if it's in a state where it can be committed. On a related subject, we should give more people access to Mauve too. I have no idea who's in charge of this any more (it's on sourceware.org). I'd be happier with some of these patches if there were test cases being added to Mauve that showed the benefit. > > Andrew. > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Future blog
On 11:05 Wed 08 Dec , Mark Wielaard wrote: > Hi, > > On Tue, 2010-12-07 at 23:53 +, Dr Andrew John Hughes wrote: > > I'll apologise in advance if some of what I've written below sounds harsh, > > but I'm not that happy with the state of Free Java generally right now. > > And I apologize for not stating the obvious. You are the only active > maintainer of GNU Classpath at the moment. It is unfair we aren't > helping you out more. Especially because there are new hackers wanting > to see their contributions integrated. Just like Mario I do feel > somewhat guilty for not making the time necessary. GNU Classpath is the > project that shaped me and that created a community of friends. > > Please don't feel discouraged by some of the details Pekka is wrong > about. It is the fact that he is so positive and forward looking that > made me agree so much with what he said. We need a wakeup call. People > like what GNU Classpath stands for. It is an important project to move > forward. It is needed to bootstrap the free java world. People want to > contribute. > > Lets see what we can/should do to help you more. I understand some of > your hesitation because we let you down. You are currently the > maintainer that carries the whole load. > Thanks. > > There is no 1.7 API to implement yet, so that's a pointless statement. > > 1.7 will be what OpenJDK implements. We can run japi against it to get > comparisons. > We already do: http://builder.classpath.org/japi/openjdk7-classpath.html though as I said in my reply to Pekka, I don't know how up-to-date the OpenJDK snapshot is. Now you have a better builder, maybe it could be done from the test builds instead. > > I also tend to still believe in the general Classpath spirit that we > > implement primarily to match the requirements of applications, not > > specific applications. > > Yes, I do agree with that. But one of the applications is making sure > IcedTea can be bootstrapped. That will require more 1.6 and eventually > 1.7 work. > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39410 Feel free to get hacking. Every time I update IcedTea7, I usually find some new bug to workaround. > > We have no hope of ever TCKing the thing > > anyway, and to my knowledge it's never been used with a JDK that's not > > Oracle-based so I have no trust in its reliability. > > Cacao got access to the TCK. > http://openjdk.java.net/groups/conformance/JckAccess/jck-access.html > I agree the terms of the TCK are erroneous though. I wouldn't be happy > to have to accept them. It makes open collaboration impossible. But if > someone is really motivated to they could do like cacao did, mix and > match GNU Classpath with Hotspot and make that work. > Maybe 'ever' was a bit far, but I don't think it's the be-all-and-end-all by any means. And yes GNU Classpath + HotSpot may be possible; depends on how the decision making has changed with the transition from Sun to Oracle. The CACAO license, AFAIK, was for CACAO+OpenJDK, not CACAO+GNU Classpath. The latter seems to be forbidden by the license terms (unless you could count JAXWS as a substantial part of OpenJDK?) > > > As soon as I am back I would like us to at least start moving to > > > mercurial on savannah if people don't mind. > > > > Yes, I do mind. > > > > We already discussed this some time back: > > > > http://developer.classpath.org/pipermail/classpath/2008-June/002629.html > > > > and nothing happened. I don't particularly see any huge benefit to > > moving the repository to a different version control system. > > That surprises me. CVS really, really is a pain. I will be offline for > two weeks, having a modern dvcs would be so nice. > This entire discussion mimics the previous one fairly well, with many people outlining benefits and others not seeing the point. I do see _a_ benefit. I just don't think it's the most important thing when there are patches to be reviewed and low output. The biggest problem with CVS is the inability to work remotely, which, while nice, is hardly the biggest reason to change the version control system, when there are other more important things to do that would have a bigger impact IMHO. > > As is, if you're going to put some time in, I'd rather it was spent > > reviewing patches than messing about with the VCS. > > Point taken. In my defense, I like tinkering with "services" around the > code base. Having autobuilders, a good dvcs integrated with a bug > database, etc. help me get motivated that the code base is useful and in > a good shape. > Well if you really wan
Re: Future blog
On 09:20 Wed 08 Dec , Pekka Enberg wrote: > On Wed, Dec 8, 2010 at 1:53 AM, Dr Andrew John Hughes > > > > There are several inaccuracies in the points themselves. I'm not too > > surprised, given that Pekka is still new to the project, but I am surprised > > that you'd agree wholeheartedly with such little hesitation. > > I hope my inaccuracies didn't get into the way of the overall point. > No, and as I said, they were understandable from someone new to the project. > On Wed, Dec 8, 2010 at 1:53 AM, Dr Andrew John Hughes > wrote: > > 1.6 work has already been done on GNU Classpath, though that is now > > some time back; it's all there in the mailing list archives though. > > Last time I tested Jato with GNU Classpath, there were some obvious > missing 1.6 APIs in java.lang.Math, for example. I need to check if > that's changed now. The overall feel I get from GNU Classpath is that > it's quite firmly stuck at 1.5 level, though. > I wasn't saying it was by any means complete, just that there was already some progress in that area and we hadn't decided to do 1.5 only. For example, I updated most of the JMX implementation to the 1.6 level. Live comparisons are here: http://builder.classpath.org/japi/ I don't think the OpenJDK snapshots used have been updated in a while, so the comparison for 7 will be quite dated. > On Wed, Dec 8, 2010 at 1:53 AM, Dr Andrew John Hughes > wrote: > > There is no 1.7 API to implement yet, so that's a pointless statement. > > I also tend to still believe in the general Classpath spirit that we > > implement primarily to match the requirements of applications, not > > specific applications. We have no hope of ever TCKing the thing > > anyway, and to my knowledge it's never been used with a JDK that's not > > Oracle-based so I have no trust in its reliability. > > There's APIs that are likely to make it into 1.7 (e.g. NIO2). I don't > see much to be gained from not implementing them now. You might have a > different view on what should be implemented and what not but that > doesn't make my statement pointless. Ok, maybe not pointless, but hardly 'critical' as you claimed in your blog. Applications aren't going to be relying on 1.7 code just yet. I've only recently started to see 1.6 dependencies (and mainly in OpenJDK). > > >> Now the cool thing would be if I said "lets do them all right now!". > >> But instead I am going on vacation and be offline for about two weeks. > >> Sorry about that. But I didn't want to not respond at all. > >> > >> As soon as I am back I would like us to at least start moving to > >> mercurial on savannah if people don't mind. > > > > Yes, I do mind. > > > > We already discussed this some time back: > > > > http://developer.classpath.org/pipermail/classpath/2008-June/002629.html > > > > and nothing happened. I don't particularly see any huge benefit to > > moving the repository to a different version control system. It would > > make more sense if there were lots of contributors but there aren't. > > As is, if you're going to put some time in, I'd rather it was spent > > reviewing patches than messing about with the VCS. > > Hey, it's not as if I'm making this up! This is a genuine experience > from someone who wanted to contribute a simple thing to GNU Classpath. > While *you* don't see the benefit from transitioning to Mercurial or > git, I certainly do, and I claim other people who are used to modern > tooling see that as well. I didn't say there wasn't a benefit, I said there wasn't a 'huge benefit'. If you read the link I posted, you will see it was me who proposed a shift to Mercurial over two years ago, so I clearly think it is beneficial. I agree CVS isn't ideal by a long shot. However, in the general scheme of things, I don't think it's as important as getting patches reviewed. Moving to Mercurial is not going to make all the patches get reviewed and committed. The real advantages of DVCS show up when you have lots of active developers, and are especially useful in remote situations as they allow you to commit without having to push at the same time. But not having Mercurial hardly stops people writing patches. > > On Wed, Dec 8, 2010 at 1:53 AM, Dr Andrew John Hughes > wrote: > > One of Pekka's motivations is also flawed: > > > > 'how much problems it causes for developers that don't have commit > > rights to the centralized repository!' > > > > Moving it all to Mercurial just so it
Re: Future blog
On 23:06 Tue 07 Dec , Mark Wielaard wrote: > Hi all, > Hi Mark, I'll apologise in advance if some of what I've written below sounds harsh, but I'm not that happy with the state of Free Java generally right now. > For those who didn't see Pekka's blog on planet.classpath.org you can > find it here: > http://penberg.posterous.com/whats-the-future-of-gnu-classpath > > He makes some very good points. I agree with all of them. I agree on the general overtone. Indeed, I already blogged about it: http://blog.fuseyism.com/index.php/2010/11/03/the-homogenisation-of-the-java-platform/ There are several inaccuracies in the points themselves. I'm not too surprised, given that Pekka is still new to the project, but I am surprised that you'd agree wholeheartedly with such little hesitation. Mauve has not been abandoned (as you acknowledge below). You merely need to look at the logs to see that tests have been added e.g. http://sources.redhat.com/cgi-bin/cvsweb.cgi/mauve/gnu/testlet/java/security/Policy/setPolicy.java?cvsroot=mauve I posted to the Mauve mailing list about this last week. It is in the same state as GNU Classpath, in that there are very few contributors, but it has not been abandoned. 1.6 work has already been done on GNU Classpath, though that is now some time back; it's all there in the mailing list archives though. There is no 1.7 API to implement yet, so that's a pointless statement. I also tend to still believe in the general Classpath spirit that we implement primarily to match the requirements of applications, not specific applications. We have no hope of ever TCKing the thing anyway, and to my knowledge it's never been used with a JDK that's not Oracle-based so I have no trust in its reliability. > Now the cool thing would be if I said "lets do them all right now!". > But instead I am going on vacation and be offline for about two weeks. > Sorry about that. But I didn't want to not respond at all. > > As soon as I am back I would like us to at least start moving to > mercurial on savannah if people don't mind. Yes, I do mind. We already discussed this some time back: http://developer.classpath.org/pipermail/classpath/2008-June/002629.html and nothing happened. I don't particularly see any huge benefit to moving the repository to a different version control system. It would make more sense if there were lots of contributors but there aren't. As is, if you're going to put some time in, I'd rather it was spent reviewing patches than messing about with the VCS. One of Pekka's motivations is also flawed: 'how much problems it causes for developers that don't have commit rights to the centralized repository!' Moving it all to Mercurial just so it's easier for someone else to create a forked lower-quality copy that accepts unreviewed patches is not a good motivation IMHO. The discussion earlier today: http://developer.classpath.org/pipermail/classpath-patches/2010-December/006528.html shows exactly why we do need patch review and discussion. > This is just because other > projects around free java (hi openjdk) are also using mercurial and it > seems convenient to use something similar, but other suggestions > appreciated. Hopefully we can do something similar for Mauve (it isn't > abandoned, more in the same state as GNU Classpath). And somehow > integrate/extend it with Malva and the jtreg testsuite from OpenJDK. > (They probably should stay separate projects, but at least the > autobuilder should run them. The autobuilder is in a really bad shape, > but there is a new host already that can pick up the load.) > jtreg would have to be a project to begin with. It doesn't seem to be one at present, and I'd barely call OpenJDK one either. Why else are we all working on IcedTea? > The discussion on the patches mailinglist does show a real problem > though. We have very little active hackers, and so aren't doing very > well helping new hackers like Pekka and Ivan to get their work > integrated. > I agree this is a problem. But whining about it won't help. Getting involved would. I'm doing my best but I can't do everything. There are only so many hours in the day. I'd prefer to spend more of those hours on GNU Classpath rather than the intense boredom of IcedTea/OpenJDK work, but unfortunately that's not how the cards are stacked. > Opinions? Suggestions? Flames? > > Thanks, > > Mark > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Savannah accident
On 30 November 2010 21:23, Mark Wielaard wrote: > On Tue, 2010-11-30 at 19:35 +, Dr Andrew John Hughes wrote: >> That explains why I couldn't cvs update yesterday. I wonder why I >> didn't get this message too? Maybe I just missed it. > > The message is up on http://savannah.gnu.org/ you might have missed it > if you didn't look there after your CVS update failed. > > No I didn't look there. I just assumed it was a temporary glitch. I thought you'd got that in e-mail, didn't realise it was a copy and paste job :-) -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) 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: Savannah accident
On 30 November 2010 11:38, Mark Wielaard wrote: > Hi all, > > If you have been wondering about the GNU Classpath services on savannah > note that they are having trouble. This means CVS and the classpath > project page are currently down. > > For more information see http://savannah.gnu.org/ > > Savannah is currently down - details to follow. > > There's been a SQL injection leading to leaking of encrypted > account passwords, some of them discovered by brute-force > attack, leading in turn to project membership access. > We're reinstalling the system and restoring the data from a safe > backup, November 24th. > Please prepare to recommit your changes since that date. > While effort was made in the past to fix injection > vulnerabilities in the Savane2 legacy codebase, it appears this > was not enough :/ > > > No firm ETA for the return online yet (but during the week). > > * 2010/11/29 21:30 GMT: access to the base host restored, > extracting incremental backup from the 24th > * 2010/11/29 23:30 GMT: finished diagnosing original > attack > > TODO > > * Put services online using backup, except for > password-based ones (e.g. the web interface) > * Fix SQL injection and look for potential others > * Reset passwords > * Implement crypt-md5 support (like /etc/shadow, strong > and LDAP-compatible) hashes > * Implement password strength enforcement > * Bring back web interface > > -- > The Savannah Hackers > > Also see http://identi.ca/group/fsfstatus for information. > > > > That explains why I couldn't cvs update yesterday. I wonder why I didn't get this message too? Maybe I just missed it. At least there haven't been any Classpath CVS changes since the 24th :-( -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) 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: SSL communication problem Classpath 0.97.2
On 13 January 2009 14:09, mohammad jouni wrote: > Hello Everyone , > > I am attempting to run an application that uses SSL communication > using JamVM and GNU Classpath 0.97.2 . > > Every time I attempt to run the application I am presented with the > following error : > > java.io.IOException > at > javax.net.ssl.SSLSocketFactory$ErrorSocketFactory.createSocket(SSLSocketFactory.java:178) > at EchoClient.main(EchoClient.java:18) > Caused by: java.lang.RuntimeException: error instantiating default > socket factory: java.security.KeyManagementException: > java.security.KeyStoreException: > gnu.javax.crypto.keyring.MalformedKeyringException: MAC verification > failed > at javax.net.ssl.SSLSocketFactory.getDefault(SSLSocketFactory.java:147) > at EchoClient.main(EchoClient.java:17) > Caused by: java.security.KeyManagementException: > java.security.KeyStoreException: > gnu.javax.crypto.keyring.MalformedKeyringException: MAC verification > failed > at > gnu.javax.net.ssl.provider.SSLContextImpl.defaultTrustManager(SSLContextImpl.java:283) > at > gnu.javax.net.ssl.provider.SSLContextImpl.engineInit(SSLContextImpl.java:202) > at javax.net.ssl.SSLContext.init(SSLContext.java:291) > at javax.net.ssl.SSLSocketFactory.getDefault(SSLSocketFactory.java:141) > ...1 more > Caused by: java.security.KeyStoreException: > gnu.javax.crypto.keyring.MalformedKeyringException: MAC verification > failed > at > gnu.javax.net.ssl.provider.X509TrustManagerFactory.engineInit(X509TrustManagerFactory.java:173) > at javax.net.ssl.TrustManagerFactory.init(TrustManagerFactory.java:285) > at > gnu.javax.net.ssl.provider.SSLContextImpl.defaultTrustManager(SSLContextImpl.java:270) > ...4 more > Caused by: gnu.javax.crypto.keyring.MalformedKeyringException: MAC > verification failed > at > gnu.javax.crypto.keyring.PasswordAuthenticatedEntry.decode(PasswordAuthenticatedEntry.java:108) > at > gnu.javax.crypto.keyring.GnuPrivateKeyring.load(GnuPrivateKeyring.java:354) > at gnu.javax.crypto.keyring.BaseKeyring.load(BaseKeyring.java:77) > at > gnu.javax.crypto.jce.keyring.GnuKeyring.loadPrivateKeyring(GnuKeyring.java:429) > at gnu.javax.crypto.jce.keyring.GnuKeyring.engineLoad(GnuKeyring.java:350) > at java.security.KeyStore.load(KeyStore.java:500) > at > gnu.javax.net.ssl.provider.X509TrustManagerFactory.engineInit(X509TrustManagerFactory.java:169) > ...6 more > > I attempted to add the certificate using each of these commands , but > on both instances i encountered the same error > > sh /usr/lib/classpath/gkeytool -import -alias dm -keystore > /usr/lib/security/cacerts -file /root/Cert.crt > > sh /usr/lib/classpath/gkeytool -import -keystore > /usr/lib/security/cacerts -trustcacerts -file /root/Cert.crt > > Thank you > > It would be helpful if you could provide a simple reproducer e.g. applying the attached certificate X and running attached program Y cause the failure. >From what you've written here, it's unclear how anyone would be able to reproduce this reliably, let alone fix it. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) 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: Fwd: can get mouse events with javac but not gcj ... what's wrong?
On 7 June 2010 20:55, Mario Torre wrote: > Il giorno lun, 07/06/2010 alle 20.34 +0100, Andrew Haley ha scritto: >> Any suggestions from Classpath hackers? >> >> Andrew. > > Hi Andrew, > > It works for me: > > gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) > > Cheers, > Mario > -- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > Proud GNU Classpath developer: http://www.classpath.org/ > Read About us at: http://planet.classpath.org > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/ > > > Saw the conversation on IRC. Works for me too with gij 4.5.0 and GNU Classpath HEAD with jamvm. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) 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: Errors at building classpath, info attached (Real One)
On 30 April 2010 11:17, Mario Torre wrote: > Il giorno gio, 29/04/2010 alle 22.06 -0300, Marcos Roriz ha scritto: >> Sorry for the last post, I hit enter unintentionally. >> Guys, I tried building yersteday classpath cvs and after some problems >> I got it to work :) > > Parabens Marcos, é muito bom! > > This means you got the first HelloWorld running? :) > >> First I'll tell what I had to do to get eclipse to get out of the red >> state in errors. I copied these two files (which the wiki refers) >> to .java: >> * classpath/gnu/classpath/Configuration.java.in >> * classpath/gnu/java/security/Configuration.java.in >> Because the build uses the .in to configure, don' t move them (yes I >> did that :'[). Also add the jaxme jar (usually on /usr/share/java) to >> the build path (I thought that I needed antlr, am I missing something >> here?) and we go down to two errors I think, which are basically >> incompatibility with my version of jaxme. > > Oh, bad eclipse... I don't use it since ages, so I can't really help > much here, but I remember this specific error. It should go away once > you do a full build from command line, because those files are generated > during the configure process (just refresh the project). > >> About the build problems: >> Here's the first problem, it complains about the following errors >> (Error 1) which can be fixed with Giuseppe Scrivano patch. I wonder >> why the thread isn't showing on classpath-patch mailing list. > > Mmm, we should probably get this patch in so. I'm not sure why we didn't > yet (well, perhaps nobody noticed it... :) > > Pun: If you succeed in making us commit this patch, you basically > already pass the first task (revive GNU Classpath :P > No, it's because it's not the correct fix (as the author himself mentions). I posted a patch too which properly corrects the warnings with a union but we're dubious about applying it without more testing. We decided instead to just add -fno-strict-aliasing. http://developer.classpath.org/pipermail/classpath/2009-October/002962.html I thought this had been done, but clearly not. I'll add it later today. You can workaround the build failure by adding --disable-Werror. >> The second error is about building the web plugin. It seems that on >> ubuntu the mozilla headers are separated on two folders stable and >> unstable. The build only get the stable directory. So here we can >> upgrade to a newer version (which only have one directory) or compile >> our own xulrunner. I did an upgrade to a newer version (got lucid >> version), the error went away. > > I'm not sure on that either. Andrew(s)? I think this is because of some > incompatibilities introduced by recent Firefox, if I'm not wrong, the > development of the plugin moved completely in the IcedTea project, if > that's the case, you may skip it (it's not needed for Escher anyway). If > you make it work, or you really have time for that and want to try it, > go for it, hacking is always fun, but keep in mind that is more > important to get the whole thing up and running first than having each > subsystem working properly (you need to fix GNU Classpath/Escher > integration now). > i've mentioned before that we should probably just remove it, given development has shifted to IcedTea. We should at least not have it enabled by default. >> I wonder if I can add this info on the wiki. What you guys think? > > Sure, this would be great, please do it. I don't think we need to wait > your paperwork for the wiki, Mark? (please, also keep a copy of your > contributed diff for anything you do, even website/wiki changes). > > Cheers, > Mario > > > -- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > Proud GNU Classpath developer: http://www.classpath.org/ > Read About us at: http://planet.classpath.org > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/ > > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) 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: libjava multilib support
[CCing the GNU Classpath list as this is a Classpath patch] On 4 May 2010 12:00, Andrew Haley wrote: > On 05/04/2010 10:36 AM, Mike Stump wrote: >> On Mar 25, 2010, at 11:09 AM, Mike Stump wrote: >>> libjava on darwin doesn't build because it lacks proper gmp support from >>> configure. This patch enhances it by adding the proper -I and -L flags for >>> finding the gmp library when building. This patch is better than that >>> status quo, but like the status quo, lacks proper target != host support. >>> When the gmp flags aren't given, we just do what was done before. >>> >>> Ok? >> >> Ping? >> >> http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01211.html > This looks sane to me and I'll add it to GNU Classpath. > I don't really understand this patch. Why does libjava need gmp? > Native support for java.math.BigInteger, see --enable-gmp. > Andrew. > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) 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: Problem compiling docs for Crypto
On 22 March 2010 17:39, Daniel B. Davis wrote:
> Hello --
>
> I am sending this to both the Cnu Crypto mailing list and the Gnu Classpath
> list,
> since I am not sure which is active.
>
GNU Crypto was merged into GNU Classpath in 2004:
2004-08-14 Casey Marshall
The Big Crypto Merge of 2004.
>From release 0.90 (March 6th, 2006):
* GNU Crypto and Jessie have been merged into GNU Classpath; this
provides Classpath with a wide array of cryptographic algorithms
(ciphers, message digests, etc.) and implementations of SSL version
3 and TLS version 1. These roughly complement the public
`java.security.' `javax.crypto,' and `javax.net.ssl' packages, and
are service providers implementing the underlying algorithms.
So any issues should be fixed in GNU Classpath.
> I tried to compile the material under Gnu Crypto in order to use your
> Blowfish
> (or Twofish) algorithm, and got the errors shown below. In working on them,
> I
> finally noticed that it had been 'merged' into Gnu Classpath. I downloaded
> Classpath, but could not find the missing Crypto files there.
>
Look under gnu/javax/crypto.
$ ls gnu/javax/crypto/cipher/
Anubis.java Cast5.java DES.java Khazad.java
Serpent.javaTwofish.java
BaseCipher.java CipherFactory.java IBlockCipher.java
NullCipher.java Square.java WeakKeyException.java
Blowfish.javaCVS/IBlockCipherSpi.java
Rijndael.javaTripleDES.java
> Please help.
>
> Daniel B. Davis
>
> Errors:
> Microsoft Windows [Version 6.0.6001]
> Copyright (c) 2006 Microsoft Corporation. All rights reserved.
>
> C:\temp\gnu-crypto-2.0.1>ant docs
> Buildfile: build.xml
>
> -init:
> [mkdir] Created dir: C:\temp\gnu-crypto-2.0.1\classes
> [mkdir] Created dir: C:\temp\gnu-crypto-2.0.1\lib
>
> -check-args:
>
> -build-jce-jar:
> [echo] About to compile Java Cryptography Extension (JCE) sources...
> [javac] Compiling 83 source files to C:\temp\gnu-crypto-2.0.1\classes
> [javac] Note: Some input files use unchecked or unsafe operations.
> [javac] Note: Recompile with -Xlint:unchecked for details.
> [echo] About to make a Java Cryptography Extension (JCE) jar...
> [jar] Building jar: C:\temp\gnu-crypto-2.0.1\lib\javax-crypto.jar
> [echo] About to compile javax.security sources...
> [javac] Compiling 20 source files to C:\temp\gnu-crypto-2.0.1\classes
> [javac] Note:
> C:\temp\gnu-crypto-2.0.1\security\javax\security\sasl\Sasl.jav
> a uses unchecked or unsafe operations.
> [javac] Note: Recompile with -Xlint:unchecked for details.
> [echo] About to make javax.security jar
> [jar] Building jar: C:\temp\gnu-crypto-2.0.1\lib\javax-security.jar
>
> -init-jce-jar:
>
> init:
>
> -compile-with-jce:
> [echo] About to compile .java sources including JCE specific ones...
> [javac] Compiling 306 source files to C:\temp\gnu-crypto-2.0.1\classes
> [javac]
> C:\temp\gnu-crypto-2.0.1\source\gnu\crypto\sasl\ClientMechanism.java
> :143: getNegotiatedProperty(java.lang.String) in
> gnu.crypto.sasl.ClientMechanism
> cannot implement getNegotiatedProperty(java.lang.String) in
> javax.security.sasl
> .SaslClient; overridden method does not throw
> javax.security.sasl.SaslException
> [javac] public Object getNegotiatedProperty(final String propName)
> throws
> SaslException {
> [javac] ^
> [javac]
> C:\temp\gnu-crypto-2.0.1\source\gnu\crypto\sasl\ServerMechanism.java
> :150: getNegotiatedProperty(java.lang.String) in
> gnu.crypto.sasl.ServerMechanism
> cannot implement getNegotiatedProperty(java.lang.String) in
> javax.security.sasl
> .SaslServer; overridden method does not throw
> javax.security.sasl.SaslException
> [javac] public Object getNegotiatedProperty(final String propName)
> throws
> SaslException {
> [javac] ^
> [javac]
> C:\temp\gnu-crypto-2.0.1\source\gnu\crypto\sasl\anonymous\AnonymousC
> lient.java:61: getNegotiatedProperty(java.lang.String) in
> gnu.crypto.sasl.Client
> Mechanism cannot implement getNegotiatedProperty(java.lang.String) in
> javax.secu
> rity.sasl.SaslClient; overridden method does not throw
> javax.security.sasl.SaslE
> xception
> [javac] public class AnonymousClient extends ClientMechanism implements
> Sasl
> Client {
> [javac] ^
> [javac]
> C:\temp\gnu-crypto-2.0.1\source\gnu\crypto\sasl\anonymous\AnonymousS
> erver.java:60: getNegotiatedProperty(java.lang.String) in
> gnu.crypto.sasl.Server
> Mechanism cannot implement getNegotiatedProperty(java.lang.String) in
> javax.secu
> rity.sasl.SaslServer; overridden method does not throw
> javax.security.sasl.SaslE
> xception
> [javac] public class AnonymousServer extends ServerMechanism implements
> Sasl
> Server {
> [javac] ^
> [javac]
> C:\temp\gnu-crypto-2.0.1\source\gnu\crypto\sasl\crammd5\CramMD5Clien
> t.java:66: getNegotiatedProperty(java.lang.String) in
> gnu.crypto.sasl.ClientMech
> anis
Re: netif.h present but unusable on Mac
2009/11/22 Richard O'Keefe : > The host is an Intel Core 2 Duo processor running Mac OS X version 10.5.7 > > I downloaded the JikesRVM version 3.1.0 and having checked that > ia32-osx was supported set out to build it. The manual says that > it needs GNU Classpath, and that I should download and install > that by doing ant -f build/components/classpath.xml, which I did. > > [exec] checking ifaddrs.h usability... yes > [exec] checking ifaddrs.h presence... yes > [exec] checking for ifaddrs.h... yes > [exec] checking netinet/in_systm.h usability... yes > [exec] checking netinet/in_systm.h presence... yes > [exec] checking for netinet/in_systm.h... yes > [exec] checking netinet/ip.h usability... yes > [exec] checking netinet/ip.h presence... yes > [exec] checking for netinet/ip.h... yes > [exec] checking net/if.h usability... no > [exec] checking net/if.h presence... yes > [exec] configure: WARNING: net/if.h: present but cannot be compiled > [exec] configure: WARNING: net/if.h: check for missing prerequisite > headers? > [exec] configure: WARNING: net/if.h: see the Autoconf documentation > [exec] configure: WARNING: net/if.h: section "Present But Cannot Be > Compiled" > [exec] configure: WARNING: net/if.h: proceeding with the preprocessor's > result > [exec] configure: WARNING: net/if.h: in the future, the compiler will > take precedence > [exec] configure: WARNING: ## ## > [exec] configure: WARNING: ## Report this to classpath@gnu.org ## > [exec] configure: WARNING: ## ## > [exec] checking for net/if.h... yes > > There was a further problem later down where the Ant script said > [exec] configure: error: The Java compiler > /home/cshome/o/ok/Desktop/jikesrvm-3.1.0/components/ecj/3.2/ecj-3.2/ecj > failed (see config.log, check the CLASSPATH?) > [exec] checking if > /home/cshome/o/ok/Desktop/jikesrvm-3.1.0/components/ecj/3.2/ecj-3.2/ecj > works... > > > Since ...components/ecj doesn't exist, it's not surprising that it > doesn't "work". This leads me to suspect a problem with the Ant > script. > > > As your mail concerns JikesRVM, I'm including the main JikesRVM list in this discussion (see http://jikesrvm.org/Mailing+Lists) My first suggestion would be that you try running the main build.xml in the root of the RVM tree by invoking 'ant' from that directory. You will need to set host.name to the desired value from build/hosts, ia32-osx in your case, so use 'ant -Dhost.name=ia32-osx'. Invoking the Classpath sub-build separately, as you do above, will mean that any prerequisites for it are not being built. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) 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: Classpath 0.98 & jks
2009/11/12 Arigead : > Hello All, > sorry new here and haven't had time to lurk for a while to see the > lie of the land. > > I'm trying to run Jxta on Jamvm 1.5.3 with Classpath 0.98. I'm getting > an error because of jks security not being found. I'll post the error > I'm getting at the end of this email. > > A bit of searching on the Internet gives me a few posts by somebody with > a similar problem [1] & [2]. I can't find any responses and solutions to > this problem. > > I'm not sure how to get around this issue. I'm sure that there are many > implementations of this security algorithm and I wonder can a lump of > code be added included into the JRE or can source code be added to > classpath. I mean there could I, if I had a clue ;-) add the necessary > code into classpath source? I'd prefer if I could pull in something like > BouncyCastle, although I'm not sure it would solve the problem as I'm > not sure it implements this functionality. > > I'm not great with Java I'm afraid so I'm not sure that a BounceyCastle > could be used to implement functionality that is being requested of the JRE. > > Sorry for a newbie post and thanks a million for any advice that anybody > can offer. > > > [1] > http://old.nabble.com/Problem-in-using-SSL-%28secure-socket%29-with-classpath-0.98-and-Jamvm-1.5.3-td23997596.html > [2] http://www.mail-archive.com/classpath@gnu.org/msg15120.html > > > > > Caused by: java.security.KeyStoreException: jks > at java.security.KeyStore.getInstance(KeyStore.java:203) > at java.security.KeyStore.getInstance(KeyStore.java:130) > at > net.jxta.impl.membership.pse.CMKeyStoreManager.(CMKeyStoreManager.java:148) > at > net.jxta.impl.membership.pse.PSEKeyStoreManagerFactory$PSEKeyStoreManagerFactoryDefault.getInstance(PSEKeyStoreManagerFactory.java:143) > ...24 more > Caused by: java.security.NoSuchAlgorithmException: Algorithm [jks] of > type [KeyStore] from provider > [gnu.javax.security.auth.callback.GnuCallbacks: name=GNU-CALLBACKS > version=2.1] is not found > at gnu.java.security.Engine.getInstance(Engine.java:191) > at gnu.java.security.Engine.getInstance(Engine.java:105) > at java.security.KeyStore.getInstance(KeyStore.java:188) > ...27 more > > > > > > jks is not a crypto algorithm but a keystore format, and a proprietary Sun one until the release of OpenJDK. I guess in theory support could now be developed using the Sun source code as a reference, but there's not much work on Classpath in general at present. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34731 -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) 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: Aliasing violations in gnu_java_nio_VMChannel.c
2009/10/23 Andrew Haley : > Andrew John Hughes wrote: >> 2009/10/22 Andrew Haley : >>> This: >>> >>> >>> #ifdef HAVE_GETPEERNAME >>> #ifdef HAVE_INET6 >>> struct sockaddr_in6 *addr6; >>> struct sockaddr_in6 sock_storage; >>> socklen_t socklen = sizeof (struct sockaddr_in6); >>> #else >>> struct sockaddr_in sock_storage; >>> socklen_t socklen = sizeof (struct sockaddr_in); >>> #endif /* HAVE_INET6 */ >>> >>> struct sockaddr *sockaddr = (struct sockaddr *) &sock_storage; >>> >>> >>> is clearly an aliasing violation: sock_storage is of type struct >>> sockaddr_in6, >>> and *sockaddr is of type struct sockaddr. >>> >>> It would be easy enough to fix the code with a union, but I can't test it >>> because gcj doesn't use this code. I could simply compile with >>> -fno-strict-aliasing. >>> >>> Thoughts? >>> >>> Andrew. >>> >>> >> >> I posted a patch sometime ago to do exactly that (use a union), but >> received no response: >> >> http://developer.classpath.org/pipermail/classpath-patches/2009-June/006341.html >> >> It does need more testing than I've had chance to give it so far, I >> just haven't had time to do any more work on it. > > I seriously wonder if it's worth the effort. I just did this: > > Index: configure.ac > === > RCS file: /sources/classpath/classpath/configure.ac,v > retrieving revision 1.244 > diff -c -u -r1.244 configure.ac > --- configure.ac 6 Feb 2009 02:21:23 - 1.244 > +++ configure.ac 23 Oct 2009 09:10:33 - > @@ -514,7 +514,7 @@ > dnl CFLAGS that are used for all native code. We want to compile > dnl everything with unwinder data so that backtrace() will always > dnl work. > - EXTRA_CFLAGS='-fexceptions -fasynchronous-unwind-tables' > + EXTRA_CFLAGS='-fexceptions -fasynchronous-unwind-tables > -fno-strict-aliasing' > AC_SUBST(EXTRA_CFLAGS) > > dnl Strict warning flags which not every module uses. > > which is a much safer change. It will somewhat pessimize other native code, > that's true, but will that make any real difference to anyone these days? > > Andrew. > Why not just amend the CFLAGS in the local Makefile.am for cpnet? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) 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: Aliasing violations in gnu_java_nio_VMChannel.c
2009/10/22 Andrew Haley : > This: > > > #ifdef HAVE_GETPEERNAME > #ifdef HAVE_INET6 > struct sockaddr_in6 *addr6; > struct sockaddr_in6 sock_storage; > socklen_t socklen = sizeof (struct sockaddr_in6); > #else > struct sockaddr_in sock_storage; > socklen_t socklen = sizeof (struct sockaddr_in); > #endif /* HAVE_INET6 */ > > struct sockaddr *sockaddr = (struct sockaddr *) &sock_storage; > > > is clearly an aliasing violation: sock_storage is of type struct sockaddr_in6, > and *sockaddr is of type struct sockaddr. > > It would be easy enough to fix the code with a union, but I can't test it > because gcj doesn't use this code. I could simply compile with > -fno-strict-aliasing. > > Thoughts? > > Andrew. > > I posted a patch sometime ago to do exactly that (use a union), but received no response: http://developer.classpath.org/pipermail/classpath-patches/2009-June/006341.html It does need more testing than I've had chance to give it so far, I just haven't had time to do any more work on it. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) 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: Cacao + Classpath + RMI
2009/9/28 Goddchen : > Hey everybody, > we are trying to get a little project running on an embedded system. The > java environment is cacao + gnu classpath. We want to get a simple rmi > example running. > We can successfully bind the server instance without any problems at all. > But when launching the client (which just does a lookup and a call of one > remote helloworld-function) it crashes. > > # java rmi.Client > java.rmi.UnmarshalException: error unmarshalling return; nested exception > is: > java.io.WriteAbortedException: Exception thrown during writing of > stream; java.io.IOException > at > gnu.java.rmi.registry.RegistryImpl_Stub.lookup(RegistryImpl_Stub.java:194) > at java.rmi.Naming.lookup(Naming.java:110) > at rmi.Client.main(Client.java:14) > Caused by: java.io.WriteAbortedException: Exception thrown during writing of > stream; java.io.IOException > at java.io.ObjectInputStream.parseContent(ObjectInputStream.java:512) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:215) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:137) > at java.io.ObjectInputStream.readFields(ObjectInputStream.java:1962) > at java.io.ObjectInputStream.parseContent(ObjectInputStream.java:465) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:215) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:137) > at > gnu.java.rmi.registry.RegistryImpl_Stub.lookup(RegistryImpl_Stub.java:190) > ...2 more > Caused by: java.io.IOException > <> > Caused by: java.lang.NullPointerException: [Ljava/lang/StackTraceElement; > <> > error in client > > Any ideas on this one? We don't have a clue what the error could be. > We already checked that the java code is compiled with java 1.5. Maybe it's > something with the stub-generation of classpath? > > Greets Goddchen > > -- > Mit freundlichen Grüßen > Martin Liersch >> Blog: http://blog.goddchen.de >> Website: http://www.goddchen.de > It's difficult to tell from just this. Could you post a suitable testcase which illustrates this bug? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) 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: issue using jfree chart with gnu classpath 0.98
2009/8/17 New User :
> Hi,
>
> I'm not part of the GNU Classpath team, but I'm using it and well, I have to
>
> say that I love it! At least for embedded systems it's great...
>
> But to answer your question, the method font.getName() isn't implemented
> (yet) in GNU Classpath 0.98. You can check the coverage for GNU Classpath
> against Java 1.5 on this site: http://www.kaffe.org/~stuart/japi/htmlout/h-
> jdk15-classpath.html
>
> There you can find: 'method java.awt.Font.getName(): missing in classpath'.
> What is a nice answer I guess... It don't means that you can't use the
> java.awt.Font, but the method .getName isn't implemented yet.
>
> I hope this is a good answer for you question...
>
> Good luck,
> Jan Pannecoeck
>
>
>
> Dhaval Yoganandi wrote:
>>
>
> Hi GNU classpath team,
>>
>>I'm facing some problem using jfree chart with GNU classpath 0.98 and
>>JamVM. I'm using a redhat based linux which is only console based linux
>>and doesn't support desktop and graphics. while running following demo
>>in my machine with JamVM I get NullPointerException but it is working
>>fine with JDK 1.5 with update 14. While generating chart with jfree
>>chart it is also giving the same error.
>>
>>import java.awt.Font;
>>public class FontDemo{
>> public static void main(String args[]){
>> Font f = new Font("SansSerif", Font.BOLD, 18);
>> System.out.println(f.getName());
>> }
>>}
>>
>>OUTPUT:
>>/bin/jamvm/bin/jamvm -cp . FontDemo Exception in thread "main"
>>java.lang.NullPointerException
>> at java.awt.Font.getName(Font.java:427)
>> at FontDemo.main(FontDemo.java:5)
>>
>>can you shed some more light on this issue ?
>>
>>--
>>Thanks and Regards,
>>
>>Dhaval Yoganandi,
>>Jr. Software Engineer,
>>Elitecore Technologies Ltd.
>>Cyberoam.
>>
>>
>>
>
>
>
>
Jan,
Thanks for the positive comments. However, the link you refer to is
very outdated (2007). If you check:
http://builder.classpath.org/japi/jdk15-classpath.html
you will find results against the current version of GNU Classpath,
rebuilt several times daily.
Links to this are available on the GNU Classpath homepage:
http://www.gnu.org/software/classpath
getName() is implemented, that's why it throws a NullPointerException
rather than not compiling. Dhaval, please file this as a bug at
http://gcc.gnu.org/bugzilla
--
Andrew :-)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
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: Does SSL works at all in classpath version 0.98 ???
2009/7/16 Audrius Meskauskas : > alk.shr wrote: >> i am not able to run my web application on HTTPS port (secure port through >> SSL) although it run fine on normal HTTP port. > This is a bug that must be verified. I add this to Bugzilla. > > See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40774 now. You can also > register and then be notified about changes in the bug. > > Thanks for so comprehensive report. > > Audrius > > > > Test cases for this issues would also help. I don't see how these failures can be replicated from the information given. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) 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: Problem in building GNU classpath 0.98 with sun JDK1.6 compiler
2009/6/11 alk.shr : > > I am getting below error trying to build GNU classpath 0.98 with sun JDK1.6 > compiler on debian linux system- > > Making all in scripts > make[1]: Entering directory `/jvm/classpath-0.98/scripts' > make[1]: Nothing to be done for `all'. > make[1]: Leaving directory `/jvm/classpath-0.98/scripts' > Making all in tools > make[1]: Entering directory `/jvm/classpath-0.98/tools' > /bin/mkdir -p classes asm > /bin/mkdir -p ../tools/generated/gnu/classpath/tools/gjdoc/expr > java -classpath antlr.Tool -o > ../tools/generated/gnu/classpath/tools/gjdoc/expr/ \ > ./gnu/classpath/tools/gjdoc/expr/java-expression.g > Unrecognized option: -o > Could not create the Java virtual machine. > make[1]: *** [tools.zip] Error 1 > make[1]: Leaving directory `/jvm/classpath-0.98/tools' > make: *** [all-recursive] Error 1 > > command used to configure classpath is given below- > ./configure --disable-gtk-peer --disable-plugin --disable-gconf-peer > --enable-tools > > Please help to resolve above build error in classpath. > -- > View this message in context: > http://www.nabble.com/Problem-in-building-GNU-classpath-0.98-with-sun-JDK1.6-compiler-tp23975962p23975962.html > Sent from the Gnu - Classpath - General mailing list archive at Nabble.com. > > > You're missing antlr. But configure should have caught this earlier, so might be useful to post your config.log. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) 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: [Fwd: compiling errors with latest gcc 4.4 and AWT/Swing]
2009/4/14 David Michel :
> Hi All,
>
> I was recently trying to run a java project, developed for and run
> with Sun's java, with the gcc compiler instead. When I first installed
> the gcj available from the Ubuntu repository, I ran into compilation
> erros and then realised that the version shipped on the repos was
> relatively old (4.2.4) so I decided to upgrade it to the latest one,
> hoping that these compilation issues will get resolved.
>
> With great help from this forum, I got the newest GCC running on my
> machine with the following commands:
>
> $ svn co http://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch/
> $ mkdir gcc-4_4-branch/obj-x86_64-unknown-linux-gnu
> $ cd gcc-4_4-branch/obj-x86_64-unknown-linux-gnu
> $ `pwd`/../configure --enable-languages=java
> --prefix=/local/gcc-4_4-branch/install --enable-java-home
> --enable-java-awt=gtk
> $ make && make install
> $ /local/gcc-4_4-branch/install/lib/jvm/bin/java -version java version
> "1.5.0" gij (GNU libgcj) version 4.4.0 20090330 (prerelease)
>
> Using Eclipse, I linked my project to the newly installed JRE
> (JRE home directory on '/local/gcc-4_4-branch/install/lib/jvm' ; JRE
> system libraries on
> '/local/gcc-4_4-branch/install/share/java/libgcj-4.4.0.jar' and the
> sourcefile on '~/gcc-4_4-branch/libjava/classpath' )
>
> When I try ro tun the project (from Eclipse), I ran into exactly the
> same compilation errors as encountered with the older gcc version:
>
> Exception in thread "main" java.lang.IllegalArgumentException
> at javax.swing.ScrollPaneLayout.addLayoutComponent(ScrollPaneLayout.java:148)
> at java.awt.Container.addImpl(Container.java:392)
> at java.awt.Container.add(Container.java:230)
> at nl.kbna.dioscuri.GUI.setScreen(GUI.java:512)
> at nl.kbna.dioscuri.GUI.(GUI.java:256)
> at nl.kbna.dioscuri.GUI.(GUI.java:295)
> at nl.kbna.dioscuri.GUI.main(GUI.java:213)
>
> The problem seem to lie with AWT and Swing... and by digging deeper
> into the code I found that:
>
> In GUI.java the following call is made:
> screenPane.add(screen);
> This works using Sun's Java, but causes a IllegalArgumentException in
> GCJ and the reason seems to be as follows:
>
> GCJ java.awt.Container class on line 276 contains code for the above call:
> add(Component comp)
> {
> addImpl(comp, null, -1)
> }
>
> The addImpl function calls, near the end (line 390):
> layoutMgr.addLayoutComponent("", comp);
> because it was passed null constraints.
>
> The ScrollPaneLayout class implements the addLayoutComp (line 125):
> addLayoutComponent(String key, Component component)
> but notice that the 'key' variable has been passed an empty String;
> this function now throws an IllegalArgumentException.
>
> As anyone had this sort of problem ? Any idea how to fix it ?
> Could it be a problem of mixing AWT and Swing together ?
>
> Regards
>
> David Michel
>
>
It's not necessary to mix the two to trigger this bug. You merely
need to add a component to a component using the ScrollPaneLayout:
public TestSwing()
{
setLayout(new ScrollPaneLayout());
add(new JButton());
}
This runs on IcedTea but fails on Classpath:
Exception in thread "main" java.lang.IllegalArgumentException
at javax.swing.ScrollPaneLayout.addLayoutComponent(ScrollPaneLayout.java:148)
at java.awt.Container.addImpl(Container.java:392)
at java.awt.Container.add(Container.java:297)
at javax.swing.JFrame.addImpl(JFrame.java:264)
at java.awt.Container.add(Container.java:230)
at TestSwing.(TestSwing.java:12)
at TestSwing.main(TestSwing.java:17)
The error is not in ScrollPaneLayout. Changing the code to:
ScrollPaneLayout l = new ScrollPaneLayout();
l.addLayoutComponent("", new JButton());
correctly triggers an IllegalArgumentException on both IcedTea and Classpath:
$ cacao TestSwing
Exception in thread "main" java.lang.IllegalArgumentException
at javax.swing.ScrollPaneLayout.addLayoutComponent(ScrollPaneLayout.java:148)
at TestSwing.(TestSwing.java:12)
at TestSwing.main(TestSwing.java:19)
$ /usr/lib/icedtea6/bin/java TestSwing
Exception in thread "main" java.lang.IllegalArgumentException: invalid
layout key
at
javax.swing.ScrollPaneLayout.addLayoutComponent(ScrollPaneLayout.java:257)
at TestSwing.(TestSwing.java:12)
at TestSwing.main(TestSwing.java:19)
Existing bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39553
--
Andrew :-)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
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
FOSDEM 2009 Recordings
2009/3/25 Andrew John Hughes : > You can now find Deepak's talk on 'The IcedTea Plugin' here: > > http://www.archive.org/details/fosdem_2009_free_java_the_icedtea_plugin > > Blurb from Deepak > (http://fosdem.org/2009/schedule/events/java_icedtea_plugin): > > 'This talk is about the IcedTea Java Web Browser Plugin. > > It will be mostly technical -- starting off with the need for the > plugin and it's history. It will then delve into the elements of > plugin design, and implementation details affecting speed, security > and reliability. > > Finally, it will also cover known limitations, and future plans to fix > those limitations.' > > It's available under the Creative Commons Attribution No-Derivative > license (http://creativecommons.org/licenses/by-nd/2.0/uk/). Please > feel free to distribute copies under those terms. > > Thanks to Deepak Bhole for allowing this to be made available. > > If there are any issues with the publication of these talks, please > contact me ASAP. > > More to come in time and with appropriate permissions, > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > 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 > Robert Schuster's talk on cross-compiling IcedTea is now available. You can find all the talks with links to the slides as well on http://fuseyism.com#movies. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) 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
FOSDEM 2009: IcedTea Plugin Talk Recording Available
You can now find Deepak's talk on 'The IcedTea Plugin' here: http://www.archive.org/details/fosdem_2009_free_java_the_icedtea_plugin Blurb from Deepak (http://fosdem.org/2009/schedule/events/java_icedtea_plugin): 'This talk is about the IcedTea Java Web Browser Plugin. It will be mostly technical -- starting off with the need for the plugin and it's history. It will then delve into the elements of plugin design, and implementation details affecting speed, security and reliability. Finally, it will also cover known limitations, and future plans to fix those limitations.' It's available under the Creative Commons Attribution No-Derivative license (http://creativecommons.org/licenses/by-nd/2.0/uk/). Please feel free to distribute copies under those terms. Thanks to Deepak Bhole for allowing this to be made available. If there are any issues with the publication of these talks, please contact me ASAP. More to come in time and with appropriate permissions, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) 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: Problems building classpath on MIPS
2009/3/17 Manuel Lauss : > On Mon, Mar 16, 2009 at 11:32:10PM +0000, Andrew John Hughes wrote: >> 2009/3/16 Manuel Lauss : >> > On Mon, Mar 16, 2009 at 09:13:18AM +, Andrew Haley wrote: >> >> Manuel Lauss wrote: >> >> >> >> > >> >> > Did I miss any prerequisites? >> >> > Any help is very much appreciated! >> >> >> >> Well, what are you trying to do? ??GNU Classpath usually has to be >> >> customized for whatever runtime it's going to be running on. ??So, >> >> what runtime will you use? >> > >> > Is that documented somewhere? ??I assume by runtime you mean the VM. >> > In this case, the target is cacaovm (although I'm flexible here) >> > >> > >> >> Andrew. >> > >> > Thanks! >> > ?? ?? ?? ??Manuel Lauss >> > >> > >> >> CACAO is a good choice, it should work just fine with an uncustomised >> copy of GNU Classpath. >> >> It seems that configure is defaulting to using gcj to compile and for >> some reason, this is failing. From your output, it seems like gcj is >> trying to compile more than just the Test.java file and is actually >> trying to compile a lot of the GNU Classpath sourcecode during the >> configure process! The thing to try first is to build outside the >> source directory: >> >> cd .. >> mkdir classpath-build >> cd classpath-build >> CFLAGS="-O2 -mips32 -msoft-float" ../classpath-0.98/configure >> --prefix=/opt/classpath --build=mipsel-softfloat-linux-gnu >> --host=mipsel-softfloat-linux-gnu --target=mipsel-softfloat-linux-gnu >> --disable-gconf-peer --disable-gtk-peer --disable-plugin --enable-gmp >> --enable-regen-headers --enable-static --enable-shared --disable-rpath >> --with-gnu-ld >> >> If this works, let us know; it may be that there is a bug with using >> gcj for in-tree compiles. There was a similar issue for older >> versions of javac. > > Yes it does! Good. However the following "gij Test" aborts with value 134; > (it segfaults on a futex() call and is finally killed with SIGIOT). > Ok, as Andrew says, it sounds like something is very broken in your installation of gcj. But this has nothing to do with the copy of GNU Classpath you just built. GCJ carries its own modified version of GNU Classpath. What you need to do next (other than possibly fixing your gcj install) is build CACAO against the GNU Classpath you built so it can be used. > >> More generally, the fact that gcj is being used as the compiler >> implies that it has already failed to find either ecj or javac. You >> can explicitly set the compiler to use by setting the JAVAC >> environment variable in the same way you set CFLAGS. >> >> Note that Classpath has the option to just compile the native code. >> You can then build the Java code on any box (you'll probably find this >> easier on an x86 box for example). Check the --with-glibj option. > > Will do. > > >> As you're on Gentoo, it may be worth checking out the GNU Classpath >> and CACAO ebuilds in the java-overlay (available via layman). We'd >> appreciate the testing on mips! > > I tried the versions in the portage tree initially, but portage has an > unhealthy fixation on x86 (i.e. dependencies and keywords prohibit building > most java stuff on mips). I'll try to get the overlay you mentioned and > massage things a bit. > I don't know anything about the in-tree versions. 0.98 is in the overlay though, and if you can use it successfully, then I can commit the appropriate ~mips or whatever flag to it. > > Thank you very much! > Manuel Lauss > Thanks for testing, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) 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: Problems building classpath on MIPS
2009/3/16 Manuel Lauss : > On Mon, Mar 16, 2009 at 09:13:18AM +, Andrew Haley wrote: >> Manuel Lauss wrote: >> >> > >> > Did I miss any prerequisites? >> > Any help is very much appreciated! >> >> Well, what are you trying to do? GNU Classpath usually has to be >> customized for whatever runtime it's going to be running on. So, >> what runtime will you use? > > Is that documented somewhere? I assume by runtime you mean the VM. > In this case, the target is cacaovm (although I'm flexible here) > > >> Andrew. > > Thanks! > Manuel Lauss > > CACAO is a good choice, it should work just fine with an uncustomised copy of GNU Classpath. It seems that configure is defaulting to using gcj to compile and for some reason, this is failing. From your output, it seems like gcj is trying to compile more than just the Test.java file and is actually trying to compile a lot of the GNU Classpath sourcecode during the configure process! The thing to try first is to build outside the source directory: cd .. mkdir classpath-build cd classpath-build CFLAGS="-O2 -mips32 -msoft-float" ../classpath-0.98/configure --prefix=/opt/classpath --build=mipsel-softfloat-linux-gnu --host=mipsel-softfloat-linux-gnu --target=mipsel-softfloat-linux-gnu --disable-gconf-peer --disable-gtk-peer --disable-plugin --enable-gmp --enable-regen-headers --enable-static --enable-shared --disable-rpath --with-gnu-ld If this works, let us know; it may be that there is a bug with using gcj for in-tree compiles. There was a similar issue for older versions of javac. More generally, the fact that gcj is being used as the compiler implies that it has already failed to find either ecj or javac. You can explicitly set the compiler to use by setting the JAVAC environment variable in the same way you set CFLAGS. Note that Classpath has the option to just compile the native code. You can then build the Java code on any box (you'll probably find this easier on an x86 box for example). Check the --with-glibj option. As you're on Gentoo, it may be worth checking out the GNU Classpath and CACAO ebuilds in the java-overlay (available via layman). We'd appreciate the testing on mips! Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) 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: FOSDEM 2009: First Talk Recording Now Available
2009/2/25 Andrew John Hughes : > You'll find Mark Reinhold's talk on 'The State of OpenJDK7' here: > > http://www.archive.org/details/fosdem_2009_free_java_the_state_of_openjdk_7 > > It's available under the Creative Commons Attribution No-Derivative > license (http://creativecommons.org/licenses/by-nd/2.0/uk/). Please > feel free to distribute copies under those terms. > > Thanks to Mark Reinhold for allowing this to be made available. He > also gave the all clear for the Project Jigsaw talk which will be > available soon. > > For a more retro talk, Andrew Haley's talk given at the University of > Sheffield last year is also available (can't remember if I already > mentioned this or not): > > http://www.archive.org/details/freedom_and_free_java > > This was part of Sun's Campus Ambassador scheme. Again, my thanks to > Andrew for allowing this to be recorded and published. > > If there are any issues with the publication of these talks, please > contact me ASAP. > > More to come in time and with appropriate permissions, > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > 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 > Project Jigsaw: http://www.archive.org/details/fosdem_2009_free_java_project_jigsaw -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) 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
Tools License Review
Hi all, I was looking at the tools code earlier this week, and noticed that the code was licensed under the pure GPL. As such, it seemed plausible that these could be moved up to the GPLv3. The main library code itself can't yet be changed as there is no suitable exception for GPLv3 (equivalent to what we have now) available from the FSF so far, and we would also like to try and remain compatible with the licensing used by OpenJDK. (note: we are already slightly different in that Classpath code can be distributed or modified under the GPLv3 due to the 'or later' clause, whereas OpenJDK can't). However, pure GPL code causes no such problem and so it seemed possible that these files could be changed, just as parts of GCC have already moved from pure GPLv2 to pure GPLv3. However, after discussing this with Mark Wielaard on IRC, it seems these files are mislicensed. I reviewed the code in the tools subdirectory in full and it seems the majority is GPLv2 + Classpath exception like the rest of the library (so it can be used from tools like Ant, etc.). However, the following are all pure GPLv2: tools/gnu/classpath/tools/rmic/ClassRmicCompiler.java tools/gnu/classpath/tools/rmic/RmicBackend.java tools/gnu/classpath/tools/rmic/CompilationError.java tools/gnu/classpath/tools/rmic/Variables.java tools/gnu/classpath/tools/rmic/MethodGenerator.java tools/gnu/classpath/tools/rmic/SourceRmicCompiler.java tools/gnu/classpath/tools/rmic/WrapUnWrapper.java tools/gnu/classpath/tools/rmic/Main.java tools/gnu/classpath/tools/rmic/Generator.java tools/gnu/classpath/tools/rmic/GiopIo.java tools/gnu/classpath/tools/rmic/RmiMethodGenerator.java tools/gnu/classpath/tools/rmic/SourceGiopRmicCompiler.java tools/gnu/classpath/tools/rmic/RMICException.java tools/gnu/classpath/tools/rmic/HashFinder.java tools/gnu/classpath/tools/serialver/SerialVer.java tools/gnu/classpath/tools/gjdoc/DocImpl.java tools/gnu/classpath/tools/gjdoc/expr/ConstantLong.java tools/gnu/classpath/tools/gjdoc/expr/LessThanExpression.java tools/gnu/classpath/tools/gjdoc/expr/ConstantShort.java tools/gnu/classpath/tools/gjdoc/expr/ShiftRightExpression.java tools/gnu/classpath/tools/gjdoc/expr/TypeCastExpression.java tools/gnu/classpath/tools/gjdoc/expr/BinaryShiftExpression.java tools/gnu/classpath/tools/gjdoc/expr/GreaterThanOrEqualExpression.java tools/gnu/classpath/tools/gjdoc/expr/ExclusiveOrExpression.java tools/gnu/classpath/tools/gjdoc/expr/DivisionExpression.java tools/gnu/classpath/tools/gjdoc/expr/BinaryExpression.java tools/gnu/classpath/tools/gjdoc/expr/EqualExpression.java tools/gnu/classpath/tools/gjdoc/expr/BinaryBitwiseExpression.java tools/gnu/classpath/tools/gjdoc/expr/ShiftLeftExpression.java tools/gnu/classpath/tools/gjdoc/expr/ConstantByte.java tools/gnu/classpath/tools/gjdoc/expr/IdentifierExpression.java tools/gnu/classpath/tools/gjdoc/expr/GreaterThanExpression.java tools/gnu/classpath/tools/gjdoc/expr/NegateExpression.java tools/gnu/classpath/tools/gjdoc/expr/AdditionExpression.java tools/gnu/classpath/tools/gjdoc/expr/UnknownIdentifierException.java tools/gnu/classpath/tools/gjdoc/expr/BinaryEqualityExpression.java tools/gnu/classpath/tools/gjdoc/expr/LessThanOrEqualExpression.java tools/gnu/classpath/tools/gjdoc/expr/InclusiveOrExpression.java tools/gnu/classpath/tools/gjdoc/expr/ConstantFloat.java tools/gnu/classpath/tools/gjdoc/expr/UnaryExpression.java tools/gnu/classpath/tools/gjdoc/expr/ConstantDouble.java tools/gnu/classpath/tools/gjdoc/expr/LogicalOrExpression.java tools/gnu/classpath/tools/gjdoc/expr/SubtractionExpression.java tools/gnu/classpath/tools/gjdoc/expr/BitShiftRightExpression.java tools/gnu/classpath/tools/gjdoc/expr/ConstantString.java tools/gnu/classpath/tools/gjdoc/expr/BinaryLogicalExpression.java tools/gnu/classpath/tools/gjdoc/expr/ModuloExpression.java tools/gnu/classpath/tools/gjdoc/expr/Evaluator.java tools/gnu/classpath/tools/gjdoc/expr/ConstantBoolean.java tools/gnu/classpath/tools/gjdoc/expr/ConditionalExpression.java tools/gnu/classpath/tools/gjdoc/expr/ConstantNull.java tools/gnu/classpath/tools/gjdoc/expr/BinaryRelationExpression.java tools/gnu/classpath/tools/gjdoc/expr/BinaryComputationExpression.java tools/gnu/classpath/tools/gjdoc/expr/AndExpression.java tools/gnu/classpath/tools/gjdoc/expr/Expression.java tools/gnu/classpath/tools/gjdoc/expr/NotExpression.java tools/gnu/classpath/tools/gjdoc/expr/EvaluatorEnvironment.java tools/gnu/classpath/tools/gjdoc/expr/IllegalExpressionException.java tools/gnu/classpath/tools/gjdoc/expr/ConstantInteger.java tools/gnu/classpath/tools/gjdoc/expr/LogicalAndExpression.java tools/gnu/classpath/tools/gjdoc/expr/ConstantExpression.java tools/gnu/classpath/tools/gjdoc/expr/NotEqualExpression.java tools/gnu/classpath/tools/gjdoc/expr/Context.java tools/gnu/classpath/tools/gjdoc/expr/LogicalNotExpression.java tools/gnu/classpath/tools/gjdoc/expr/MultiplicationExpression.java tools/gnu/classpath/tools/gjdoc/expr/Type.java tools/gnu/classpath/tools/gjdoc/expr/Circ
FOSDEM 2009: First Talk Recording Now Available
You'll find Mark Reinhold's talk on 'The State of OpenJDK7' here: http://www.archive.org/details/fosdem_2009_free_java_the_state_of_openjdk_7 It's available under the Creative Commons Attribution No-Derivative license (http://creativecommons.org/licenses/by-nd/2.0/uk/). Please feel free to distribute copies under those terms. Thanks to Mark Reinhold for allowing this to be made available. He also gave the all clear for the Project Jigsaw talk which will be available soon. For a more retro talk, Andrew Haley's talk given at the University of Sheffield last year is also available (can't remember if I already mentioned this or not): http://www.archive.org/details/freedom_and_free_java This was part of Sun's Campus Ambassador scheme. Again, my thanks to Andrew for allowing this to be recorded and published. If there are any issues with the publication of these talks, please contact me ASAP. More to come in time and with appropriate permissions, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) 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 Classpath 0.98 "Better Late Than Never" released
Sun and Classpath's java.lang.Appendable - PR35487: gcj causes ConcurrentModificationException during tomcat5 - PR35690: javax.tools.FileObject.toUri is in wrong case - PR36085: java.util.regex escape-sequence handling - PR36147: Apache Tomcat fails to read descriptors using GNU XML - PR36219: gnu.xml.transform.SortKey isn't subclass - PR36220: NPEs in gnu.xml.transform.* clone methods - PR36221: DomDOMException running SPEC jvm 2008 xml.transform - PR36477: OOME in CPStringBuilder when running Eclipse - PR36522: Policy file is not read at all - PR36636: gjar -u doesn't work - PR36637: --without-fastjar doesn't wor - PR36677: Omission bug in JDWP VirtualMachineCommandSet - PR38417: gnu.java.security.util.PRNG produces easily predictable values - PR38473: Segmentation fault in retrieving font outline decomposition - PR38861: Support XULRunner 1.9.1. - PR38912: XMLParser not interning element names Runtime interface changes: * VMSecureRandom has moved to gnu.java.security.jce.prng.VMSecureRandom as part of the fix for PR38417. * gnu.java.lang.VMCPStringBuilder has been added and should be added to avoid the inefficency of reflection when creating non-copied String objects. The following people helped with this release: Chris Burdess, David Daney, David Edelsohn, Daniel Frampton, Michael Franz, Jeroen Frijters, David P Grove, Andrew Haley, Laszlo Andras Hernadi, Andrew John Hughes, Matthias Klose, Byeogncheol Lee, Robert Lougher, Raif S. Naffah, Xavier Poinsard, Ian Rogers, Robert Schuster, Archit Shah, Joshua Sumali, Christian Thalinger, Mario Torre, Tom Tromey, Ralf Wildenhues, Mark Wielaard We would also like to thank the numerous bug reporters and testers! In addition, we'd like to extend our thanks to all those who've contributed over the years and have helped in building a thriving and friendly community around the GNU Classpath project. -- Andrew :-) IcedTea/OpenJDK Software Engineer Red Hat, Inc. (http://www.redhat.com) 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
[commit-cp] classpath ChangeLog NEWS configure.ac
CVSROOT:/sources/classpath Module name:classpath Changes by: Andrew John Hughes 09/02/05 23:26:08 Modified files: . : ChangeLog NEWS configure.ac Log message: Prepare for 0.98 release. 2009-02-05 Andrew John Hughes * NEWS: Updated. * configure.ac: Bump to 0.98 proper. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpath&r1=1.9757&r2=1.9758 http://cvs.savannah.gnu.org/viewcvs/classpath/NEWS?cvsroot=classpath&r1=1.195&r2=1.196 http://cvs.savannah.gnu.org/viewcvs/classpath/configure.ac?cvsroot=classpath&r1=1.242&r2=1.243
[commit-cp] classpath ChangeLog native/plugin/gcjwebplugin.cc
CVSROOT:/sources/classpath Module name:classpath Changes by: Andrew John Hughes 09/02/05 22:54:11 Modified files: . : ChangeLog native/plugin : gcjwebplugin.cc Log message: Handle XULRunner 1.9.1. 2009-02-05 Andrew Haley PR libgcj/38861 * native/plugin/gcjwebplugin.cc: Cope with the changed header file format. https://bugzilla.mozilla.org/show_bug.cgi?id=455458 (GCJ_GetJavaClass): Likewise. (NP_Initialize): Likewise. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpath&r1=1.9756&r2=1.9757 http://cvs.savannah.gnu.org/viewcvs/classpath/native/plugin/gcjwebplugin.cc?cvsroot=classpath&r1=1.13&r2=1.14
[commit-cp] classpath ChangeLog gnu/xml/stream/XMLParser.java
CVSROOT:/sources/classpath Module name:classpath Changes by: Andrew John Hughes 09/02/05 20:46:23 Modified files: . : ChangeLog gnu/xml/stream : XMLParser.java Log message: 2009-02-05 Mark Wielaard PR classpath/38912: * gnu/xml/stream/XMLParser.java: (getLocalName()): Respect stringInterning. (getName()): Likewise. (getPrefix()): Likewise. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpath&r1=1.9755&r2=1.9756 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/xml/stream/XMLParser.java?cvsroot=classpath&r1=1.35&r2=1.36
FOSDEM: Talk Recordings
Hi all, I'll be bringing along my video camera again, all things permitting. Previous recordings can be seen on http://fuseyism.com/ Unfortunately, things so far haven't gone as I'd like. I've been unable to get hold of more tapes for recording talks, so I'll be bringing my laptop with firewire along and hoping a combination of four tapes and a hard disc will get me through... Help would be appreciated, even if it's just making sure I have some power and an unblocked view of the speaker :D It would be nice to get these online ASAP, so if you have some spare cycles during FOSDEM and want to encode one of the movies, please let me know. The originals are in DV format and I encode to three sizes of Ogg Theora (a nice little script I have will do this for you, provided you have ffmpeg2theora on your box and optionally mplayer/speex for an audio track -- see attachment). If you particularly want your talk recorded, please let me know. Alternatively, if for some reason you'd rather not have it recorded, let me know as well. Thanks, and see you all at FOSDEM, -- Andrew :-) IcedTea/OpenJDK Software Engineer Red Hat, Inc. (http://www.redhat.com) 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 encode Description: Binary data
Re: ./configure javah
2009/2/4 Daniel Patrick : > Hi All, > > I have facing some problems when I try to execute the ./configure command. > See below the messages > > 1) ./configure --with-jikes --with-javah=./tools/com/sun/tools/javah > --enable-jni > gmodule-2.0 -ldl -lglib-2.0 > checking for ./tools/com/sun/tools/javah... no > configure: error: can not find javah > > 2) ./configure --with-jikes --enable-jni > checking for javah... no > configure: error: can not find javah > > The 0.97.1 and 0.97 versions have the same symptoms. > > What is the exactly path that I must specify? > > Thanks all > > My regards, > > Daniel Patrick > > Is javah a binary? If not, that's why this is failing. Jikes has not been supported since 0.95. You need a 1.5 compiler such as ecj or the Free version of javac. -- Andrew :-) IcedTea/OpenJDK Software Engineer Red Hat, Inc. (http://www.redhat.com) 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
[commit-cp] classpath ChangeLog native/jni/native-lib/cpproc.c
CVSROOT:/sources/classpath Module name:classpath Changes by: Andrew John Hughes 09/02/04 14:17:19 Modified files: . : ChangeLog native/jni/native-lib: cpproc.c Log message: Revert the return on chdir == -1. 2009-02-04 Andrew John Hughes * native/jni/native-lib/cpproc.c: (cpproc_forkAndExec): Don't return on a -1 result from chdir as this may be valid in some cases. A better fix is needed. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpath&r1=1.9754&r2=1.9755 http://cvs.savannah.gnu.org/viewcvs/classpath/native/jni/native-lib/cpproc.c?cvsroot=classpath&r1=1.5&r2=1.6
Re: 0.98 Release Imminent
2009/2/4 Andrew Haley : > Andrew John Hughes wrote: >> 2009/2/4 Andrew Haley : >>> Andrew John Hughes wrote: >>>> I plan to release 0.98 on Thursday before FOSDEM, now that the >>>> security issue has been patched: >>>> >>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38417 >>>> >>>> If there are any major bugs that mean a release should not go ahead, >>>> please let me know ASAP. >>> I have found a deadlock in gcj in AWT even processing. I don't know >>> if it affects all of Classpath, but I think so. >> >> Do you have any more details? I'll see if I can replicate it here. > > Found it, and it's already fixed in Classpath. It's this: > > http://article.gmane.org/gmane.comp.java.classpath.patches/12149 > > Despite the fact that this patch was written in mid-2007 it is still not > in the gcc 4.3 branch. Unfortunately, gcc 4.3.3 was released last > Sunday. :-( > > It looks like the last Classpath import for gcc 4.3 was this: > > 2007-08-04 Matthias Klose > >Import GNU Classpath (libgcj-import-20070727). > > which means that this change of 2007-08-23 missed gcc 4.3, even though > 4.3 wasn't released until 2008-03-05. > > Thus, every gcj ever released has this evil deadlock, even that in > Fedora 10. > > Andrew. > Ouch... we really should be doing better at keeping these in sync. This is partly why I want to get another Classpath release sorted. At the moment, GCJ and Classpath are pretty much in sync (I'll merge across Mario's patch and any remaining fixes against the 0.98 tag once made). This should mean 4.4 ~= 0.98 and we can then port across any appropriate bug/security fixes that occur more easily. We shouldn't just stop merging code from Classpath once a gcc is frozen (though obviously we shouldn't merge new features to such a branch either). -- Andrew :-) IcedTea/OpenJDK Software Engineer Red Hat, Inc. (http://www.redhat.com) 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
[commit-cp] classpath ChangeLog native/jni/native-lib/cpproc.c
CVSROOT:/sources/classpath Module name:classpath Changes by: Andrew John Hughes 09/02/04 12:09:55 Modified files: . : ChangeLog native/jni/native-lib: cpproc.c Log message: Fix build errors on gcc 4.3.3 with -Werror. 2009-02-03 Andrew John Hughes * native/jni/native-lib/cpproc.c: (cpproc_forkAndExec): Handle return of chdir. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpath&r1=1.9753&r2=1.9754 http://cvs.savannah.gnu.org/viewcvs/classpath/native/jni/native-lib/cpproc.c?cvsroot=classpath&r1=1.4&r2=1.5
Re: 0.98 Release Imminent
2009/2/4 Andrew Haley : > Andrew John Hughes wrote: >> I plan to release 0.98 on Thursday before FOSDEM, now that the >> security issue has been patched: >> >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38417 >> >> If there are any major bugs that mean a release should not go ahead, >> please let me know ASAP. > > I have found a deadlock in gcj in AWT even processing. I don't know > if it affects all of Classpath, but I think so. > > Andrew. > Do you have any more details? I'll see if I can replicate it here. Thanks, -- Andrew :-) IcedTea/OpenJDK Software Engineer Red Hat, Inc. (http://www.redhat.com) 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
0.98 Release Imminent
I plan to release 0.98 on Thursday before FOSDEM, now that the security issue has been patched: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38417 If there are any major bugs that mean a release should not go ahead, please let me know ASAP. The tree has already undergone regression testing so no new changes should be committed between now and the release. Given the low traffic of the tree at the moment, I don't plan to take a release branch, so please consider the main tree frozen until after the release. Thanks, -- Andrew :-) IcedTea/OpenJDK Software Engineer Red Hat, Inc. (http://www.redhat.com) 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
[commit-cp] classpath ChangeLog Makefile.am
CVSROOT:/sources/classpath Module name:classpath Changes by: Andrew John Hughes 09/01/06 01:01:04 Modified files: . : ChangeLog Makefile.am Log message: Distribute ChangeLog-2008. 2009-01-05 Andrew John Hughes * Makefile.am: Add ChangeLog-2008 to EXTRA_DIST. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpath&r1=1.9748&r2=1.9749 http://cvs.savannah.gnu.org/viewcvs/classpath/Makefile.am?cvsroot=classpath&r1=1.50&r2=1.51
Re: gcjwebplugin in Classpath
2008/12/23 Andrew Haley : > Andrew John Hughes wrote: >> Dear all, >> >> What shall we do with the copy of gcjwebplugin that still remains in >> GNU Classpath? Given that development has since shifted to IcedTea, >> and then been abandoned altogether in favour of the new IcedTeaPlugin, >> I don't see any advantage in maintaining this in GNU Classpath. I do >> see a disadvantage in that we know it has significant security issues >> and bugs. My preference would be to remove it before releasing 0.98. >> If we still want to ship a plugin with Classpath, we could possibly >> include IcedTeaPlugin. >> >> Thoughts? > > a. Would it work? > b. Do we have copyright assignment for all of it? > > Andrew. > > I've just tried to compile IcedTeaPlugin's Java code using Classpath and this fails due to dependencies on Sun's X11 code. We'd need to change that should we want to include it. As to copyright, part of the plugin is clearly marked as copyrighted to Red Hat and thus falls under the blanket assignment. Some of the other files have no copyright header (AppletSecurityContextManager,PluginCallRequestFactory, PluginClassLoader, PluginDebug, PluginException, PluginMessageConsumer, PluginMessageHandlerWorker, PluginStreamHandler, RequestQueue) and one is copyrighted to Sun (PluginAppletViewer). I also noted a lot of warnings from ecj - some of the Java code is very messy :) There are probably other issues, that was just the obvious failure. I guess the issue of a missing security manager would still remain, and that's still my main reason for suggesting we drop the plugin from GNU Classpath. I suppose that was my main question and IcedTeaPlugin was an afterthought; do we want to continue support something with known security issues and bugs? -- 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
gcjwebplugin in Classpath
Dear all, What shall we do with the copy of gcjwebplugin that still remains in GNU Classpath? Given that development has since shifted to IcedTea, and then been abandoned altogether in favour of the new IcedTeaPlugin, I don't see any advantage in maintaining this in GNU Classpath. I do see a disadvantage in that we know it has significant security issues and bugs. My preference would be to remove it before releasing 0.98. If we still want to ship a plugin with Classpath, we could possibly include IcedTeaPlugin. Thoughts? -- 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: [GCJ] Performance of GUI applications on embedded systems
2008/11/8 Andrew Haley <[EMAIL PROTECTED]>:
> Andrew Haley wrote:
>
>>
>>
>> Index: gnu_java_awt_peer_gtk_CairoGraphics2D.c
>> ===
>> --- gnu_java_awt_peer_gtk_CairoGraphics2D.c (revision 141575)
>> +++ gnu_java_awt_peer_gtk_CairoGraphics2D.c (working copy)
>> @@ -351,7 +351,6 @@
>>for (i = 0; i < n; i++)
>> {
>>PangoFcFont *font = JLONG_TO_PTR(PangoFcFont, fonts[i]);
>> - gdk_threads_leave ();
>>
>>/* Draw as many glyphs as possible with the current font */
>>int length = 0;
>
> Incidentally, this bug was introduced on 2007-06-04, so this patch
> needs applying to a bunch of systems and gcc branches. It affects
> Fedora systems and (presumably) recent Debians.
>
> Andrew.
>
So is the bug GCJ only? I got the impression we were also seeing this
on 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
Re: GCJ Mauve testing
2008/10/18 Matthias Klose <[EMAIL PROTECTED]>: > Andrew John Hughes schrieb: >> I've just run Mauve against both the 4.3 tree and our >> Classpath 0.98 merge tree (effectively equivalent to Classpath >> CVS + GCJ-specific changes). Overall: >> >> 4.3: >> 281 of 3177 tests failed. 123926 total calls to harness.check() failed. >> >> 4.4: >> 239 of 3177 tests failed. 143832 total calls to harness.check() failed. >> >> There will be some new tests that compile with 4.4 but not 4.3 (e.g. >> java.util.Scanner tests). > > Here is another run, done with trunk and branch 20081017. > Thanks for this. > 4.3: > 277 of 3175 tests failed. 139350 total calls to harness.check() failed. > > trunk: > 232 of 3175 tests failed. 122871 total calls to harness.check() failed. > > merge branch (as 4.4 above): > 229 of 3175 tests failed. 122914 total calls to harness.check() failed. > >> Additional FAILs are as follows: >> >> +FAIL: gnu.java.security.util.TestOfIntegerUtil >> +FAIL: java.sql.Date.DateTest >> +FAIL: java.lang.Character.Blocks15 >> +FAIL: java.lang.InheritableThreadLocal.simple >> +FAIL: java.text.SimpleDateFormat.parse >> +FAIL: java.util.Calendar.ampm >> +FAIL: java.util.Scanner.LotsOfPMInts >> +FAIL: java.util.Scanner.Inputs >> +FAIL: javax.swing.text.DefaultStyledDocument.ElementBuffer.insert >> +FAIL: >> javax.swing.table.JTableHeader.AccessibleJTableHeader.AccessibleJTableHeaderEntry.getForeground > > comparing 4.3 with the merge branch: > > 56 progressions and > > +FAIL: java.awt.TextField.PaintTest > +FAIL: java.lang.ref.PhantomReference.phantom > +FAIL: java.text.SimpleDateFormat.parse > +FAIL: java.util.Calendar.ampm > +FAIL: java.util.Scanner.FindWithinHorizon > +FAIL: java.util.logging.Logger.getParent > +FAIL: javax.swing.JButton.constructors > +FAIL: javax.swing.text.DefaultStyledDocument.ElementBuffer.insert > > The following three go away if the cacerts file is in place. > > +FAIL: gnu.java.security.jce.TestOfHttps > +FAIL: gnu.java.security.util.TestOfIntegerUtil > +FAIL: java.net.URLConnection.getHeaderFields > > comparing the trunk with the merge branch (0.97.2 vs. 0.98pre): > > 9 progressions and > > +FAIL: gnu.java.security.util.TestOfIntegerUtil > +FAIL: java.awt.Component.clickModifiers > +FAIL: java.text.SimpleDateFormat.Localization > +FAIL: java.util.Calendar.ampm > +FAIL: java.util.Currency.US > +FAIL: java.util.Scanner.FindWithinHorizon > +FAIL: java.util.logging.Logger.getParent > > Full logs at http://people.ubuntu.com/~doko/java/mauve-results/ > > libjava/testsuite/libjava.mauve doesn't work with current mauve, so all > builds were installed, and > mauve was run on the installed build. > > Matthias > > The Scanner tests can be written off, as they won't have compiled with either 4.3 or trunk (neither have java.util.Scanner). The merge branch seems to be an improvement, but there are clearly some new localisation issues. What is the plan for merging to trunk? -- 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: GCJ Mauve testing
2008/10/7 Andrew Haley <[EMAIL PROTECTED]>: > Andrew John Hughes wrote: >> 2008/10/6 Andrew Haley <[EMAIL PROTECTED]>: >>> Andrew John Hughes wrote: >>> >>>> FAIL: java.lang.InheritableThreadLocal.simple >>>> Test timed out. Use -timeout [millis] option to change the timeout >>>> value. >>> This is strange, given that gcj has its own InheritableThreadLocal that >>> hasn't changed. I'll look. >>> >>> Andrew. >>> >> >> I did another Mauve run against the merge branch and gained some passes, >> but also some new failures: >> >> +PASS: gnu.java.security.util.TestOfIntegerUtil >> +PASS: java.awt.event.MouseEvent.modifiersEx >> +PASS: java.awt.event.MouseEvent.modifiers >> +PASS: java.util.logging.Logger.global >> +PASS: javax.swing.plaf.metal.MetalScrollBarUI.constructor >> +PASS: javax.swing.plaf.metal.MetalScrollBarUI.installDefaults >> +FAIL: java.util.logging.Logger.hierarchyChecks >> +FAIL: java.util.logging.Logger.securityChecks >> +FAIL: java.util.logging.SocketHandler.getFormatter >> +FAIL: java.util.Scanner.DoubleFloat >> +FAIL: java.util.Scanner.FishString >> +FAIL: java.util.Scanner.Radix >> +FAIL: javax.sound.sampled.AudioProperties >> +FAIL: javax.swing.JTable.TableRobot >> >> Odd to say the least. > > Curious. It's not immediately obvious how the change could have affected > those, but I'll have a look. > > Andrew. > > I think some of them may be spurious. gnu.java.security.util.TestOfIntegerUtil particularly is based on timing. I'll post the test log shortly. -- 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: GCJ Mauve testing
2008/10/6 Andrew Haley <[EMAIL PROTECTED]>: > Andrew John Hughes wrote: > >> FAIL: java.lang.InheritableThreadLocal.simple >> Test timed out. Use -timeout [millis] option to change the timeout value. > > This is strange, given that gcj has its own InheritableThreadLocal that > hasn't changed. I'll look. > > Andrew. > I did another Mauve run against the merge branch and gained some passes, but also some new failures: +PASS: gnu.java.security.util.TestOfIntegerUtil +PASS: java.awt.event.MouseEvent.modifiersEx +PASS: java.awt.event.MouseEvent.modifiers +PASS: java.util.logging.Logger.global +PASS: javax.swing.plaf.metal.MetalScrollBarUI.constructor +PASS: javax.swing.plaf.metal.MetalScrollBarUI.installDefaults +FAIL: java.util.logging.Logger.hierarchyChecks +FAIL: java.util.logging.Logger.securityChecks +FAIL: java.util.logging.SocketHandler.getFormatter +FAIL: java.util.Scanner.DoubleFloat +FAIL: java.util.Scanner.FishString +FAIL: java.util.Scanner.Radix +FAIL: javax.sound.sampled.AudioProperties +FAIL: javax.swing.JTable.TableRobot Odd to say the least. -- 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: org.w3c.dom.html2 package
2008/10/4 Robert Schuster <[EMAIL PROTECTED]>: > Hi, > all the classes of the package "org.w3c.dom.html2" in GNU Classpath are > living in "org.w3c.dom.html" in OpenJDK. > > Now this is an odd thing and I wonder why this has never caused any > troubles before. I can't compile xerces-j from source with that. > > If nobody objects I would like to move all classes to the right package. > > Regards > Robert > > Aren't these in external? So presumably this is what upstream does... -- 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: Disabled wiki editing
2008/10/2 Mark Wielaard <[EMAIL PROTECTED]>: > Hi Andrew, > > On Wed, 2008-10-01 at 21:35 +0100, Andrew John Hughes wrote: >> I'd appreciate being on the admin list, as I have used the wiki in the >> past for releases and other stuff and probably will again. > > You should be now. > Thanks. >> On the subject of Classpath infrastructure, what is the chance of us >> getting some more space on builder.classpath.org to do IcedTea builds? >> Or is there somewhere else we can do this? > > There is enough disk space on icedtea.classpath.org (the main problem is > memory though, the build uses a lot, especially during the javadoc pass, > so you will have to disable that with --disable-docs). > I have already setup something there, but... > The reason I ask is because I now have a build script that's worked for me in a few places on different systems. I could probably adapt that to icedtea.classpath.org pretty easily. It does include --disable-docs :) Ideally, it'd be great to have some other archs for the cacao/shark stuff. >> With a couple of backported packages (freetype and zlib) this is >> possible on etch, as I proved again today. > > That would be interesting to have/see. The current thing on > icedtea.classpath.org is using a chrooted sid setup which is certainly > awkward to use, so if we could with a simple backport use Etch/debian > stable that would be great. > My freetype deb was online but it looks like I accidentally dropped it when setting up a repository for the powerpc stuff :( If you can backport freetype on there, I can do the rest. > Cheers, > > Mark > > -- 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: Disabled wiki editing
2008/9/30 Mark Wielaard <[EMAIL PROTECTED]>:
> Hi,
>
> As people who have been watching the RecentChanges page have noticed
> already our wiki is attracting a lot of spammers:
> http://developer.classpath.org/mediation/RecentChanges
> Even after removing the spam accounts and making it harder to register
> they still keep coming :{ So for now I have disabled editing of the
> pages except for admins. If you want to edit one of the pages please
> ping me and I add you to the admin list.
>
> Cheers,
>
> Mark
>
>
>
Hi Mark,
I'd appreciate being on the admin list, as I have used the wiki in the
past for releases and other
stuff and probably will again.
On the subject of Classpath infrastructure, what is the chance of us
getting some more space
on builder.classpath.org to do IcedTea builds? Or is there somewhere
else we can do this?
With a couple of backported packages (freetype and zlib) this is
possible on etch, as I proved
again today.
Cheers,
--
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: GCJ Mauve testing
2008/9/27 Andrew John Hughes <[EMAIL PROTECTED]>: > I've just run Mauve against both the 4.3 tree and our > Classpath 0.98 merge tree (effectively equivalent to Classpath > CVS + GCJ-specific changes). Overall: > > 4.3: > 281 of 3177 tests failed. 123926 total calls to harness.check() failed. > > 4.4: > 239 of 3177 tests failed. 143832 total calls to harness.check() failed. > > There will be some new tests that compile with 4.4 but not 4.3 (e.g. > java.util.Scanner tests). > > Additional FAILs are as follows: > > +FAIL: gnu.java.security.util.TestOfIntegerUtil > +FAIL: java.sql.Date.DateTest > +FAIL: java.lang.Character.Blocks15 > +FAIL: java.lang.InheritableThreadLocal.simple > +FAIL: java.text.SimpleDateFormat.parse > +FAIL: java.util.Calendar.ampm > +FAIL: java.util.Scanner.LotsOfPMInts > +FAIL: java.util.Scanner.Inputs > +FAIL: javax.swing.text.DefaultStyledDocument.ElementBuffer.insert > +FAIL: > javax.swing.table.JTableHeader.AccessibleJTableHeader.AccessibleJTableHeaderEntry.getForeground > > The two Scanner tests we can discount as regressions as they simply won't > have run with 4.3. > > The remaining failures: > > FAIL: gnu.java.security.util.TestOfIntegerUtil > line 71: IntegerUtil.valueOf(String) MUST be faster than > Integer.valueOf(String) [1] -- boolean passed to check was fa\ > lse > FAIL: java.sql.Date.DateTest > uncaught exception: > java.lang.OutOfMemoryError > FAIL: java.lang.Character.Blocks15 > uncaught exception: > java.lang.OutOfMemoryError > FAIL: java.lang.InheritableThreadLocal.simple > Test timed out. Use -timeout [millis] option to change the timeout value. > FAIL: java.text.SimpleDateFormat.parse > line 132: parse pattern -MM-dd HH:mm z [3] -- Objects were not equal. > Use -debug for more information. > line 132: parse pattern -MM-dd HH:mm Z [3] -- Objects were not equal. > Use -debug for more information. > FAIL: java.util.Calendar.ampm > line 72: 12:00 AM couldn't be parsed [1] -- forced fail > line 72: 12:10 AM couldn't be parsed [1] -- forced fail > line 57: 12:10 AM couldn't be parsed [2] -- Objects were not equal. Use > -debug for more information. > line 72: 0:00 AM couldn't be parsed [1] -- forced fail > line 57: 0:00 AM couldn't be parsed [2] -- Objects were not equal. Use > -debug for more information. > line 72: 0:10 AM couldn't be parsed [1] -- forced fail > line 72: 12:00 PM couldn't be parsed [1] -- forced fail > line 72: 12:10 PM couldn't be parsed [1] -- forced fail > line 57: 12:10 PM couldn't be parsed [2] -- Objects were not equal. Use > -debug for more information. > line 72: 0:00 PM couldn't be parsed [1] -- forced fail > line 57: 0:00 PM couldn't be parsed [2] -- Objects were not equal. Use > -debug for more information. > line 72: 0:10 PM couldn't be parsed [1] -- forced fail > FAIL: javax.swing.text.DefaultStyledDocument.ElementBuffer.insert > line 746: EmptyStackException must be thrown [1] -- forced fail > line 759: EmptyStackException must be thrown [3] -- got 4 but expected 3 > line 765: EmptyStackException must be thrown [7] -- got 7 but expected 15 > line 767: EmptyStackException must be thrown [8] -- got 12 but expected 15 > line 768: EmptyStackException must be thrown [9] -- got 15 but expected 16 > line 771: EmptyStackException must be thrown [10] -- got > javax.swing.text.AbstractDocument$DefaultDocumentEvent but ex\ > pected null > FAIL: > javax.swing.table.JTableHeader.AccessibleJTableHeader.AccessibleJTableHeaderEntry.getForeground > line 54: [2] -- got javax.swing.plaf.ColorUIResource but expected > java.awt.Color > > The first is odd, and CACAO+Classpath CVS fails this also. OpenJDK can't > compile it. CACAO + Classpath CVS > also fails with java.text.SimpleDateFormat.parse, java.util.Calendar.ampm and > javax.swing.text.DefaultStyledDocument.ElementBuffer.insert, which suggest a > common Classpath issue. > java.sql.Date.DateTest, java.lang.Character.Blocks15, > java.lang.InheritableThreadLocal.simple and > javax.swing.table.JTableHeader.AccessibleJTableHeader.AccessibleJTableHeaderEntry.getForeground > are > all GCJ-specific failures. OpenJDK passes all but the first, which is GNU > Classpath specific. > > Full logs are available at: > > http://fuseyism.com/classpath/mauve-gcj-4.3.log > http://fuseyism.com/classpath/mauve-gcj-4.4.log > -- > 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 > Changed to: http://fuseyism.com/classpath/mauve-gcj-4.3.log.gz http://fuseyism.com/classpath/mauve-gcj-4.4.log.gz due to size... -- 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
GCJ Mauve testing
I've just run Mauve against both the 4.3 tree and our Classpath 0.98 merge tree (effectively equivalent to Classpath CVS + GCJ-specific changes). Overall: 4.3: 281 of 3177 tests failed. 123926 total calls to harness.check() failed. 4.4: 239 of 3177 tests failed. 143832 total calls to harness.check() failed. There will be some new tests that compile with 4.4 but not 4.3 (e.g. java.util.Scanner tests). Additional FAILs are as follows: +FAIL: gnu.java.security.util.TestOfIntegerUtil +FAIL: java.sql.Date.DateTest +FAIL: java.lang.Character.Blocks15 +FAIL: java.lang.InheritableThreadLocal.simple +FAIL: java.text.SimpleDateFormat.parse +FAIL: java.util.Calendar.ampm +FAIL: java.util.Scanner.LotsOfPMInts +FAIL: java.util.Scanner.Inputs +FAIL: javax.swing.text.DefaultStyledDocument.ElementBuffer.insert +FAIL: javax.swing.table.JTableHeader.AccessibleJTableHeader.AccessibleJTableHeaderEntry.getForeground The two Scanner tests we can discount as regressions as they simply won't have run with 4.3. The remaining failures: FAIL: gnu.java.security.util.TestOfIntegerUtil line 71: IntegerUtil.valueOf(String) MUST be faster than Integer.valueOf(String) [1] -- boolean passed to check was fa\ lse FAIL: java.sql.Date.DateTest uncaught exception: java.lang.OutOfMemoryError FAIL: java.lang.Character.Blocks15 uncaught exception: java.lang.OutOfMemoryError FAIL: java.lang.InheritableThreadLocal.simple Test timed out. Use -timeout [millis] option to change the timeout value. FAIL: java.text.SimpleDateFormat.parse line 132: parse pattern -MM-dd HH:mm z [3] -- Objects were not equal. Use -debug for more information. line 132: parse pattern -MM-dd HH:mm Z [3] -- Objects were not equal. Use -debug for more information. FAIL: java.util.Calendar.ampm line 72: 12:00 AM couldn't be parsed [1] -- forced fail line 72: 12:10 AM couldn't be parsed [1] -- forced fail line 57: 12:10 AM couldn't be parsed [2] -- Objects were not equal. Use -debug for more information. line 72: 0:00 AM couldn't be parsed [1] -- forced fail line 57: 0:00 AM couldn't be parsed [2] -- Objects were not equal. Use -debug for more information. line 72: 0:10 AM couldn't be parsed [1] -- forced fail line 72: 12:00 PM couldn't be parsed [1] -- forced fail line 72: 12:10 PM couldn't be parsed [1] -- forced fail line 57: 12:10 PM couldn't be parsed [2] -- Objects were not equal. Use -debug for more information. line 72: 0:00 PM couldn't be parsed [1] -- forced fail line 57: 0:00 PM couldn't be parsed [2] -- Objects were not equal. Use -debug for more information. line 72: 0:10 PM couldn't be parsed [1] -- forced fail FAIL: javax.swing.text.DefaultStyledDocument.ElementBuffer.insert line 746: EmptyStackException must be thrown [1] -- forced fail line 759: EmptyStackException must be thrown [3] -- got 4 but expected 3 line 765: EmptyStackException must be thrown [7] -- got 7 but expected 15 line 767: EmptyStackException must be thrown [8] -- got 12 but expected 15 line 768: EmptyStackException must be thrown [9] -- got 15 but expected 16 line 771: EmptyStackException must be thrown [10] -- got javax.swing.text.AbstractDocument$DefaultDocumentEvent but ex\ pected null FAIL: javax.swing.table.JTableHeader.AccessibleJTableHeader.AccessibleJTableHeaderEntry.getForeground line 54: [2] -- got javax.swing.plaf.ColorUIResource but expected java.awt.Color The first is odd, and CACAO+Classpath CVS fails this also. OpenJDK can't compile it. CACAO + Classpath CVS also fails with java.text.SimpleDateFormat.parse, java.util.Calendar.ampm and javax.swing.text.DefaultStyledDocument.ElementBuffer.insert, which suggest a common Classpath issue. java.sql.Date.DateTest, java.lang.Character.Blocks15, java.lang.InheritableThreadLocal.simple and javax.swing.table.JTableHeader.AccessibleJTableHeader.AccessibleJTableHeaderEntry.getForeground are all GCJ-specific failures. OpenJDK passes all but the first, which is GNU Classpath specific. Full logs are available at: http://fuseyism.com/classpath/mauve-gcj-4.3.log http://fuseyism.com/classpath/mauve-gcj-4.4.log -- 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: Problem from Installation GNU Classpath 0.97.2
2008/9/26 ZNTU <[EMAIL PROTECTED]>: > > ecj in my computer is ecj-bootstrap version 3.1.2-2ubuntu4 > > Currently i remove ecj-bootstrap from my computer and using jikes instead > and i successfully installed a classpath > > ./configure --disable-gtk-peer --disable-gconf-peer --disable-plugin > --with-jikes --enable-jni > > then here is the following result > ... > checking for ecj... no > checking for ecj-3.3... no > checking for ecj-3.2... no > checking for javac... javac -Xlint:unchecked > checking if javac -Xlint:unchecked works... yes > checking whether javac supports -J... yes > ... > > > > gnu_andrew wrote: >> >> On 12:55 Thu 25 Sep , Mark Wielaard wrote: >>> Hi ZNTU, >>> >>> On Tue, 2008-09-23 at 00:13 -0700, ZNTU wrote: >>> > I'm just starting to learn about jvm and classpath. I try to install >>> > classpath 0.97.2 on my pc which has i686 and Linux(Kubuntu). However, >>> once I >>> > run >>> > >>> > ./configure --disable-gtk-peer --disable-gconf-peer --disable-plugin >>> > >>> > I notice that there is some incorrect classpath: >>> > ... >>> > checking for ecj... ecj -warn:-deprecation,serial,unusedImport >>> > checking if ecj -warn:-deprecation,serial,unusedImport works... yes >>> > checking whether javac supports -J... incorrect classpath: >>> > yes >>> > >>> > >>> > However once this command finish then i run command "make" >>> > >>> > and there is 1 error and 1 warning that I cannot fix it >>> > >>> > Making all in lib >>> > make[1]: Entering directory `/home/tktan/classpath-0.97.2/lib' >>> > true >>> > top_builddir=.. top_srcdir=.. /bin/sh ./gen-classlist.sh standard >>> > Adding java source files from srcdir '..'. >>> > Adding java source files from VM directory ../vm/reference >>> > ecj -warn:-deprecation,serial,unusedImport -J-Xmx768M -source 1.5 >>> -target >>> > 1.5 -bootclasspath '' -classpath >>> > >>> ../vm/reference:..:../external/w3c_dom:../external/sax:../external/relaxngDatatype:../external/jsr166:.:: >>> > -d . @classes >>> > incorrect classpath: >>> > -- >>> > 1. ERROR in ../sun/reflect/annotation/AnnotationInvocationHandler.java >>> > (at line 87) >>> > memberValues.put(name, m.getDefaultValue()); >>> > ^^^ >>> > The method getDefaultValue() is undefined for the type Method >>> > -- >>> > 2. WARNING in >>> ../sun/reflect/annotation/AnnotationInvocationHandler.java >>> > (at line 373) >>> > throw new IncompleteAnnotationException(type, methodName); >>> > >>> > Type safety: The expression of type Class needs unchecked conversion to >>> > conform to Class >>> > -- >>> > 2 problems (1 error, 1 warning)make[1]: *** [compile-classes] Error 255 >>> > make[1]: Leaving directory `/home/tktan/classpath-0.97.2/lib' >>> > make: *** [all-recursive] Error 1 >>> > >>> > can anyone please help me solve this problem? Any hints are greatly >>> > appreciated. >>> >>> That is strange. It is as if ecj is still compiling against a core class >>> library that has a java.lang.reflect.Method which doesn't have the 1.5 >>> getDefaultValue() method. Which shouldn't be possible since both >>> -bootclasspath and -classpath are given and make sure the Method.java >>> from the code you are compiling is being used. >>> >>> What version of ecj is this? >>> >>> Cheers, >>> >>> Mark >>> >>> >> >> This also reads very strangely to me as well. >> What is ecj in this case? Is it a script or a native >> binary? If it is the former, what's the content of the script? >> >> One guess would be that it is swallowing the first part of the >> classpath ../vm/reference which is where the Method class is in 0.97.2. >> A similar issue was noticed with the IcedTea build. The 'incorrect >> classpath' adds weight to 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 >> >> > > -- > View this message in context: > http://www.nabble.com/Problem-from-Installation-GNU-Classpath-0.97.2-tp19622463p19681733.html > Sent from the Gnu - Classpath - General mailing list archive at Nabble.com. > > > This isn't using jikes; that wouldn't work with Classpath 0.97.2. It's using javac instead. --with-jikes is not an option in Classpath 0.97.2. Instead, checks are made for ecj, javac and gcj in that order. This can be overridden by setting the JAVAC environment variable. -- 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: Problem from Installation GNU Classpath 0.97.2
On 12:55 Thu 25 Sep , Mark Wielaard wrote: > Hi ZNTU, > > On Tue, 2008-09-23 at 00:13 -0700, ZNTU wrote: > > I'm just starting to learn about jvm and classpath. I try to install > > classpath 0.97.2 on my pc which has i686 and Linux(Kubuntu). However, once I > > run > > > > ./configure --disable-gtk-peer --disable-gconf-peer --disable-plugin > > > > I notice that there is some incorrect classpath: > > ... > > checking for ecj... ecj -warn:-deprecation,serial,unusedImport > > checking if ecj -warn:-deprecation,serial,unusedImport works... yes > > checking whether javac supports -J... incorrect classpath: > > yes > > > > > > However once this command finish then i run command "make" > > > > and there is 1 error and 1 warning that I cannot fix it > > > > Making all in lib > > make[1]: Entering directory `/home/tktan/classpath-0.97.2/lib' > > true > > top_builddir=.. top_srcdir=.. /bin/sh ./gen-classlist.sh standard > > Adding java source files from srcdir '..'. > > Adding java source files from VM directory ../vm/reference > > ecj -warn:-deprecation,serial,unusedImport -J-Xmx768M -source 1.5 -target > > 1.5 -bootclasspath '' -classpath > > ../vm/reference:..:../external/w3c_dom:../external/sax:../external/relaxngDatatype:../external/jsr166:.:: > > -d . @classes > > incorrect classpath: > > -- > > 1. ERROR in ../sun/reflect/annotation/AnnotationInvocationHandler.java > > (at line 87) > > memberValues.put(name, m.getDefaultValue()); > > ^^^ > > The method getDefaultValue() is undefined for the type Method > > -- > > 2. WARNING in ../sun/reflect/annotation/AnnotationInvocationHandler.java > > (at line 373) > > throw new IncompleteAnnotationException(type, methodName); > > > > Type safety: The expression of type Class needs unchecked conversion to > > conform to Class > > -- > > 2 problems (1 error, 1 warning)make[1]: *** [compile-classes] Error 255 > > make[1]: Leaving directory `/home/tktan/classpath-0.97.2/lib' > > make: *** [all-recursive] Error 1 > > > > can anyone please help me solve this problem? Any hints are greatly > > appreciated. > > That is strange. It is as if ecj is still compiling against a core class > library that has a java.lang.reflect.Method which doesn't have the 1.5 > getDefaultValue() method. Which shouldn't be possible since both > -bootclasspath and -classpath are given and make sure the Method.java > from the code you are compiling is being used. > > What version of ecj is this? > > Cheers, > > Mark > > This also reads very strangely to me as well. What is ecj in this case? Is it a script or a native binary? If it is the former, what's the content of the script? One guess would be that it is swallowing the first part of the classpath ../vm/reference which is where the Method class is in 0.97.2. A similar issue was noticed with the IcedTea build. The 'incorrect classpath' adds weight to 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: Gradual progress with classpath
On 13/08/2008, Greene, Geoffrey N <[EMAIL PROTECTED]> wrote: > > Getting closer with classpath. I did notice several places where > __attribute was used instead of __attribute__. > > Don't know if anyone cares, but these should probably be fixed for the sake > of consistency. > > Thanks > > Do you have any specific information on these locations? -- 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: Java Transaction API
On 03/08/2008, Petteri Räty <[EMAIL PROTECTED]> wrote: > Mark Wielaard kirjoitti: > > > > > I am unsure. I doubt any other distro ships the proprietary version. Why > > does Gentoo when (multiple) free versions are available? > > > > > > We have been doing this long before open source versions existed. We just > haven't been quick to replace things that don't show up in depgraphs for the > most used things. > > Regards, > Petteri > -- > Gentoo/Java project lead > > > I didn't realise Gentoo was alive and had Java support back in 1997... ;) This is by no means a personal attack or anything, so don't take it that way. I know you've done a lot of work to improve Free Java support on Gentoo, but the distro overall is less concerned with ensuring that packages are Free than, say, Debian or Fedora. Another example would be Motif support; lesstif seems to be packaged masked, so I had to backport doko's motif patch to remove the motif dependency and ensure that the IcedTea build in Gentoo was Free. I should note that we've recently had some good progress with Free Java on Gentoo, and a working gcj 4.3 is now available at last. -- 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: Java Transaction API
On 03/08/2008, Mark Wielaard <[EMAIL PROTECTED]> wrote: > Hi Andrew, > > > On Thu, 2008-07-31 at 22:52 +0100, Andrew John Hughes wrote: > > It seems Classpath includes the full set of interfaces for the Java > > Transaction API: > > > > http://en.wikipedia.org/wiki/Java_Transaction_API > > > > while the J2SE spec. only prescribes three exceptions used by CORBA: > > > > > http://java.sun.com/javase/6/docs/api/javax/transaction/package-summary.html > > > > They were (apparently) added by Warren Levy and Tom Tromey back in 2001. > > > Wow, we were quick and early back in the day :) > Yeah! I'm wondering why they were all added, because some of these still aren't part of the specification. Tom? > > > Gentoo currently has a JTA package that uses the version of these > > interfaces from Sun. These still seem to under a proprietary license > > (though IANAL): > > > > http://java.sun.com/javaee/technologies/jta/ > > > > even though there is presumably also a GPL version in Glassfish. > > > There is a version under dual license CDDL or GPL + Classpath exception > at: > https://glassfish.dev.java.net/source/browse/glassfish/transaction-api/src/ > > > > How do other distributions handle this? Is it worth our while moving > > these out of GNU Classpath into a separate package so people can use > > the Free Classpath versions? > > > I am unsure. I doubt any other distro ships the proprietary version. Why > does Gentoo when (multiple) free versions are available? > Don't get me started... ;) Gentoo seems to have a number of non-Free packages in its main tree, including proprietary JDKs which are used as the 'standard' JDK rather than gcj or OpenJDK. Given Glassfish is also a recent development, maybe this explains why the code is in GNU Classpath. It was probably needed to run J2EE servers Freely. > Feel free to create a little subpackage of javax.transaction.* for > distribution if you feel it would be useful to people. It is just > interface (constants) and exceptions, no real code, so I doubt anything > in it will change much. > I will if there is sufficient demand. At the moment, my guess would be people were using this for J2EE support on GNU Classpath. With the switch to OpenJDK generally, should we try and be more true to J2SE in Classpath and separate this out? > Cheers, > > > Mark > > Cheers, -- 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
Java Transaction API
Dear all, It seems Classpath includes the full set of interfaces for the Java Transaction API: http://en.wikipedia.org/wiki/Java_Transaction_API while the J2SE spec. only prescribes three exceptions used by CORBA: http://java.sun.com/javase/6/docs/api/javax/transaction/package-summary.html They were (apparently) added by Warren Levy and Tom Tromey back in 2001. Gentoo currently has a JTA package that uses the version of these interfaces from Sun. These still seem to under a proprietary license (though IANAL): http://java.sun.com/javaee/technologies/jta/ even though there is presumably also a GPL version in Glassfish. How do other distributions handle this? Is it worth our while moving these out of GNU Classpath into a separate package so people can use the Free Classpath versions? Thanks, -- 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: CACAO 0.99.2 released.
On 08/07/2008, Christian Thalinger <[EMAIL PROTECTED]> wrote: > CACAO 0.99.2 released. > > This is a bug-fix release. Here is a short list of the most important > changes: > > * Rewrite of atomic instructions code. This fixes problems with > AWT/Swing programs with OpenJDK. > * Fixed PR83, PR89. > > CACAO uses GNU Classpath as default Java runtime library and supports > upstream releases or CVS snapshots. This release requires GNU > Classpath 0.96 or higher to build and was tested against GNU Classpath > 0.97.2 on a number of various platforms. > > CACAO's ./configure has some options for Java runtime configuration, > namely: > > --with-java-runtime-library= > --with-java-runtime-library-prefix= > --with-java-runtime-library-classes= > --with-java-runtime-library-libdir= > > For detailed information, use ./configure --help. > > Currently supported JIT compiler architectures are: > > * alpha > * arm > * i386 > * m68k (broken) > * mips > * powerpc > * powerpc64 > * s390 > * sparc64 > * x86_64 > > Information about working applications and some screenshots can be > found on http://www.cacaovm.org/. > > The CACAO wiki can be found here: > http://c1.complang.tuwien.ac.at/cacaowiki/ > > The CACAO mailing lists can be found here: > http://c1.complang.tuwien.ac.at/mailman/listinfo/ > > Nightly test runs with CACAO Mercurial tip, GNU Classpath CVS head and > Mauve CVS head can be found on > http://www.complang.tuwien.ac.at/cacaojvm/jvmtester/. > > CACAO 0.99.2 can be downloaded from > http://www.complang.tuwien.ac.at/cacaojvm/download/cacao-0.99.2/ > > File : cacao-0.99.2.tar.gz > md5sum : a2865f47535f6dc3def268c0055ff20a > sha1sum: 2985f77415038d26a8e56bf0046ab8dae79a88da > > File : cacao-0.99.2.tar.bz2 > md5sum : 912e353a26c88ba5f5f59ebb9f688e2f > sha1sum: 9b1f25bff55c95d3c6ffef576a2d35a799c2d521 > > Enjoy! > > CACAOVM - Verein zur Foerderung der freien virtuellen Maschine CACAO > [EMAIL PROTECTED] > > Congratulations on the release! -- 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: Crypto functions supported.
2008/6/28 NACHO SAAVEDRA <[EMAIL PROTECTED]>: > Hello all! > I'm a new member and navigating into the classpath page I realized the info > is complete. However for now it's a little difficult to know if the issues > I'm searching are completely support for the gnu. > I'm searching a java examples (not too interested in the source code, only > the "black boxes") for the following process. > > Please could you tell me if all are supported by GNU ClassPath into the > Crypto functions? Thanks in advance. > > 1- KeyPair generation in assymetric encryption. > 2- 3DES key generation. > 3- To guard or store the generated keys. > 4- Assymetric encryption and decryption. RSA. > 5- Random number generation. > 6- To generate and validate DSS. > 7- Support of X.509 certificate (e.g. entity knows the seriousness of a > digital signature generator). > > Thanks and regards. > > José Ignacio Saavedra Vivas > Systems Engineer > > Our API comparisons may be useful: http://builder.classpath.org/japi/openjdk6-classpath.html#err_missing_javax_crypto -- 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: Other class libraries
2008/6/27 Christian Thalinger <[EMAIL PROTECTED]>: > On Tue, 2008-06-24 at 18:45 +0200, Christian Thalinger wrote: >> I guess this email came from the Long.signum() discussion we had today > > Ehh... will someone actually fix this bug? Otherwise I'll do it in the > Hackers Delight/OpenJDK way. > > - twisti > > I thought you already had :D -- 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: Other class libraries
2008/6/25 dalibor topic <[EMAIL PROTECTED]>: > Andrew John Hughes wrote: >> >> Unfortunately, such suppositions aren't worth much in legal terms (and >> let's get the obvious IANAL disclaimer in here before I say any more). >> As we discussed a little on IRC earlier today, it's actually quite a >> ridiculous situation that GNU Classpath and OpenJDK are just about >> under the same license, but because of that 'or later' clause, they >> are incompatible. Ideally, we would have imported a lot of OpenJDK >> code into GNU Classpath when it was released. Filling the holes in >> GCJ, for example, with Sun code would probably be a faster method of >> getting a TCK-passing implementation on non-x86/x86_64 platforms, >> assuming that such a combination counts as 'sufficiently derived'. In >> an ideal world, both would be under GPLv3 and we'd share code between >> the two as intended. On the other side, I've not seen as much code as >> I'd expect (like the AWT peers) move into OpenJDK either, but I think >> this is less legal and more process related. >> >> Dalibor, could you give us something from Sun's side on this issue? >> > > I'm not sure on which one: > > * whether combining a GPLd VM with OpenJDK class library would be > sufficiently derived > as far ar the OCTLA goes? > > Yes, please see the GB minutes > http://openjdk.java.net/groups/gb/2007-08-23.html#license-eligibility . > Well I suppose the question is more 'how much OpenJDK is needed to be substantially derived?' I suspect just having something like jaxws + cacao + classpath is not enough for example, while jaxws + hotspot + classpath would be. Is the TCK license available for general consumption yet? I'm slightly less perturbed by aph telling me that you do actually get source code. The fact that a myth to the contrary could permeate to me just shows the problems with such NDA stuff... ;) > * whether GPLv2 + Classpath exception and GPLv2 or later + Classpath > exception are incompatible? > > IANAL, but I'd say quite clearly no, they are compatible as you can pick v2 > regardless of what later later versions say in classpath's case. > This was mjw's interpretation, but I think, as pointed out here and in other threads, that it's more a policy-level issue (FSF/Sun) and I didn't comprehend that we need GPLv3+exception not GPLv3 for some reason. > * whether classpath or openjdk will be under GPLv3? > > It's always hard to predict the future, but I guess a lot of that will > depend on the ongoing work the FSF is doing to unify the exception language > around gcc, when it is ready for public review, and how it turns out - don't > understimate the scope of that work, it's been going on for a long time, as > readers of the autoconf lists know. It will also depend on what the actual > effects of the v3 version of the exceptions would be on v2 only users, or > VMs that have v2-only dependencies. Think VM-as-Linux-kernel-module > scenarios, or Kaffe. > Solaris should clearly just go GPLv3 and we should all switch to that, if Linux is going to stick with GPLv2 ;) > * whether FSF will accept GPLv2+Classpath exception code from openjdk into > classpath? > > Hard to say. I'm not quite sure what we'd gain from duplicating the same > code in several places though - if we want to turn classpath into an icedtea > like wrapper around bits and pieces from openjdk, we can do that without > copying and pasting openjdk code over into another repository (we've got > enough third party code in classpath as it is, imho). if there are bits from > openjdk that make sense to depend on as a 'source plug' for classpath, then > we could go the icepick route, for example, and wrap them up accordingly. > I wasn't thinking of duplicating or trashing code. More just of plugging the vast holes that I don't think there are sufficient people working on Classpath to fill any more e.g. jaxws as mentioned above. > * whether gcj will lose its own copy of classpath and be able to use an > installed one or an alternative class library? > > Hard to say. But it's basically the pragmatic reason why openjdk code hasn't > flown into classpath: it wouldn't look very good to have gplv2 only code in > a gplv3 gcc/gcj. That's a policy decision forced by the current architecture > of gcj - if the tight coupling between the class library and gcj was removed > (see JamVM, Cacao, etc.), that particular dilemma would not present itself > as such. This is actually something I'd be interested in looking at, if only I had the time. >> >> I hope we can come
Re: Other class libraries
On 24/06/2008, Roman Kennke <[EMAIL PROTECTED]> wrote: > > As we discussed a little on IRC earlier today, it's actually quite a > > ridiculous situation that GNU Classpath and OpenJDK are just about > > under the same license, but because of that 'or later' clause, they > > are incompatible. > > > IANAL either, but from my understanding this is not the problem. At > least not for contributors. The problem is copyright, and this is > regardless of the license, proprietary or free. If I look at Sun's code > and then go and implement something in GNU Classpath that is very > similar or equal to what I studied before in OpenJDK, I risk to be > blamed for copyright infringement. Normally in FLOSS projects this is > less of a problem because people have an attitude of sharing anyway, but > as you said, that doesn't count much from a legal POV. Of course, if the > licenses were compatible it would be much easier, we could simply import > the code in question into external/ and be done. > > Yes, it's the project-level import I was referred to here. If that were possible, it would automatically remove the possibility of code-copying for the most part. > /Roman > > -- > http://kennke.org/blog/ > > -- 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: Other class libraries
On 24/06/2008, Roman Kennke <[EMAIL PROTECTED]> wrote: > Hi Andrew, > > > > Since OpenJDK has been released, I've noticed that a tendency has > > arisen to not treat > > that codebase with the same 'don't look if working on the same code' > > approach we had > > when it was proprietary. When working on GNU Classpath, we still need > > to be careful > > about cross-pollination between codebases, even though the OpenJDK > > class libraries > > are under (nearly) the same license. > > > > This also applies for other class libraries, namely Harmony's. > > > So where is the boundary? I already spent significant time studying > OpenJDK's code, in the graphics area (as part of my Challenge project) > as well as several other areas. Am I disqualified now as GNU Classpath > contributor? (Not that I contributed much in the last weeks, but > still...) You are 'walking the line' then too, with the CPStringBuilder > effort (I think this has been 'inspired' by OpenJDK iirc), and as part > of your Challenge project you are also studying a lot of OpenJDK code I > suppose. > > Do we have any strong criteria by which we can measure which > contribution can go in and which can't? > > /Roman > > > -- > http://kennke.org/blog/ > > Hi Roman, I find myself asking the same questions, and this is why I raised the questions. I don't have all the answers either, and I'm sorry if the original mail came across like I was dictating a particular position. That wasn't the intention. FWIW, yes, both you and I have worked on both the Classpath and OpenJDK codebases of late, as have Mark, Mario, Christian and probably others - we're all in this together (although, just to clarify, CPStringBuilder was based on an idea in GCJ and the implementation (and its bugs) are original). I think it's an issue we need to look into, and we need to do so before it's too late. In reality, I don't think Sun is going to come chasing GNU Classpath contributors, if just because the majority are also now OpenJDK contributors (which is half the problem) and it would eradicate all the good work they've done with the Free Java community over the past couple of years. Unfortunately, such suppositions aren't worth much in legal terms (and let's get the obvious IANAL disclaimer in here before I say any more). As we discussed a little on IRC earlier today, it's actually quite a ridiculous situation that GNU Classpath and OpenJDK are just about under the same license, but because of that 'or later' clause, they are incompatible. Ideally, we would have imported a lot of OpenJDK code into GNU Classpath when it was released. Filling the holes in GCJ, for example, with Sun code would probably be a faster method of getting a TCK-passing implementation on non-x86/x86_64 platforms, assuming that such a combination counts as 'sufficiently derived'. In an ideal world, both would be under GPLv3 and we'd share code between the two as intended. On the other side, I've not seen as much code as I'd expect (like the AWT peers) move into OpenJDK either, but I think this is less legal and more process related. Dalibor, could you give us something from Sun's side on this issue? Mark, perhaps you can fill in some of the details I've probably left out, as you're much more aware of these matters than myself? I hope we can come to a decent resolution on this, but I think the issue does need to be discussed openly and as soon as possible. -- 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: Other class libraries
On 24/06/2008, Christian Thalinger <[EMAIL PROTECTED]> wrote: > On Tue, 2008-06-24 at 15:20 +0100, Andrew John Hughes wrote: > > Since OpenJDK has been released, I've noticed that a tendency has > > arisen to not treat > > that codebase with the same 'don't look if working on the same code' > > approach we had > > when it was proprietary. When working on GNU Classpath, we still need > > to be careful > > about cross-pollination between codebases, even though the OpenJDK > > class libraries > > are under (nearly) the same license. > > > > This also applies for other class libraries, namely Harmony's. > > > I guess this email came from the Long.signum() discussion we had today > on IRC. Today I noticed that we are failing this one, so I tried with > CACAO/OpenJDK and it worked. Then I had a look at GNU Classpath's code > and it was simply a one-liner. Wondering why it failed, I looked at the > OpenJDK code and asked Mark if we could not simply use that correct > implementation (from OpenJDK). > That's correct, but it's something that's troubled me for a while and with previous patches. > My point is, people are still working like in the "good old" proprietary > way, at least I do. But also back then one-liners haven't been a > problem. > It wasn't that specific case, but it reminded me of the issue in general. And, of course, that particular one-liner is taken from a book anyway! > - twisti > > -- 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
Other class libraries
Since OpenJDK has been released, I've noticed that a tendency has arisen to not treat that codebase with the same 'don't look if working on the same code' approach we had when it was proprietary. When working on GNU Classpath, we still need to be careful about cross-pollination between codebases, even though the OpenJDK class libraries are under (nearly) the same license. This also applies for other class libraries, namely Harmony's. Thanks, -- 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: CACAO 0.99 released.
On 14/06/2008, Christian Thalinger <[EMAIL PROTECTED]> wrote: > CACAO 0.99 "Just one step left..." released. > > This is a major feature enhancement and bug-fix release. Here is a > short list of the most important changes: > > * Initial support to use OpenJDK as Java runtime library. > * Fixed memory leak in Boehm-GC. > * Boehm-GC updated to version 7.1. > * Removed libltdl dependency. > * Renamed --with-classpath configure options to > --with-java-runtime-library. > * Renamed --with-jre-layout to --enable-layout. > * Replaced --with-classpath-includedir with --with-jni_h and > --with-jni_md_h to better support OpenJDK/IcedTea builds. > * Use 8-byte stack-slots on all architectures. > * Faster C-to-Java calls. > * Removed genoffsets, cross-compilation is now much easier. > * Implemented Class.isAnonymousClass(), isLocalClass() and > isMemberClass() for GNU Classpath. > * Annotation support. > * Assertion support. > * Linenumber table code rewritten. > * Exception table code rewritten. > > The major feature enhancement of this release is the OpenJDK support. > CACAO's libjvm.so can now be used as drop-in replacement for Sun's > HotSpot libjvm.so in OpenJDK. There is also support in IcedTea > available to use CACAO as JVM (--with-cacao option). > > CACAO uses GNU Classpath as default Java runtime library and supports > upstream releases or CVS snapshots. This release requires GNU > Classpath 0.96 or higher to build and was tested against GNU Classpath > 0.97.2 on a number of various platforms. > > CACAO's ./configure has some options for Java runtime configuration, > namely: > > --with-java-runtime-library= > --with-java-runtime-library-prefix= > --with-java-runtime-library-classes= > --with-java-runtime-library-libdir= > > For detailed information, use ./configure --help. > > Currently supported JIT compiler architectures are: > > * alpha > * arm > * i386 > * m68k (broken) > * mips > * powerpc > * powerpc64 > * s390 > * sparc64 > * x86_64 > > Information about working applications and some screenshots can be > found on http://www.cacaovm.org/. > > The CACAO wiki can be found here: > http://c1.complang.tuwien.ac.at/cacaowiki/ > > The CACAO mailing lists can be found here: > http://c1.complang.tuwien.ac.at/mailman/listinfo/ > > Nightly test runs with CACAO Mercurial tip, GNU Classpath CVS head and > Mauve CVS head can be found on > http://www.complang.tuwien.ac.at/cacaojvm/jvmtester/. > > CACAO 0.99 can be downloaded from > http://www.complang.tuwien.ac.at/cacaojvm/download/cacao-0.99/ > > File : cacao-0.99.tar.gz > md5sum : 7084fa846b39f9b33893a2179127c375 > sha1sum: cc14f1517b19e2110aef87ca1de1e9a9c8d6ff90 > > File : cacao-0.99.tar.bz2 > md5sum : cafe430ed0f57f6fc1216ac89f52141a > sha1sum: 04b2f7a2e68664cbfe30084e02e0310e05761a8e > > Enjoy! > > CACAOVM - Verein zur Foerderung der freien virtuellen Maschine CACAO > [EMAIL PROTECTED] > > > Congratulations! Been waiting for this for a _long_ time :D -- 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: Savannah has Mercurial!
2008/6/6 Mario Torre <[EMAIL PROTECTED]>: > Il giorno ven, 06/06/2008 alle 15.05 +0100, Ian Rogers ha scritto: >> Andrew John Hughes wrote: >> > I just noticed this announcement when submitting the news announcement >> > for 0.97.2. >> > >> > What do people think to the idea of switching? Maybe post 0.98? >> > >> > >> Hi, >> >> just to give a different perspective. For Jikes RVM there's been no >> choice to use Mercurial as SourceForge don't provide it, > > Hi Ian! > > We use hg with escher, and it's hosted on sf. You may give a look at > this: > > http://www.selenic.com/mercurial/wiki/index.cgi/MercurialOnSourceforge > > It's not publicized, but allowed by the sf team as far as I know. > Bah! You beat me to it! >> So in summary, having a central repository that's an >> SVN repository can be a good thing as it supports the maximum number of >> version control tools. We have a list of different tools for working >> with our repository (hg, git, svn, svk, darcs, svm, rsync) and how to >> set them up with Jikes RVM here: >> >> http://jikesrvm.org/Using+Distributed+And+Local+Version+Control+Tools >> >> I may be talking rubbish as I'm not a version control guru. Regards, > > I'm not sure I understand, but I don't think it's a good idea for > development to mix up. > > Just my 2 cents :) > I've been contemplating this idea as the discussion went on. I think a switch to something other than CVS is needed, as it just doesn't track things well enough in general. For me the speed of diffs/status checks in CVS is appalling and has a significant impact on my work habits. Maybe we should instead think about switching to SVN as our main tree and those who want to use Mercurial, git, darcs, etc. could work with them in the way Ian describes? Again, we'd obviously need a trial period. > Mario > > > -- 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: Savannah has Mercurial!
2008/6/6 Andrew Haley <[EMAIL PROTECTED]>: > Roman Kennke wrote: >> >>> What do people think to the idea of switching? Maybe post 0.98? Seems I've opened a proverbial can of worms with this... > Mercurial is a disaster as far as I can see. It doesn't seem to be > possible to work locally and merge back into the trunk without having > to do a complex and error-prone three-way merge, and several times > I've got into a state that it was impossible to recover from, even > with the help of the best Mercurial experts we have at RH. The only > way people work successfully is to merge from trunk, check in, and > then push their changes immediately to the mater repo before someone > else does any updates to the same files. If you don't get in fast > enough, merge time. This approach doesn't scale at all. I disagree. I think this impression stems from the attempt to map CVS development behaviour to Mercurial (or any other DVCS). I think the way that HG handles this is conceptionally better than CVS. Think about it: Developer A and B both clone the repository at Changeset (CS) 1. Both make changes and end try to push them back. We end up with: /-2 1 \-3 This needs to be merged, no matter if the changes are disjoint or not. Merging disjoint changes is easily done automatically. > > Indeed. This is the easy stuff, or should be. > > What you're seeing here is that the easy stuff (or stuff that *should* be > easy) is made hard for developers because of a policy to deal with > the super-hard rare stuff such as merges that break even though they > have no file conflicts. > Indeed. It's surprised me how often Mercurial has prompted me with merges, as if it can't do any of the job itself. The only time it should be done manually is when the same area of the same file differs. Patching manages to work just fine if a function has moved a few lines down, for example. So why can't Mercurial do this? I'm sure I've had clean merges though with local changes. Now you could argue that CVS does this automatically when committing. I argue that this is not a good idea, because even disjoint changes might lead to a broken tree (although it doesn't happen that often in a well-structured project like Classpath. But I've run into it several times). Even worse, with CVS you basically loose some in-between information (one of the CSs automatically get merged, while with HG you retain all the changesets and get one additional merge CS). > > Sure, but let's get away from arguing about CVS, which is ancient and > almost as broken as hg. > Unfortunately we can't completely, because this is what Classpath uses. If we were already on SVN like GCC, I suspect there'd be much less of an issue. snip... >> But committing changes to files (that doesn't trigger a conflict) >> will get the remote repository into a different state than you (and >> therefore anybody else) have on your machine, and is therefore not >> possible to prove that this is a reasonable state at all. > > Sure, but if none of the files you are committing has changed on the > trunk since the versions you edited, I don't expect a complaint about > merging from the VCS when none of the files have been merged. This is > just broken, whether it's deliberate policy or not. > > Here's how I want to work: > > Clone the repo. > Do work locally, committing as I go along. > Pull from the repo, merging changes from trunk with the changes I just > made. > Make sure it all works. > Push back my changes. > > If there's a merge conflict at Stage 3 because someone has changed the > same lines in a file that I have changed, then I expect to have to fix > a conflict. If there isn't, I don't want any complaints from the VCS. > This is how I also tend to work. snip.. > Frankly, I've never managed to get into such a state with HG either. In >> my experience, HG does the basic things like commit, merge, branches, >> etc just right. > > Well, I know it's possible in theory, but I also know what happens > when I try. And I've been around this in IRC, where I explain the > simple thing I've been trying to do, the fact it doesn't work, and > no-one has any clue how to repair the situation. I suspect that most > of the icedtea developers solve this problem simply by not doing local > hg operations at all. It would be interesting to ask icedtea > developers just how much they use hg to do local develeopment. > The little work I've done on IcedTea has been multiple-commit-pull-push as you outline above. The merging of the pull has required a little more of me than I'd expect, but I've not really had anything broken yet. snip... > >>> Any developer can create a branch any time they like, and work on >>> that branch as though it were their own repo, all changes are >>> tracked, and everything is safely backed up. Also, everyone gets >>> to see and s
Re: Savannah has Mercurial!
2008/6/6 Andrew Haley <[EMAIL PROTECTED]>: > Mark Wielaard wrote: >> Hi Andrew, >> >> On Fri, 2008-06-06 at 03:37 +0100, Andrew John Hughes wrote: >>> I just noticed this announcement when submitting the news announcement >>> for 0.97.2. >> >> Thanks for doing 0.97.2. I see Michael Koch already pushed it into >> Debian! >> >>> What do people think to the idea of switching? Maybe post 0.98? > > Mercurial is a disaster as far as I can see. It doesn't seem to be > possible to work locally and merge back into the trunk without having > to do a complex and error-prone three-way merge, and several times > I've got into a state that it was impossible to recover from, even > with the help of the best Mercurial experts we have at RH. The only > way people work successfully is to merge from trunk, check in, and > then push their changes immediately to the master repo before someone > else does any updates to the same files. If you don't get in fast > enough, merge time. This approach doesn't scale at all. > Yes, I recall reading your discussion of this on IRC. I think CVS has similar issues, if not worse, if you try to work in this way. Of course, doing so is pretty infeasible because even generating a diff requires server access. This and branch management are probably the biggest flaws for me; file/directory versioning is also another issue, but I fall prey to it less often. I do agree that Mercurial seems to be incredibly unintelligent when it comes to merges though - I presume it has it's own system rather than using patch. When Classpath had the same level of commits as IcedTea, we used to be more prone to these sort of mid-air collisions. I can remember the days of working on a patch, updating the repository when finished, testing with all the new changes that would have happened, then committing and failing because the ChangeLog had changed again in the interim. I don't think any VCS is perfect, and most buckle under heavy commits to a single repository. Distributed ones like Mercurial are a lot more flexible in allowing offline working and different development models, which I think is advantageous. I've been using it a lot just to maintain my own material between multiple machines. It's useful to me in this respect just for recording what I've done and for syncing between locations. This is more feasible largely because Mercurial trees are so much easier to create and make available. SSH (and optionally HTTP) access is all you really need. I assume most of your experience comes from working with IcedTea and Mercurial, where I think the project structure itself doesn't help. There are a relatively small number of files which increases the possibility of collision (e.g. nearly all the commits will be to Makefile.am, configure.ac and/or one of the patches). I found in doing the IcedTea6->IcedTea merge that having the autogenerated files from autoconf/automake in there didn't help either, as you'd never want to merge them manually and the newly generated version would differ depending on the version of the autotools it was generated on. By comparison, Classpath should have a much lower hit rate, with fewer developers and a much larger codebase, so I'm more hopeful there. That said, I think running a Mercurial tree in parallel with CVS for some time would be the best option, if feasible. If we do think switching would be a major disaster, we can then abandon it altogether or consider a simpler move to e.g. SVN. >> I wouldn't object (although I don't really have trouble with CVS at this >> point with classpath). So if enough developers think it is a positive >> switch lets do it. We would be the second project on savannah though, so >> expect some first adopter issues. >> >> The only thing we have to really look out for is doing a good >> conversion, some experimentation with hg convert and/or tailor might be >> necessary. >> >> Also a better understanding (best practices for) release branches would >> be nice. I found the in-tree branching of mercurial somewhat confusing >> at times, so it would be good to make sure we have clear guidelines for >> those who want to do (release) branches on the tree would be nice. > > Indeed. The conversion of the history for gcc was done excellently > with no loss of data. We must maks sure we do just as well. > Couldn't agree more. > Andrew. > -- 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: Savannah has Mercurial!
2008/6/6 Mark Wielaard <[EMAIL PROTECTED]>: > Hi Andrew, > > On Fri, 2008-06-06 at 03:37 +0100, Andrew John Hughes wrote: >> I just noticed this announcement when submitting the news announcement >> for 0.97.2. > > Thanks for doing 0.97.2. I see Michael Koch already pushed it into > Debian! > Wow, that was quick! I guess because he was already testing pre-releases earlier this week. >> What do people think to the idea of switching? Maybe post 0.98? > > I wouldn't object (although I don't really have trouble with CVS at this > point with classpath). So if enough developers think it is a positive > switch lets do it. We would be the second project on savannah though, so > expect some first adopter issues. > > The only thing we have to really look out for is doing a good > conversion, some experimentation with hg convert and/or tailor might be > necessary. > > Also a better understanding (best practices for) release branches would > be nice. I found the in-tree branching of mercurial somewhat confusing > at times, so it would be good to make sure we have clear guidelines for > those who want to do (release) branches on the tree would be nice. > A lot of thought does need to go into it, which is why if we do switch, I wouldn't want to do so before 0.98 is out, as it could delay it even further. I did try to hg convert it once and didn't get very far. A tree as old as Classpath will be non-trivial. As to release branches, I actually prefer a completely separate tree (like icedtea/icedtea6) rather than in-tree branches, but I'm not sure Savannah would support this. > Cheers, > > Mark > > Cheers, -- 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
Savannah has Mercurial!
I just noticed this announcement when submitting the news announcement for 0.97.2. What do people think to the idea of switching? Maybe post 0.98? -- 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
Classpath 0.97.2 released!
We are proud to announce the release of GNU Classpath 0.97.2, the second bugfix release for GNU Classpath 0.97. GNU Classpath, essential libraries for java, is a project to create free core class libraries for use with runtimes, compilers and tools for the java programming language. The GNU Classpath developer snapshot releases are not directly aimed at the end user but are meant to be integrated into larger development platforms. For example JamVM, CACAO and Kaffe can make use of an installed copy of GNU Classpath 0.97.2, while GCC (gcj) will use the developer snapshots as a base for future versions. For more projects based on GNU Classpath, see http://www.gnu.org/software/classpath/stories.html This is the second of a new series of bugfix releases that follow a major (0.x) release. A 0.x.y release will only contain minor bug fixes. It will not cause major changes in the functionality of GNU Classpath, either for better or for worse. With this bugfix release, the following issues have been resolved: * Include headers in the release tarball. * Allow the building of tools to be optional. * Only check for a Java compiler when required. * Allow VMOperatingSystemMXBeanImpl to compile on Solaris. * Documentation typo fixes * Fix memory leak in native/jni/classpath/jcl.c * Web page updates (PR classpath/22883) * Fixes to pass the JSR166 TCK * Use awk to construct the classlist on building * Fix deadlock in Logger (PR classpath/35974) * Fix regression in java.lang.String (PR classpath/35482) * Allow Classpath tools to handle @file options. * Allow parseInt to handle a + prefix correctly. * Remove use of 1.5 language constructs in the VM layer. >From the 0.95 release, we switched fully towards the 1.5 generics work that we previously released separately as classpath-generics. All this work is now fully integrated in the main release and various runtimes (GCJ, CACAO, JamVM, JikesRVM etc) have been extended to take advantage of the new generics, annotations and enumeration support in the core library. As a consequence, only 1.5 capable compilers (currently the Eclipse Compiler for Java (ecj) and Sun's javac) may be used to build Classpath. The GNU Classpath developers site (http://developer.classpath.org/) provides detailed information on how to start with helping the GNU Classpath project and gives an overview of the core class library packages currently provided. For each snapshot release generated documentation is provided through the GNU Classpath Tools gjdoc project, which will become part of GNU Classpath itself with the release of 0.98. A documentation generation framework for java source files used by the GNU project. Full documentation on the currently implemented packages and classes can be found at: http://developer.classpath.org/doc/ We are looking into how to extend the documentation experience in the future. Please contact the mailinglist if you would like to help with this effort. For more information about the project see also: GNU Classpath home page: http://www.gnu.org/software/classpath/ Developer information (wiki): http://developer.classpath.org/ Full class documentation: http://developer.classpath.org/doc/ GNU Classpath hackers: http://planet.classpath.org/ Autobuilder, current build status, build snapshots: http://builder.classpath.org/ Application test pages (wiki): http://developer.classpath.org/mediation/Applets http://developer.classpath.org/mediation/FreeAWTTestApps http://developer.classpath.org/mediation/FreeSwingTestApps http://developer.classpath.org/mediation/FreeSWTTestApps GNU Classpath hacking with Eclipse (wiki): http://developer.classpath.org/mediation/ClasspathHackingWithEclipse GNU Classpath promotion banners: http://developer.classpath.org/mediation/ClasspathBanners GNU Classpath 0.97.2 is available from ftp://ftp.gnu.org/pub/gnu/classpath/, one of the ftp.gnu.org mirrors (http://www.gnu.org/order/ftp.html) or the Classpath continuous integration system (http://builder.classpath.org/dist) File: classpath-0.97.2.tar.gz MD5sum: 6a35347901ace03c31cc49751b338f31 SHA1sum: 627e9781f9bb744b1a70e4aaff88d2d0440cbf1f The following people helped fix bugs in Classpath 0.97.1: Andrew John Hughes, Michael Koch, Jim Meyering, Robert Schuster, Mario Torre, Tom Tromey, Ralf Wildenhues The following people helped with the release of Classpath 0.97 and/or 0.97.1: Luciano Chavez, Thomas Fitzsimmons, Bernhard Fischer, Jeroen Frijters, Stefan Huehner, Andrew John Hughes, Jakub Jelinek, Ito Kazumitsu, Roman Kennke, Alexandre Oliva, Petteri Raety, Ian Rogers, Robert Schuster, Leen Toelen, Mario Torre, Dalibor Topic, Tom Tromey, David Walluck, Mark Wielaard and Ralf Wildenhues. We would also like to thank the numerous bug reporters and testers! In addition, we'd like to extend our thanks to all those who've contributed over the years and have helped in building a thriving and friendly community around
Re: javah in 0.97+ -> trouble
2008/5/14 Michael Koch <[EMAIL PROTECTED]>: > > On Wed, May 14, 2008 at 09:51:58AM +0200, Christian Thalinger wrote: > > On Wed, 2008-05-14 at 01:19 +0200, Robert Schuster wrote: > > > 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. > > > > That sounds like a good idea. It won't help in any situation but maybe > > in some.d > > I would prefer if *releases* would contain generated header files. > This would make building on a new arch a lot easier. > > Also would this remove the need to build the java parts on a new arch > where there is probably no javac yet. > > > Cheers, > Michael > > I believe we talked about using the built javah as it's a fairly obvious thing to do. I definitely don't think we want to do this by default because it would put even more dependence on the existing Java environment, but we could look at an option for it. The tools would have to be built first in this case, using the host's existing class library. I think providing pre-generated headers for the release is more urgent, and was surprised we didn't do this already. -- 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: Classpath 0.98
2008/5/14 Mario Torre <[EMAIL PROTECTED]>: > Il giorno dom, 11/05/2008 alle 15.55 +0100, Andrew John Hughes ha > scritto: > > > On 11/05/2008, Ian Rogers <[EMAIL PROTECTED]> wrote: > > > Andrew John Hughes wrote: > > > > > > > Dear all, > > > > > > > > I think it's about time we started to consider another (major) > > > > release. My personal wishlist of things to finish for this release > > If we can delay a little, I would like to finish two things: > > 1. escher peer made usable > > I'm almost there, but I'm fixing a couple of bugs that are important, I > guess I'll need a full week to make things solid. > > 2. Fix the bug in the GConf backend. > > It's too much time now really, I want to fix this bug, but I can work on > this only on this weekend, maybe the next one... so it makes a full week > again. > > Let me know if it's ok for you to wait a little, I don't want to delay > the release, so feel free to ignore me :) > > Btw, we need the usual testing period anyway, but I think Classpath is > better than ever :) > > 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/ > > > Shouldn't be a problem. I need roughly the same time, if not more, myself so was thinking about early to mid June for a release. Much longer and we will probably have too many changes for one release IMO (the GMP and CPStringBuilder are already quite significant changes in themselves). Part of my intention of this mail was to highlight the final list of things I intend to do for this release (and Ian, I will include SpecJVM in this). Anything other than that I want to postpone, personally, so I can devote my FOSS time over the next few months to the OpenJDK project and the challenge proposal. -- 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: 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
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: Integer.parseInt("+42") gives -42
On 12/05/2008, Andrew Haley <[EMAIL PROTECTED]> wrote:
> Andrew John Hughes wrote:
>
> >
> > Interestingly, our parseInt Mauve test has this:
> >
> > // In JDK1.7, '+' is considered a valid character.
> > try
> > {
> > i = Integer.parseInt("+10");
> > harness.check(true);
> > }
> > catch (NumberFormatException nfe)
> > {
> > harness.fail("Leading '+' does not throw NumberFormatException");
> > }
> >
> > and indeed it does return 42 (so Classpath is still wrong returning
> > -42).
>
>
> 1.7 Javadoc:
>
>
> /**
> * Parses the string argument as a signed integer in the radix
> * specified by the second argument. The characters in the string
> * must all be digits of the specified radix (as determined by
> * whether [EMAIL PROTECTED] java.lang.Character#digit(char, int)}
> returns a
> * nonnegative value), except that the first character may be an
> * ASCII minus sign [EMAIL PROTECTED] '-'} ('\u002D') to
> * indicate a negative value or an ASCII plus sign [EMAIL PROTECTED] '+'}
> * ('\u002B') to indicate a positive value. The
> * resulting integer value is returned.
> *
> * An exception of type [EMAIL PROTECTED] NumberFormatException} is
> * thrown if any of the following situations occurs:
> *
> * The first argument is [EMAIL PROTECTED] null} or is a string of
> * length zero.
> *
> * The radix is either smaller than
> * [EMAIL PROTECTED] java.lang.Character#MIN_RADIX} or
> * larger than [EMAIL PROTECTED] java.lang.Character#MAX_RADIX}.
> *
> * Any character of the string is not a digit of the specified
> * radix, except that the first character may be a minus sign
> * [EMAIL PROTECTED] '-'} ('\u002D') or plus sign
> * [EMAIL PROTECTED] '+'} ('\u002B') provided that the
> * string is longer than length 1.
> *
> * The value represented by the string is not a value of type
> * [EMAIL PROTECTED] int}.
> *
> *
> * Examples:
> *
> * parseInt("0", 10) returns 0
> * parseInt("473", 10) returns 473
> * parseInt("+42", 10) returns 42
>
I'm just testing a patch that correctly provides the 1.7 behaviour.
I've also made Mauve spot the bad Classpath behaviour.
--
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: Integer.parseInt("+42") gives -42
On 12/05/2008, Andrew John Hughes <[EMAIL PROTECTED]> wrote:
> On 12/05/2008, Tom Tromey <[EMAIL PROTECTED]> wrote:
> > >>>>> "David" == David Daney <[EMAIL PROTECTED]> writes:
> >
> > David> I am not an expert in this realm, but this may be small enough
> > David> so that an assignment is not necessary.
> >
> > Yes, I agree, particularly because there is really only one fix for
> > this -- delete the '+' code.
>
>
> It would be small enough, was this his only contribution. But his
> mention of commit rights implies previous contributions and there are
> several ChangeLog entries:
>
> ChangeLog-2005:2005-12-18 Nicolas Geoffray <[EMAIL PROTECTED]>
> ChangeLog-2005:2005-12-14 Nicolas Geoffray <[EMAIL PROTECTED]>
> ChangeLog-2005:2005-12-04 Nicolas Geoffray <[EMAIL PROTECTED]>
> ChangeLog-2005:2005-12-04 Nicolas Geoffray <[EMAIL PROTECTED]>
> ChangeLog-2005:2005-12-03 Nicolas Geoffray <[EMAIL PROTECTED]>
> ChangeLog-2005:2005-10-28 Nicolas Geoffray <[EMAIL PROTECTED]>
> ChangeLog-2005:2005-10-21 Nicolas Geoffray <[EMAIL PROTECTED]>
> ChangeLog-2005:2005-10-21 Nicolas Geoffray <[EMAIL PROTECTED]>
> ChangeLog-2005: Reported by Nicolas Geoffray <[EMAIL PROTECTED]>
> ChangeLog-2006:2006-01-16 Nicolas Geoffray <[EMAIL PROTECTED]>
>
> This does imply to me that he already has an assignment, but either he
> or mjw needs to confirm this.
>
>
> Actually, the proposed patch doesn't
> > seem to go far enough in that direction... AFAICT a leading '+' is not
> > allowed at all; there's no reason to check for it specially.
> >
> >
> > Tom
> >
>
>
> This strikes me as odd too, but I haven't yet had chance to test the
> code itself against OpenJDK.
>
> --
> 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
>
Interestingly, our parseInt Mauve test has this:
// In JDK1.7, '+' is considered a valid character.
try
{
i = Integer.parseInt("+10");
harness.check(true);
}
catch (NumberFormatException nfe)
{
harness.fail("Leading '+' does not throw NumberFormatException");
}
and indeed it does return 42 (so Classpath is still wrong returning
-42). OpenJDK6 throws an exception:
Exception in thread "main" java.lang.NumberFormatException: For input
string: "+42"
at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:470)
at java.lang.Integer.parseInt(Integer.java:514)
at TestPlusPrefix.main(TestPlusPrefix.java:5)
--
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: Integer.parseInt("+42") gives -42
On 12/05/2008, Tom Tromey <[EMAIL PROTECTED]> wrote: > > "David" == David Daney <[EMAIL PROTECTED]> writes: > > David> I am not an expert in this realm, but this may be small enough > David> so that an assignment is not necessary. > > Yes, I agree, particularly because there is really only one fix for > this -- delete the '+' code. It would be small enough, was this his only contribution. But his mention of commit rights implies previous contributions and there are several ChangeLog entries: ChangeLog-2005:2005-12-18 Nicolas Geoffray <[EMAIL PROTECTED]> ChangeLog-2005:2005-12-14 Nicolas Geoffray <[EMAIL PROTECTED]> ChangeLog-2005:2005-12-04 Nicolas Geoffray <[EMAIL PROTECTED]> ChangeLog-2005:2005-12-04 Nicolas Geoffray <[EMAIL PROTECTED]> ChangeLog-2005:2005-12-03 Nicolas Geoffray <[EMAIL PROTECTED]> ChangeLog-2005:2005-10-28 Nicolas Geoffray <[EMAIL PROTECTED]> ChangeLog-2005:2005-10-21 Nicolas Geoffray <[EMAIL PROTECTED]> ChangeLog-2005:2005-10-21 Nicolas Geoffray <[EMAIL PROTECTED]> ChangeLog-2005: Reported by Nicolas Geoffray <[EMAIL PROTECTED]> ChangeLog-2006:2006-01-16 Nicolas Geoffray <[EMAIL PROTECTED]> This does imply to me that he already has an assignment, but either he or mjw needs to confirm this. Actually, the proposed patch doesn't > seem to go far enough in that direction... AFAICT a leading '+' is not > allowed at all; there's no reason to check for it specially. > > > Tom > This strikes me as odd too, but I haven't yet had chance to test the code itself against OpenJDK. -- 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: 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: Classpath 0.98
On 11/05/2008, Ian Rogers <[EMAIL PROTECTED]> wrote: > Andrew John Hughes wrote: > > > Dear all, > > > > I think it's about time we started to consider another (major) > > release. My personal wishlist of things to finish for this release > > is: > > > > * java.util.regex 1.6 support > > * java.util.Scanner import (dependent on the above) > > * import of javax.activation > > > > Another possibility is to also import gjdoc; our options there are: > > > > * Add GJDoc for 0.98 > > * Add GJDoc post-release (ending up in 0.99) > > * Don't add it at all > > > > It would obviously be an optional build. > > > > Does anyone have any other suggestions for things that should make this > release? > > Please highlight any regressions you know of as well. PR36199 that > > twisti just filed seems like it should be fixed, for example. > > > > Thanks, > > > > > It'd be great if SPEC jvm 2008 were known to run. There are issues on Cacao > and Jikes RVM related to Classpath. > > Thanks, > Ian > This would be helped if the bugs were narrowed down and filed as Classpath bugs against current CVS, rather than being largely unhelpful stack traces against Classpath 0.97 that are difficult to reproduce. There are few people actively working on GNU Classpath today so any help to reduce the leg work required to fix bugs is much appreciated. Reading the RVM bug, the two issues confused me. The Class issue seems JikesRVM specific and indeed, Classpath has been compiling javac since it was Freed in 2006. In fact, I'm not sure this wasn't also fixed in a recent rvm commit; it doesn't appear in the JAPI run. The XML issue I thought was also seen before, but it may just be very similar to another. It's definitely worth filing that on Classpath as I doubt Chris, who wrote the JAXP packages, will be monitoring RVM issues. Thanks, -- 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
Classpath 0.98
Dear all, I think it's about time we started to consider another (major) release. My personal wishlist of things to finish for this release is: * java.util.regex 1.6 support * java.util.Scanner import (dependent on the above) * import of javax.activation Another possibility is to also import gjdoc; our options there are: * Add GJDoc for 0.98 * Add GJDoc post-release (ending up in 0.99) * Don't add it at all It would obviously be an optional build. Does anyone have any other suggestions for things that should make this release? Please highlight any regressions you know of as well. PR36199 that twisti just filed seems like it should be fixed, for example. Thanks, -- 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
Building the VM classes
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? Thanks, -- 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: SPEC jvm 2008 successes?
2008/5/9 Ian Rogers <[EMAIL PROTECTED]>: > Hi, > > I was wondering what success people have had running SPEC jvm 2008 [1]. My > experiences are here [2] and I'd like to get further. If anyone succeeds I'd > be interested to know. > > Thanks, > Ian > > [1] http://www.spec.org/jvm2008/ > [2] http://jira.codehaus.org/browse/RVM-480 > -- > Third International Workshop on Implementation, Compilation, Optimization > of Object-Oriented Languages, Programs and Systems (ICOOOLPS 2008) > Submissions/Notification/Conference: May 12th/May 19th/July 7th > Paphos (Cyprus) http://icoolps.loria.fr > > If you look at my comments on the bug, you'll see this comes down to a problem with our ImageIO JPEG write support (done via GdkPixbuf) and a lack of metadata. http://jfreechart.svn.sourceforge.net/viewvc/jfreechart/trunk/source/org/jfree/chart/encoders/SunJPEGEncoderAdapter.java?revision=286&view=markup -- 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
