Re: Future blog

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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_andrew@xxxxxxxxxxxxxx> 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 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
> 




[Index of Archives]     [Linux Kernel]     [Linux Cryptography]     [Fedora]     [Fedora Directory]     [Red Hat Development]

  Powered by Linux