Re: Future blog

[Dr Andrew John Hughes]

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 penb...@kernel.org
 Date: Sun, 12 Dec 2010 10:52:27 +0200
 Subject: [PATCH] mauve: Add test case for Class.getSimpleName()
 
 Signed-off-by: Pekka Enberg penb...@kernel.org
 ---
  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

[Pekka Enberg]

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 penb...@kernel.org
Date: Sun, 12 Dec 2010 10:52:27 +0200
Subject: [PATCH] mauve: Add test case for Class.getSimpleName()

Signed-off-by: Pekka Enberg penb...@kernel.org
---
 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

Re: Future blog

[Andrew Haley]

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 a...@redhat.com 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.

Andrew.

Re: Future blog

[Andrew Haley]

On 12/08/2010 05:15 PM, Dr Andrew John Hughes wrote:
 
 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.

Sure.  I'll try to have a look at a few of them today.

Andrew.

Re: Future blog

[Andrew Haley]

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.

And every ML, I would have thought.  What possible advantage could
there be in generating patch mails in which the patch doesn't appear
in the body of the mail?

Andrew.

Re: Future blog

[Andrew Haley]

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.

Andrew.

Re: Future blog

[Dr Andrew John Hughes]

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: Future blog

[Dr Andrew John Hughes]

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 a...@redhat.com 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

[Andrew Haley]

On 12/09/2010 12:44 PM, Dr Andrew John Hughes wrote:
 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.

Yes, of course.  It's a lot less painful, though.

Andrew.

Re: Future blog

[Andrew Haley]

On 12/09/2010 12:45 PM, Dr Andrew John Hughes wrote:
 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 a...@redhat.com 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.

Well, it means it's been reviewed already.  In this case I know it's
already been tested because I tested it, as the mails show.

 As far as I'm aware, Pekka already has a testcase for
 this so it would be good to have it in Mauve.

Definitely.

Andrew.

Re: Future blog

[Gary Benson]

Dr Andrew John Hughes wrote:
 On 23:06 Tue 07 Dec, Mark Wielaard 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.

Seriously?  There's no reason anybody needs to be using CVS these
days.

Cheers,
Gary

-- 
http://gbenson.net/

Re: Future blog

[Brian Jones]

Hi all, long time, no commit.

It is unclear from my vantage point what the purpose of Classpath should be.  
Most of the VMs I'm familiar with who were essentially customers in the past 
are moving to support openjdk's class library it seems  Thank goodness for 
JamVM and all the rest over the years.

Brian

On Dec 7, 2010, at 6:53 PM, Dr Andrew John Hughes gnu_and...@member.fsf.org 
wrote:

 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 

Re: Future blog

[Mark Wielaard]

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.

 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.

 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.

   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.

  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.

 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.

Thanks,

Mark

Re: Future blog

[Pekka Enberg]

On Wed, Dec 8, 2010 at 12:32 PM, Andrew Haley a...@redhat.com wrote:
 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.)

But it's not a red herring! I don't expect to have commit rights to
GNU Classpath. I'm more than happy to send patches to the list and
have someone else merge them (that's in fact a model I personally
prefer). Unfortunately, as things stand, CVS as itself is totally
useless for this model of development.

Pekka

Re: Future blog

[Pekka Enberg]

On Wed, Dec 8, 2010 at 12:32 PM, Andrew Haley a...@redhat.com 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

http://developer.classpath.org/pipermail/classpath-patches/2010-November/006513.html

http://developer.classpath.org/pipermail/classpath-patches/2010-November/006512.html

There's also 10-15 patches from Ivan sitting in the archives and from
last count roughly the same amount of patches in Bugzilla.

Pekka

Re: Future blog

[Andrew Haley]

On 12/08/2010 10:56 AM, Pekka Enberg wrote:
 On Wed, Dec 8, 2010 at 12:32 PM, Andrew Haley a...@redhat.com wrote:
 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.)
 
 But it's not a red herring! I don't expect to have commit rights to
 GNU Classpath. I'm more than happy to send patches to the list and
 have someone else merge them (that's in fact a model I personally
 prefer).

This model does not scale.  Also, it is unreliable: no-one should
commit a patch they haven't tested themselves.  It leads to extra
work.  It's also bad because it leads to two classes of developers,
those with and those without commit access.

Every developer should commit their own patches.

Andrew.

Re: Future blog

[Andrew Haley]

On 12/08/2010 10:58 AM, Pekka Enberg wrote:
 On Wed, Dec 8, 2010 at 12:32 PM, Andrew Haley a...@redhat.com 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
 
 http://developer.classpath.org/pipermail/classpath-patches/2010-November/006513.html
 
 http://developer.classpath.org/pipermail/classpath-patches/2010-November/006512.html
 
 There's also 10-15 patches from Ivan sitting in the archives and from
 last count roughly the same amount of patches in Bugzilla.

The Classpath route is to post patches to the list.  I think this
is true of most GNU projectes.

Andrew.

Re: Future blog

[Pekka Enberg]

On Wed, Dec 8, 2010 at 12:32 PM, Andrew Haley a...@redhat.com wrote:
 But I'm afraid people are looking at the things they think might make
 a difference, but won't make a difference.  I read the list, and
 haven't seen a huge number of unreviewed patches, but I admit I
 haven't been paying close enough attention.

You don't see the whole picture if you look at the number unreviewed
patches alone (which is btw roughly as much as what you've committed
this year!). I for example, am very interested in getting some of the
simple things I've discovered fixed. Unfortunately the whole process
is so slow and uncertain at the moment I don't know if it's worth the
effort to send even more patches. (I'm optimistic though and currently
waiting for FSF papers to arrive.) I'm not claiming you're losing a
major contributor in me but you are losing someone who is (a) capable
of fixing things and (b) cares deeply about GNU Classpath.

Pekka

Re: Future blog

[Andrew Haley]

On 12/08/2010 10:58 AM, Pekka Enberg wrote:
 On Wed, Dec 8, 2010 at 12:32 PM, Andrew Haley a...@redhat.com 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.

 http://developer.classpath.org/pipermail/classpath-patches/2010-November/006512.html

What compatibility problem does this fix?

 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.

Re: Future blog

[Pekka Enberg]

Hi Andrew,

On Wed, Dec 8, 2010 at 1:06 PM, Andrew Haley a...@redhat.com wrote:
 On 12/08/2010 10:56 AM, Pekka Enberg wrote:
 On Wed, Dec 8, 2010 at 12:32 PM, Andrew Haley a...@redhat.com wrote:
 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.)

 But it's not a red herring! I don't expect to have commit rights to
 GNU Classpath. I'm more than happy to send patches to the list and
 have someone else merge them (that's in fact a model I personally
 prefer).

 This model does not scale.  Also, it is unreliable: no-one should
 commit a patch they haven't tested themselves.  It leads to extra
 work.  It's also bad because it leads to two classes of developers,
 those with and those without commit access.

Well, you know, it works just fine for the Linux kernel so as a
general statement, that's just not true.

 Every developer should commit their own patches.

I didn't mean to start an argument on what kind of development model
GNU Classpath should be using. But I don't quite agree with the above
statement because waiting for commit access creates a barrier for
people who just want to submit simple one-liners. In any case, even if
everyone did have commit access, CVS is still painful for *local*
development.

Pekka

Re: Future blog

[Pekka Enberg]

On Wed, Dec 8, 2010 at 1:13 PM, Andrew Haley a...@redhat.com 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:

http://developer.classpath.org/pipermail/classpath-patches/2010-June/006411.html

http://developer.classpath.org/pipermail/classpath-patches/2010-June/006424.html

http://developer.classpath.org/pipermail/classpath-patches/2010-June/006437.html

http://developer.classpath.org/pipermail/classpath-patches/2010-June/006438.html

http://developer.classpath.org/pipermail/classpath-patches/2010-June/006441.html

http://developer.classpath.org/pipermail/classpath-patches/2010-June/006439.html

http://developer.classpath.org/pipermail/classpath-patches/2010-June/006440.html

http://developer.classpath.org/pipermail/classpath-patches/2010-June/006442.html

http://developer.classpath.org/pipermail/classpath-patches/2010-June/006443.html

http://developer.classpath.org/pipermail/classpath-patches/2010-June/006444.html

http://developer.classpath.org/pipermail/classpath-patches/2010-June/006445.html

http://developer.classpath.org/pipermail/classpath-patches/2010-June/006446.html

http://developer.classpath.org/pipermail/classpath-patches/2010-June/006447.html

http://developer.classpath.org/pipermail/classpath-patches/2010-June/006448.html

Re: Future blog

[Pekka Enberg]

On Wed, Dec 8, 2010 at 1:13 PM, Andrew Haley a...@redhat.com wrote:
 http://developer.classpath.org/pipermail/classpath-patches/2010-November/006512.html

 What compatibility problem does this fix?

That the result is not what we get with OpenJDK. JamVM, for example,
(and I guess CACAO) has fixed this in their tree as has GCJ. The test
case I used for this is ClassTest.testGetSimpleName() here:

https://github.com/penberg/malva/blob/master/src/malva/java/lang/ClassTest.java

Re: Future blog

[Andrew Haley]

On 12/08/2010 11:32 AM, Pekka Enberg wrote:
 On Wed, Dec 8, 2010 at 1:13 PM, Andrew Haley a...@redhat.com 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:
 
 http://developer.classpath.org/pipermail/classpath-patches/2010-June/006411.html

Ah, yes, these were the patches that were sent hex encoded with a
MIME type of application/octet-stream.  Needless to say these didn't
get reviewed.

I'll have a look, but IMO it is unreaslistic to expect a reviewer to
save an attachment and open it in an external editor.  And I did point
this out at the time.

Andrew.

Re: Future blog

[Pekka Enberg]

On Wed, Dec 8, 2010 at 1:41 PM, Andrew Haley a...@redhat.com wrote:
 I'm not sure if this is all of it but it's a start anyway:

 http://developer.classpath.org/pipermail/classpath-patches/2010-June/006411.html

 Ah, yes, these were the patches that were sent hex encoded with a
 MIME type of application/octet-stream.  Needless to say these didn't
 get reviewed.

Right.

 I'll have a look, but IMO it is unreaslistic to expect a reviewer to
 save an attachment and open it in an external editor.  And I did point
 this out at the time.

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

Re: Future blog

[Gary Benson]

Andrew Haley wrote:
 On 12/08/2010 11:23 AM, Pekka Enberg wrote:
  In any case, even if everyone did have commit access, CVS is still
  painful for *local* development.
 
 Not for me.  I mean, it's not great, but it's hardly a big factor in
 the time it takes to develop code.

I think different people use their VCS different amounts as they work.
I use it *constantly*:

  mambo$ awk '{print $1}' ~/.bash_history | sort | uniq -c | sort -nr
  416 hg
   66 bin/thingtest
   53 emacs
   50 cd
   34 chmod
   33 cat
   28 ls
  ...etc...

So for me, how the VCS works is paramount to my getting anything done,
and with CVS specifically I almost can't work offline.  I'm guessing
you use your VCS a lot less than I do...

Cheers,
Gary
   
-- 
http://gbenson.net/

Re: Future blog

[Andrew Haley]

On 12/08/2010 11:37 AM, Pekka Enberg wrote:
 On Wed, Dec 8, 2010 at 1:13 PM, Andrew Haley a...@redhat.com wrote:
 http://developer.classpath.org/pipermail/classpath-patches/2010-November/006512.html

 What compatibility problem does this fix?
 
 That the result is not what we get with OpenJDK. JamVM, for example,
 (and I guess CACAO) has fixed this in their tree as has GCJ. The test
 case I used for this is ClassTest.testGetSimpleName() here:
 
 https://github.com/penberg/malva/blob/master/src/malva/java/lang/ClassTest.java

The patch is OK.

I'm not sure about this bit, but I can live with it:

@@ -299,24 +299,24 @@ final class VMClass
 if (isAnonymousClass(klass))
   return ;
 if (isArray(klass))
-  {
-return getComponentType(klass).getSimpleName() + [];
-  }
+  return getComponentType(klass).getSimpleName() + [];
+

Andrew.

Re: Future blog

[Pekka Enberg]

On Wed, Dec 8, 2010 at 1:47 PM, Andrew Haley a...@redhat.com wrote:
 That the result is not what we get with OpenJDK. JamVM, for example,
 (and I guess CACAO) has fixed this in their tree as has GCJ. The test
 case I used for this is ClassTest.testGetSimpleName() here:

 https://github.com/penberg/malva/blob/master/src/malva/java/lang/ClassTest.java

 The patch is OK.

 I'm not sure about this bit, but I can live with it:

No need to live with it, I'll fix it up and resend.

Re: Future blog

[Andrew Haley]

On 12/08/2010 11:47 AM, Gary Benson wrote:
 Andrew Haley wrote:
 On 12/08/2010 11:23 AM, Pekka Enberg wrote:
 In any case, even if everyone did have commit access, CVS is still
 painful for *local* development.

 Not for me.  I mean, it's not great, but it's hardly a big factor in
 the time it takes to develop code.
 
 I think different people use their VCS different amounts as they work.
 I use it *constantly*:
 
   mambo$ awk '{print $1}' ~/.bash_history | sort | uniq -c | sort -nr
   416 hg
66 bin/thingtest
53 emacs
50 cd
34 chmod
33 cat
28 ls
   ...etc...
 
 So for me, how the VCS works is paramount to my getting anything done,
 and with CVS specifically I almost can't work offline.  I'm guessing
 you use your VCS a lot less than I do...

Possibly, but I don't work offline.  Ever.

Andrew.

Re: Future blog

[Andrew Haley]

On 12/08/2010 11:49 AM, Pekka Enberg wrote:
 On Wed, Dec 8, 2010 at 1:47 PM, Andrew Haley a...@redhat.com wrote:
 That the result is not what we get with OpenJDK. JamVM, for example,
 (and I guess CACAO) has fixed this in their tree as has GCJ. The test
 case I used for this is ClassTest.testGetSimpleName() here:

 https://github.com/penberg/malva/blob/master/src/malva/java/lang/ClassTest.java

 The patch is OK.

 I'm not sure about this bit, but I can live with it:
 
 No need to live with it, I'll fix it up and resend.

This is truly weird.  The gcj patch says:

2008-05-22  Andrew Haley  a...@redhat.com

PR libgcj/35020
* java/lang/Class.java (getSimpleName): Import from GNU Classpath.

http://gcc.gnu.org/ml/java-patches/2008-q2/msg00016.html

There's a complex thread of replies to that.  Still, I'm pretty
sure the current gcj version is right.

Andrew.

Re: Future blog

[Pekka Enberg]

On Wed, Dec 8, 2010 at 2:03 PM, Andrew Haley a...@redhat.com wrote:
 No need to live with it, I'll fix it up and resend.

 This is truly weird.  The gcj patch says:

 2008-05-22  Andrew Haley  a...@redhat.com

        PR libgcj/35020
        * java/lang/Class.java (getSimpleName): Import from GNU Classpath.

 http://gcc.gnu.org/ml/java-patches/2008-q2/msg00016.html

 There's a complex thread of replies to that.  Still, I'm pretty
 sure the current gcj version is right.

I didn't check gcj code but lifted the copy from JamVM. The issues is
bit weird for sure as it's been ongoing for ages now:

http://www.mail-archive.com/classpath-patc...@gnu.org/msg10757.html

http://draenog.blogspot.com/2009/03/i-read-with-interest-jeroens-recent.html

In any case, the test case I mentioned passes with OpenJDK and fails
with Classpath CVS unless I apply the patch I sent.

Pekka

Re: Future blog

[Andrew Haley]

On 12/08/2010 12:09 PM, Pekka Enberg wrote:
 On Wed, Dec 8, 2010 at 2:03 PM, Andrew Haley a...@redhat.com wrote:
 No need to live with it, I'll fix it up and resend.

 This is truly weird.  The gcj patch says:

 2008-05-22  Andrew Haley  a...@redhat.com

PR libgcj/35020
* java/lang/Class.java (getSimpleName): Import from GNU Classpath.

 http://gcc.gnu.org/ml/java-patches/2008-q2/msg00016.html

 There's a complex thread of replies to that.  Still, I'm pretty
 sure the current gcj version is right.
 
 I didn't check gcj code but lifted the copy from JamVM. The issues is
 bit weird for sure as it's been ongoing for ages now:
 
 http://www.mail-archive.com/classpath-patc...@gnu.org/msg10757.html
 
 http://draenog.blogspot.com/2009/03/i-read-with-interest-jeroens-recent.html
 
 In any case, the test case I mentioned passes with OpenJDK and fails
 with Classpath CVS unless I apply the patch I sent.

The patch is still OK.  :-)

Andrew.

Re: Future blog

[Mario Torre]

Il giorno mer, 08/12/2010 alle 09.26 +, Gary Benson ha scritto:
 Dr Andrew John Hughes wrote:
  On 23:06 Tue 07 Dec, Mark Wielaard 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.
 
 Seriously?  There's no reason anybody needs to be using CVS these
 days.
 
 Cheers,
 Gary
 

Nah, no need for version control system at all, Real Hackers(TM) append
a timestamp to the file names :)

But seriously, let's go to hg soon I really like the idea.

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/

Re: Future blog

[Brian Jones]

On Wed, Dec 8, 2010 at 6:49 AM, Andrew Haley a...@redhat.com wrote:
 On 12/08/2010 11:44 AM, Brian Jones wrote:

 I've only recently gone from svn to git and honestly git is freaking
 awesome sauce.

 I'm pretty sure what you are missing is how much nicer having local
 branches can be for local development.  The cvs way would be
 multiple checkouts, and a lot of manual diffing and merging.

 If Classpath were on svn at least then you could use git svn as a
 contributor with ease.  But yea, git and github are pretty sweet.

 You seem to be assuming the rest of us don't use such systems.  We do,
 every day.

 Please don't top-post.

Oh okay, as long as you'll admit any dvcs is better than cvs for
contributors, I suppose I can post in this way.

Brian

Re: Future blog

[Mario Torre]

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.

I really like those tools because they give you context around the
patch, and it's easier for the reviewer, with just a very small overhead
to the developer.

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/

Re: Future blog

[Andrew Haley]

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.

Andrew.

Re: Future blog

[Andrew Haley]

On 12/08/2010 01:23 PM, Mario Torre wrote:
 Il giorno mer, 08/12/2010 alle 13.03 +, Andrew Haley ha scritto:
 On 12/08/2010 12:57 PM, Mario Torre wrote:

 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 don't think they introduce any other overhead than preparing the patch
 itself. You just post the patch via mercurial directly rather than via
 first a mailing list (and mercurial takes care of sending the mail to
 the patches list), and it makes line by line review easier, so this is
 no obsession.
 
 If you think this is overkill, because the number of patches we have to
 review is pretty limited, then this is a different issue and then I may
 agree with you.

I use webrevs all the time.  I use patch mails all the time.  I use
Mercurial all the time.

It's not that I don't understand how all this works, so you don't need
to explain.  I just don't agree with you.  I prefer simple tools.

Andrew.

Re: Future blog

[Dr Andrew John Hughes]

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
 gnu_and...@member.fsf.org 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
 gnu_and...@member.fsf.org 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
 gnu_and...@member.fsf.org 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's easier for someone else to
  create a forked lower-quality copy that accepts unreviewed patches is
  not a good motivation IMHO.
 
 I hope you don't mean this:
 
 https://github.com/penberg/classpath
 
 because it's (a) not a fork (it's queue of patches I want to feed to
 mainline) and (b) I don't merge unreviewed patches (I reviewed them
 myself).
 

No, I didn't mean that specifically, but your blog gave the impression
that an advantage to Mercurial was that you could avoid the main repository.
Sure, you can commit locally in Mercurial where you can't in 

Re: Future blog

[Dr Andrew John Hughes]

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 want to spend the time doing it, feel free from my point
of view.  Just make sure all that history is preserved.

 Thanks,
 
 Mark
 
 

Thanks,
-- 
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

[Dr Andrew John Hughes]

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

[Dr Andrew John Hughes]

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 a...@redhat.com 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

[Dr Andrew John Hughes]

On 08:16 Wed 08 Dec , Pekka Enberg wrote:
 On Wed, Dec 8, 2010 at 1:53 AM, Dr Andrew John Hughes
 gnu_and...@member.fsf.org 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[2]: Future blog

[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 :(

Regards.

Wed, 8 Dec 2010 13:32:20 +0200 Pekka Enberg penb...@kernel.org:

 On Wed, Dec 8, 2010 at 1:13 PM, Andrew Haley a...@redhat.com 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:
  ...

Re: Re[2]: Future blog

[Dr Andrew John Hughes]

2010/12/8 Ivan Maidanski iv...@mail.ru:
 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 penb...@kernel.org:

 On Wed, Dec 8, 2010 at 1:13 PM, Andrew Haley a...@redhat.com 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!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath

Future blog

[Mark Wielaard]

Hi all,

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.
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. 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.)

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.
 
Opinions? Suggestions? Flames?

Thanks,

Mark

Re: Future blog

[Mario Torre]

Il giorno mar, 07/12/2010 alle 23.06 +0100, Mark Wielaard ha scritto:
 Hi all,
 
 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.
 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. 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.)
 
 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.
  
 Opinions? Suggestions? Flames?
 
 Thanks,
 
 Mark
 
 

Hi Mark,

the post is definitely nice and I also completely agree on all points.

Just quoting here what I wrote on the #classpath channel, I feel very
guilty because despite I read all the GNU Classpath mails I never
reply...

My last two years had very little free time and most of it went to
OpenJDK but I definitely agree with what Pekka wrote.

Hopefully this new project (IcedRobot for the interested parties) will
make us contribute more to GNU Classpath again as well.

I don't know if GNU Classpath should still be a cleanroom implementation
of the jdk class library though, as there are many areas that are just
difficult to make it right like the last decimal format code (and btw, I
spent I don't know how much time on this thing and it still doesn't work
100% right).

Those could just benefit from a good out of the box implementation like
the jdk; also, the OpenJDK code is free now and will always be like
that, there's no way back and the effort of maintaining OpenJDK code
ourselves if Oracle decides to screw up things are still less than
writing the missing part of GNU Classpath to make it to the same level
anyway.

It's a tricky situation...

Anyway, let's make the two things you proposed.

And I would give my +1 to migrate to mercurial ASAP.

This is sane!

And then we'll make GNU Classpath shine again :)

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/

Re: Future blog

[Dr Andrew John Hughes]

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: Future blog

[Pekka Enberg]

On Wed, Dec 8, 2010 at 1:53 AM, Dr Andrew John Hughes
gnu_and...@member.fsf.org 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.

Pekka

Re: Future blog

[Pekka Enberg]

On Wed, Dec 8, 2010 at 1:53 AM, Dr Andrew John Hughes
gnu_and...@member.fsf.org wrote:
 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.

I hope my inaccuracies didn't get into the way of the overall point.

On Wed, Dec 8, 2010 at 1:53 AM, Dr Andrew John Hughes
gnu_and...@member.fsf.org wrote:
 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.

Sorry about that. It looked abandoned last time I checked it out but I
guess I wasn't looking hard enough.

On Wed, Dec 8, 2010 at 1:53 AM, Dr Andrew John Hughes
gnu_and...@member.fsf.org 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.

On Wed, Dec 8, 2010 at 1:53 AM, Dr Andrew John Hughes
gnu_and...@member.fsf.org 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.

 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.

On Wed, Dec 8, 2010 at 1:53 AM, Dr Andrew John Hughes
gnu_and...@member.fsf.org 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's easier for someone else to
 create a forked lower-quality copy that accepts unreviewed patches is
 not a good motivation IMHO.

I hope you don't mean this:

https://github.com/penberg/classpath

because it's (a) not a fork (it's queue of patches I want to feed to
mainline) and (b) I don't merge unreviewed patches (I reviewed them
myself).

 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.

Again, I have nothing against patch review and discussion. My other
point of patches needing more swift attention has nothing to do with
my point about modern tooling.

 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