Re: classpath-0_92-branch created test release tar.gz dist available
On Sat, 2006-07-29 at 15:03 +0200, Mark Wielaard wrote: Hi, On Fri, 2006-07-28 at 01:40 +0200, Mark Wielaard wrote: We now finally have a branch for 0.92. classpath-0_92-branch (and the branch point is tagged as classpath-0_92-branch-point). Paul reminded me to activate the future release script on builder. For those wanting a tar.gz dist to test these are now available at: http://builder.classpath.org/dist/ classpath-future-release-latest.tar.gz classpath-generics-latest.tar.gz (There is no separate generics-release branch, as Andrew said we will just use the normal generics branch for the release dist.) And after more than a week of extra testing and fixing some smaller regressions I think it is finally ready. If you know of anything really, really bad which should prevent the release you have to speak up quickly. There will most likely only be some documentation changes going onto the branch before we will push it out officially tomorrow. I just kicked the autobuilder to restart building the release and generics branches so the two tar.gz files mentioned above should be refreshed in a couple of hours and be almost identical to the final versions. Apologies to everybody that worked hard on things that didn't make it onto the branch this time. But we need to keep some new cool improvements for the next one! :) Cheers, Mark
ANN: GNU Classpath 0.92 Bling! Bling! released
. It introduces a dependency on the Mozilla plugin support headers and libraries. * New java implementations of png and gif imageio readers and writers. * A tools.texinfo document has been created and now includes documentation about: * appletviewer * gcjwebplugin * jarsigner * keytool * Several new tools are now included: * appletviewer * jar * native2ascii * serialver * keytool * jarsigner A new configure option --enable-tool-wrappers causes wrapper binaries to be built for VMs that support the JNI Invocation API. * javax.sound.midi providers have been added to read and write standard MIDI files. * A javax.sound.sampled .au and .wav file readers have been added. * New Java Virtual Machine Tool Interface header, jvmti.h. * AWT peers for X Windows based on Escher (a pure java X protocol implementation) have been added. So far it supports AWT 1.1 style Graphics, image loading via ImageIO (PNG, GIF and BMP images in this release), top level components as well as mouse and keyboard input. It is capable of running many Swing applications. Graphics2D and AWT widgets are not yet supported with this peer set. * GConf based util.peers backend (see the --enable-gconf-peer and --enable-default-preferences-peer configure options). * Support for batch importing trusted certificates for use with ssl connections (see script/import-cacerts.sh). * NIO scatter-gather channel support. Runtime interface changes: * A new class, VMURLConnection, is used to implement URLConnection.guessContentTypeFromStream. The reference implementation uses libmagic (and falls back to doing nothing if libmagic is not available). * The method gnu.java.io.PlatformHelper.toCanonicalForm() has been replaced with a JNI implementation of VMFile.toCanonicalForm() for GNU/Posix systems. * A new class, VMRuntimeMXBeanImpl, is used to implement the low-level support of the runtime management bean. VMs should use it to supply the input arguments and start time of the VM. In addition, one of sun.boot.class.path or java.boot.class.path should be defined by the VM to support the optional boot class path access functionality. * The Unsafe class was moved back to the place expected by the JSR 166 reference implementation. We've also added a couple other new VM classes to support the JSR 166 code -- sun.reflect.Reflection and sun.reflect.misc.ReflectUtil. * Another new class, VMClassLoadingMXBeanImpl, is used to implement the low-level support of the class loading management bean. VMs need to supply it with information about how many classes are currently loaded, how many have been unloaded and whether verbose class loading output is on or off. Provision should also be made for the latter to be toggled at runtime. * VMThreadMXBeanImpl is used to implement the low-level support of the thread management bean. Providing this interface requires providing a fair amount of information about threads, including optional time and contention monitoring, and instances of the new ThreadInfo class in java.lang.management. getState() has also been added to the VMThread interface; this is required by the bean as well as java.lang.Thread. * VMMemoryMXBeanImpl is used to implement the low-level support of the memory management bean. Providing this interface requires providing information about the levels of heap and non-heap memory, and the number of objects eligible for garbage collection. * VMCompilationMXBeanImpl is used to allow for optional compilation time support for Just-In-Time compilers. * VMMemoryPoolMXBeanImpl is used to implement the low-level support of the memory pool beans. Providing this interface requires providing memory usage statistics for each supported bean. * VMManagementFactory provides the names of the memory pools, memory managers and garbage collectors maintained by the virtual machine. These are used to create the beans by the ManagementFactory. * VMMemoryManagerMXBeanImpl and VMGarbageCollectorMXBeanImpl provide low-level support for memory managers (including the specific subclass of garbage collecting memory managers). The interfaces for these require no more than enumerating the number of collections and the time spent (for garbage collectors) and a relationship to the memory pools (for all), along with a validity check. The following people helped with this release: Andreas Tobler, Andrew John Hughes, Anthony Balkissoon, Anthony Green, Archie Cobbs, Audrius Meskauskas, Carsten Neumann, Casey Marshall, Chris Burdess, Christian Thalinger, C. Scott Marshall, Dalibor Topic, David Gilbert, Francis Kung, Gary Benson, Henrik Gulbrandsen, Ingo Proetel, Ito Kazumitsu, Jeroen Frijters, Jim Huang, Kazuya Ujihara, Keith Seitz, Kyle Galloway, Lillian Angel, Mario Torre, Mark Wielaard, Martin Platter, Matthew Burgess, Matthew Wringe, Matt Wringe, Michael Barker, Miriam Schuster, Olivier Jolly, Paul Jenner, Raif S. Naffah, Robert
Re: glibj-generics-latest.zip corrupt?
Hi Stuart, On Fri, 2006-08-11 at 10:56 -0400, Stuart Ballard wrote: I finally got around to investigating why the Japi generics comparisons aren't happening, and it appears to be because glibj-generics-latest.zip is not a valid zipfile and hasn't been for some time (it's been a long time since we had a successful -generics comparison run). Anyone have any ideas why this should be or how to fix it? Oops. We were cleaning up temporary build dirs to safe some space on builder. We shouldn't clean before copying the glibj.zip, so people can actually download it. Fixed. Cheers, Mark
A wonderful group of people
Hi all, The last release was the best release ever (as always!). I am always amazed how smoothly our development process is and how we seem to push out increasingly cooler code each and every time. Especially considering we have not all seen each other face-to-face. If you are curious who some of the other hackers are take a look at: http://www.klomp.org/mark/classpath/Classpath-08-06.jpg This features just a fraction of our hackers: http://www.klomp.org/mark/classpath/GNUClasspath-by-numbers.jpg Aaron M. Renn (1) Alex Lancaster (14) Andreas Tobler (3) Andrew Cowie (18) Andrew Haley (40,64) Andrew John Hughes (31) Andrew Overholt (38) Andy Walter (49) Anthony Balkissoon (45) Anthony Green (34) Archie Cobbs (44) Arnaud Vandyck (5,28) Audrius Meskauskas (32) Brian Jones (2) Bryce McKinlay (22) Casey Marshall (51) Chris Burdess (30) Chris Gray (66) Christian Thalinger (33) Dalibor Topic (37,69) David Gilbert (42) Egon Willighagen (52) Fernando Nasser (25) Francis Kung (48) Gary Benson (43,24) graydon hoare (20) Grzegorz B. Prokopski (36,62) Ingo Proetel (35) Jeffrey Morgan (54) Jeroen Frijters (29,61) Jim Huang (8) Jim Pick (7,63) Jochen Hoenicke (19) John Keiser (12) Keith Seitz (23) Lillian Angel (56) Mario Torre (53) Mark Wielaard (10,55,60) Michael Koch (47) Nic Ferrier (4) Patrik Reali (13,70) Ranjit Mathew (17) Robert Lougher (26,59) Robert Schuster (11,57) Roman Kennke (41) Sascha Brawer (6,67) Stephane Meslin-Weber (16,65) Steven Augart (50) Stuart Ballard (15) Sven de Marothy (46,27) Thomas Fitzsimmons (21) Tom Tromey (9,39,68) Wolfgang Baer (58) Obviously this is just a small selection of all the contributors. The FSF records for GNU Classpath list more than 120 individuals and/or company contributors. We didn't have pictures of everybody. Please do send me one if you are missing! Cheers, Mark
Re: New news about an OpenSource Sun Java
On Tue, 2006-08-15 at 18:52 +0200, Audrius Meskauskas wrote: Ha, Sun doesn't have rights to some elements such as the software to render fonts on a screen, so there will be proprietary modules that accompany the open-source software. We will see soon that kind of rights do they have on all omg.org.*. Why not to release under GPL, taking these classes from us? Yes, it seems like it would be good to help them out whenever we can. I am cautiously optimistic that Sun might actually be able to do the right thing in the long term. On the other hand it is much too early to really say anything concrete about their plans since it is all so vague. We might end up with just promises, another incompatible license, and chunks of proprietary closed binaries needed to get a working system. Tom posted a very informative blog about it all which is a must read: http://tromey.com/blog/?p=262 Thanks for that summary Tom! Cheers, Mark
Re: Accessibility crash
Hi Mario, On Wed, 2006-08-16 at 19:26 +0200, Mario Torre wrote: No, but I have incorrectly reported it as crash, infact it hangs, so I guess is a deadlock somewhere. Someone has other ideas about the cause? Some runtimes (cacao, jamvm) will print a stacktrace of all running threads when they receive a SIGQUIT (normally ctrl-\ in your terminal). That is, if they haven't been locked up completely. Cheers, mark signature.asc Description: This is a digitally signed message part
Re: slow mailinglists
On Sat, 2006-08-19 at 19:01 +, [EMAIL PROTECTED] wrote: Seems the mailinglists are really slow atm. I am trying to figure out why. It seems it is something between gnu.org and developer.classpath.org holding up things. So don't be surprized if your messages take a while to arrive. Fixed. Somehow mailman on developer.classpath.org had stopped processing new messages. No message should be lost. They were just a little delayed. Cheers, Mark signature.asc Description: This is a digitally signed message part
firstNonNullClassLoader for jamvm
Hi,
GNU Classpath CVS needs a new VMClassLoader.firstNonNullClassLoader()
method. Here is a quick and dirty implementation (based on
getCallerFrame()) which works for me.
I have also installed this temporarily on builder.classpath.org to get
mauve results again. We will see how well it does soon :)
Cheers,
Mark
Index: lib/gnu/classpath/VMStackWalker.java
===
RCS file: /cvsroot/jamvm/jamvm/lib/gnu/classpath/VMStackWalker.java,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 VMStackWalker.java
--- lib/gnu/classpath/VMStackWalker.java 5 Sep 2005 00:02:35 - 1.1.1.1
+++ lib/gnu/classpath/VMStackWalker.java 20 Aug 2006 21:22:50 -
@@ -95,5 +95,11 @@
* version of this method.
*/
public static native ClassLoader getCallingClassLoader();
+
+ /**
+ * Walk up the stack and return the first non-null class loader.
+ * If there aren't any non-null class loaders on the stack, return null.
+ */
+ public static native ClassLoader firstNonNullClassLoader();
}
Index: src/natives.c
===
RCS file: /cvsroot/jamvm/jamvm/src/natives.c,v
retrieving revision 1.17
diff -u -r1.17 natives.c
--- src/natives.c 28 Jun 2006 21:16:08 - 1.17
+++ src/natives.c 20 Aug 2006 21:22:50 -
@@ -548,6 +548,23 @@
return ostack;
}
+uintptr_t *firstNonNullClassLoader(Class *clazz, MethodBlock *mb, uintptr_t *ostack) {
+uintptr_t *loader = NULL;
+Frame *last = getExecEnv()-last_frame-prev;
+Class *class;
+
+while (loader == NULL) {
+if((last-mb == NULL (last = last-prev)-prev == NULL) ||
+ (last = getCallerFrame(last)) == NULL)
+return NULL;
+class = last-mb-class;
+loader = class ? CLASS_CB(class)-class_loader : NULL;
+}
+
+*ostack++ = loader;
+return ostack;
+}
+
uintptr_t *getClassContext(Class *class, MethodBlock *mb, uintptr_t *ostack) {
Class *class_class = findArrayClass([Ljava/lang/Class;);
Object *array;
@@ -1149,6 +1166,7 @@
{getClassContext, getClassContext},
{getCallingClass, getCallingClass},
{getCallingClassLoader, getCallingClassLoader},
+{firstNonNullClassLoader, firstNonNullClassLoader},
{NULL, NULL}
};
Re: Bringing License arguments to Sun
Hi Wes, On Mon, 2006-08-21 at 13:53 -0500, Wes Felter wrote: If One TCK is so important, let me propose a semi-heretical idea: don't open it. Certainly the 400 JVM developers should be able to run the TCK, but it's not clear that they need to distribute modified versions. (Of course, they could still submit bug fixes and such to the TCK maintainers.) I don't think the Linux distros need to distribute the TCK either, so their OSI or die policy doesn't appear to affect the TCK. Of course the Linux distros need it! One of the great strenghts of distributions is their ability to run the testsuite for all packages they build. And to give their users the power to repeat the build process and do their own checking of the results. It is a critical part of quality control. So when you build your deb/rpm/etc (possibly with distro specific patches) you run the testsuite and fail if some tests don't give clean results. That is how GCC for example works. There are even distros that only ship (easily buildable) source code so as to optimize any binary for your personal system. Then it is even more important that the user also gets the testsuites to make sure their special customized build on their own hardware is perfect. And it might very well be that to do that you have to adapt, modify and hack the testsuite to run and build in your particular packaging environment (and run it non-interactively). Don't forget that free software breaks down the artificial barrier between users and developers. Everybody is a core library, runtime, compiler, package, etc hacker now. So everybody should also take the responsibility and run any testsuites. Your users will demand it from you. Cheers, Mark
Sorry about the builder breakage
Hi, Those of you following the classpath-testresults mailinglist might have gotten lots of failure messages. That was my fault. I somehow managed to remove the g++ package while trying to update the gcj package. Everything should be fixed now. At the same time lists.gnu.org got trapped into some sort of spam/backhole/rbl thing which prevented some messages to arrive. Please do disregard any failure messages send today and if you are using some rbl to block and bounce email then please check that mailman hasn't auto-unsubscribed you because of that (that is only for the cvs-classpath, bug-classpath and classpath-testresults lists, the main classpath and classpath-patches lists are currently handled by developer.classpath.org which should be fine). Cheers, Mark
Re: Bootstrapping GNU Classpath on Fedora Core 5
On Sat, 2006-09-02 at 14:32 -0600, Tom Tromey wrote: Paul == Paul Jenner [EMAIL PROTECTED] writes: Paul IMHO the INSTALL file in the distribution should contain enough detail Paul on requirements for people to be able to build. I'll take a look at Paul updating that if necessary and maybe compare notes with you offline Paul Alexander? Yeah, that would be handy. Updating it for all the distros when things change may be a bit painful, but it is worth trying. Robert added the package names needed on Debian to the developer wiki: http://developer.classpath.org/mediation/ClasspathFirstSteps#head-ef627d3b855ba73a11250a2b1fd9a51af45348c8 It would probably be a good idea to add the development package names for the major GNU/Linux distributions to the INSTALL file. Cheers, Mark
[Fwd: DaCapo Benchmark Suite and Paper]
Hi, For those that haven't seen it. There is a new release of the DaCapo Benchmark Suite and a paper describing perfromance evaluation and benchmarking methodologies. The suite itself is a collection of real world, free software programs and datasets. http://www.dacapobench.org/ Cheers, Mark ---BeginMessage--- The DaCapo research group is pleased to announce a new beta release of the DaCapo benchmark suite, an accompanying set of performance evaluation methodologies for dynamically compiled languages [Blackburn et al., OOPSLA 2006], and mailing lists for community participation and feedback. All are available at http://www.dacapobench.org. The DaCapo benchmark suite is a set of 11 non-trivial, real-world, open source Java benchmarks. This release contains numerous substantial improvements over earlier beta releases of the suite, including new, larger benchmarks and a greatly improved harness. We encourage researchers and developers from industry and academia working with Java to use the DaCapo suite and apply the methodologies presented in the accompanying paper (http://www.dacapobench.org/dacapo-oopsla-2006.pdf). The paper recommends performance evaluation and benchmarking methodologies for dynamically compiled languages, describes and analyzes the suite, and critiques the current state of measurement methodology in the field. The web site also contains a link to a companion 30-page technical report which includes comparative data for SPEC benchmarks. The suite and paper represent the culmination of five years of work from around twenty individuals across eight institutions. We anticipate that this will be the final beta release. Enjoy! Steve Blackburn, on behalf of the DaCapo research group (http://www-ali.cs.umass.edu/DaCapo/) - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Jikesrvm-researchers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers ---End Message--- signature.asc Description: This is a digitally signed message part
Re: A question @Mark Wilaard (and other developer)
Hi Patrick, On Sun, 2006-09-03 at 13:11 +, theUser BL wrote: Have a look at http://forums.java.net/jive/thread.jspa?threadID=18036tstart=0 there I have written a qustion at Mark and other developers. It would be nice and I would be happy, if you answer it. Seems you need to have to register for some sort of account on that site to post there, but feel free to quote or redistribute my response if you want. I cannot possibly hope to speak for all GNU Classpath developers since there are just too many and GNU Classpath is really a community of communities, lots of individuals, organizations and projects working together for various reasons. But I think you are right that we are pretty flexible and accommodating. The common theme in the last 8 years has been cooperation and respect for each others work. This also extends to licenses, anything upward compatible with the GPL seems fine with the community. So you are also right that either the GNU Classpath license, GPL plus some exception, GPLv2 or v3, LGPL, BSD or MIT/X would all encourage cooperation between groups. Non-GPL compatible licenses seem to fragment the community and nobody wants to see an incompatible, proprietary fork of java. Sun has in the past chosen to use and create licenses like SISSL and CDDL, which some say are explicitly designed to be GPL-incompatible so as to not work together with the larger GNU/Linux community. Lets hope they are sincere in wanting to work with the existing communities. As soon as there is code available under a friendly license I am sure we will see some sort of cooperation between the communities. But no code is available atm, no license has been chosen and it isn't clear whether Sun needs or wants help from the community with code that we can provide for them to create a large free software platform together. Cheers, Mark
Re: Using jedit 4.2 with Gnu Classpath
Hi Alexander, On Sun, 2006-09-03 at 18:46 +0300, Alexander Shopov wrote: I think that I have successfully installed GNU Classpath from CVS HEAD on my Fedora Core 5 box. I have also correctly set the environmet variables LD_LIBARY_PATH CLASSPATH. I am trying to use jedit 4.2 with it. This link claims that it it mostly usable. http://developer.classpath.org/mediation/FreeSwingTestApps#head-2593845ab871285a8f9bf5309a5c9523e6a9f460 jedit 4.2 was tested against GNU Classpath 0.92, and should work. I can successfully install jedit 4.2 from the install jar file. gij -jar jedit42install.jar (The only problem is that there is no text in the text boxes that apppear, for example the one for GPL). This indicates you are not using gij with GNU Classpath 0.92. gcj/gij needs to be recompiled itself to use the latest GNU Classpath version. GCC from svn has this integrated, but you need to recompile all of gcc to use it. Only some runtimes, like jamvm or cacao, work out of the box with a self-compiled core library set. Could you try one of those? If you rather work with a prepackaged distribution then Fedora Core 6 test 3 (out this week I believe) does come with a gcj/gij including GNU Classpath 0.92 done by Thomas Fitzsimmons and Debian experimental has a gcj/gij package based on 0.92 done by Mathias Klose. Cheers, Mark
Re: [Fwd: DaCapo Benchmark Suite and Paper]
Hi Dalibor, On Mon, 2006-09-04 at 16:26 +0200, Dalibor Topic wrote: For those that haven't seen it. There is a new release of the DaCapo Benchmark Suite and a paper describing perfromance evaluation and benchmarking methodologies. The suite itself is a collection of real world, free software programs and datasets. http://www.dacapobench.org/ Great! Many thanks to Steve and the DaCapo team for putting the work into it. Could this go on builder.classpath.org? We looked at it but builder is a shared, multi-user machine. Although it is great as an autobuilder and tester for various things it isn't great for running benchmarks. We would need a more dedicated machine for benchmarking to get reliable/comparable results. Note that the cacao hackers do have dacapo setup as part of tgolem: http://www.complang.tuwien.ac.at/cacaojvm/tgolem/ Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: headless mode available?
Hi, On Mon, 2006-09-11 at 00:52 -0400, Martin Cordova wrote: Is it possible with latest classpath libs to use graphic/image APIs in headless mode?. I would like to run some JFreeChart based code on a text-mode server (shared XOrg libraries are installed). Not at the moment. It does work semi-headless when run with Xvfb. Debian has a utility script called xvfb-run which makes running under Xvfb really easy. That is what we currently use on our autobuilder/tester to verify graphics/awt. Cheers, Mark
Re: Moving developer.classpath.org server
Hi Jim, On Thu, 2006-10-05 at 17:13 -0700, Jim Pick wrote: Okay, the server has moved. That went very smoothly. If this email gets through, then I think all is well. :-) Everything looks fine. And the new setup feels much more responsive. Especially the wiki http://developer.classpath.org/mediation/ which used to be a bit sluggish seems to fly now :) Thanks, Mark signature.asc Description: This is a digitally signed message part
Re: glibj-generics-latest.zip on builder old?
Hi Stuart, On Tue, 2006-10-31 at 20:05 -0500, Stuart Ballard wrote: On http://builder.classpath.org/dist/, glibj-generics-latest.zip is dated Oct 18th as opposed to all the other files including classpath-generics-latest.tar.gz and glibj-latest.zip which are dated Oct 31st as expected. Is something up with the generics build causing it to fail to produce an updated zip? Yes, according to classpath-testresults starting Oct 18th we have: http://article.gmane.org/gmane.comp.java.classpath.testresults/2667 6267 problems (1 error, 6266 warnings)make[1]: *** [compile-classes] Error 255 make[1]: Leaving directory `/home/cpdev/Nightly/generics/build/lib' make: *** [all-recursive] Error 1 Unfortunately the large number of warnings obscure the 1 error. Looking through the log it is: 1729. ERROR in ../../classpath/java/util/EnumSet.java (at line 252) return copyOf((EnumSetT) other); ^^ The method copyOf(EnumSetT) is ambiguous for the type EnumSetT This is why Andrew's hard work with the generics merge the other day didn't result in a wonderfully huge Japi diff email... Sometimes huge japi diff emails are also caught by mailman as way too big an improve to be true :) Cheers, Mark
Re: glibj-generics-latest.zip on builder old?
On Fri, 2006-11-03 at 10:12 -0500, Stuart Ballard wrote: On 11/1/06, Mark Wielaard [EMAIL PROTECTED] wrote: Looking through the log it is: 1729. ERROR in ../../classpath/java/util/EnumSet.java (at line 252) return copyOf((EnumSetT) other); ^^ The method copyOf(EnumSetT) is ambiguous for the type EnumSetT So do we reckon this is a Classpath bug or an ecj issue? Andrew, presumably -generics builds for you - how does your ecj version compare to the one on builder? This seems to have been fixed now. Although I am not sure how that happened precisely. The ecj version used on builder is: Eclipse Java Compiler 0.722, 3.3.0 milestone-3 Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: glibj-generics-latest.zip on builder old?
Hi Andrew, On Tue, 2006-11-07 at 09:11 +, Andrew John Hughes wrote: Don't know if my other post reached the list or not (I can't see it in my archives), but the problem is that there are two copyOf methods: copyOf(EnumSetT) copyOf(CollectionT) where the latter calls the former, if an instanceof EnumSet succeeds. But that is good code isn't it? Or is there a reason the compiler refuses it? Things still seem to be broken on builder. I'm guessing 3.1.2 is too old, as problems with the java.util.concurrent stuff seems to have been reintroduced I upgraded the ecj on builder to v_677_R32x, 3.2.1 (ecj-bootstrap-gcj_3.2.1-3_i386.deb) Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: glibj-generics-latest.zip on builder old?
Hi Stuart, On Tue, 2006-11-07 at 08:38 -0500, Stuart Ballard wrote: On 11/7/06, Mark Wielaard [EMAIL PROTECTED] wrote: Things still seem to be broken on builder. I'm guessing 3.1.2 is too old, as problems with the java.util.concurrent stuff seems to have been reintroduced I upgraded the ecj on builder to v_677_R32x, 3.2.1 (ecj-bootstrap-gcj_3.2.1-3_i386.deb) Part of the issue is Japitools aborting entirely part way through Japizing when certain kinds of corrupt class files are encountered. Work on fixing this is in progress. Ah, that would explain why whole packages were disappearing from the comparison. Thanks for working on Japitools. I wish more projects would use it when they do new releases to get a good overview of compatibility between releases. Do the zip files as published at http://builder.classpath.org/dist/ work correct for Japitools now? Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: Java Is FREE!
On Mon, 2006-11-13 at 15:54 +0900, [EMAIL PROTECTED] wrote: Java to be Freed tomorrow!! Way to go Sun! http://www.theserverside.com/news/thread.tss?thread_id=43046 http://www.javalobby.org/java/forums/t84244.html Yes. Thank you Sun! Some more links for your reading pleasure: http://blogs.zdnet.com/Burnette/?p=199 http://blogs.zdnet.com/Burnette/?p=200 And guess what they mean with following established free software community practices for licensing virtual machines and their associated libraries. Yes! They will use the GPL and the GPL+exception! Congratulations everybody, Mark signature.asc Description: This is a digitally signed message part
Re: Java Is FREE! (some real information)
Hi all, On Mon, 2006-11-13 at 09:28 +0100, Mark Wielaard wrote: On Mon, 2006-11-13 at 15:54 +0900, [EMAIL PROTECTED] wrote: Java to be Freed tomorrow!! Way to go Sun! http://www.theserverside.com/news/thread.tss?thread_id=43046 http://www.javalobby.org/java/forums/t84244.html Yes. Thank you Sun! Some more links for your reading pleasure: http://blogs.zdnet.com/Burnette/?p=199 http://blogs.zdnet.com/Burnette/?p=200 And guess what they mean with following established free software community practices for licensing virtual machines and their associated libraries. Yes! They will use the GPL and the GPL+exception! And there is some real information available now at: http://www.sun.com/software/opensource/java/ Make sure you read the FAQ which is pretty nice: http://www.sun.com/software/opensource/java/faq.jsp You will notice some really nice things like: Q: What is the Classpath exception? A: The Classpath exception was developed by the Free Software Foundation's GNU/Classpath Project (see http://www.gnu.org/software/classpath/license.html). It allows you to link an application available under any license to a library that is part of software licensed under GPL v2, without that application being subject to the GPL's requirement to be itself offered to the public under the GPL. Q: Why do you need the Classpath exception? A: If an application is distributed with an implementation of Java such as the JDK under GPL v2, that application could be subject to the requirements of the GPL that all code that is shipped as part of a Òwork based on the [GPL] programÓ also be GPL licensed. Accordingly, a GPL license exception is needed that specifically excludes from this licensing requirement any application that links to the GPL implementation. The Classpath exception accomplishes this. Without the Classpath exception, a Java SE implementation licensed under GPL v2 could not practically be distributed with non-GPL licensed Java applications. This could present a serious barrier to adoption, for example by OpenSolaris or GNU/Linux distributions if left unaddressed. Q: Why did you choose this licensing method? A: This is the licensing paradigm in common use within Free software communities such as GNU/Classpath and Kaffe for the components of a Java technology implementation including the virtual machine and class libraries. We consciously chose the same licensing method so that there would be no temptation to second guess Sun's intention to make its Java SE implementation available under a genuinely Free and open license. And please do join some of us on irc.gnu.org in #classpath we might not have answers yet for all the wonderful things the future might bring, but we can at least have a little virtual party! :) Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: Proposal for a response to SUN's announcement
Hi, On Fri, 2006-11-17 at 11:09 -0800, David Daney wrote: If an official response is deemed necessary, this one seems good. It is fairly content free, which I think is all you can have given the constraints that it is a press release *and* from a moderatly large free software project. To keep things really simple I'll install the attached patch to point to the official FSF press release and add the link to Planet Classpath for a collection of individual reactions. 2006-11-17 Mark Wielaard [EMAIL PROTECTED] * docs/www.gnu.org/newsitems.txt: Add Sun GPL news announcement. It does seem a good thing to acknowledge and thank Sun for their announcement. Cheers, Mark diff -u -r1.40 newsitems.txt --- newsitems.txt 12 Aug 2006 23:57:19 - 1.40 +++ newsitems.txt 17 Nov 2006 21:11:40 - @@ -1,3 +1,10 @@ +newsitem date=15 Nov 2006 +createlink name=FSF welcomes Sun's GPL release of Java +url=http://www.fsf.org/news/fsf-welcomes-gpl-java.html;br +createlink name=Planet Classpath url=http://planet.classpath.org/; +carries the reactions of many individual GNU Classpath developers. +/newsitem + newsitem date=09 Aug 2006 createlink name=GNU Classpath 0.92 url=announce/20060809.html
Re: Running Sun's javac on Classpath
Hi Andrew, On Tue, 2006-11-21 at 22:57 +, Andrew John Hughes wrote: Andrew Hughes did add something similar to the generics branch (but not the the trunk yet): 2006-11-13 Andrew John Hughes [EMAIL PROTECTED] * gnu/java/util/regex/RETokenNamedProperty.java: (getHandler(String)): Add support for 'all'. This patch is on HEAD too as of the weekend. Thanks, sorry I missed that. So what we need to decide now is whether we want this stuff on HEAD, I guess. Since some of the things needed are using 1.5 language additions I don't think we want it on HEAD for now. Supporting javac is clearly still a little experimental atm. But lets make it a strong goal for the release after 0.93 when we will merge the branch finally with HEAD. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: [Devjam] Java Is FREE! (some real information)
Hi Petter, On Sun, 2006-11-19 at 20:09 +0100, Petter Reinholdtsen wrote: Yes, this is great news. I believe it calls for a free java developer gathering like the one in Oldenburg a long time ago. This time with people from SUN as well as all the developers from the Classpath project cluster. :) Any volunteer to make it happen. I know a gathering is planned for FOSDEM, perhaps it could be extended and some travel sponsoring can be organized for it? Yes that makes sense. We got confirmation from the Fosdem organizers that for FOSDEM 2007 (24-25th February in Brussels, Belgium) we will have a room for 100 people and Sun.be has asked for an OpenJDK booth that the FOSDEM organization will place not too far away from that room. We have some friends at Sun now that would like to join us for Fosdem. Normally we have three themes for our Fosdem meeting (Sat afternoon, Sun morning, Sun afternoon). For this year it is probably a good idea to make those: - GNU Classpath friends - Reflection Future (Party!) - OpenJDK - Welcome to/from the community - GNU/Linux distro packaging for the new libre Java world Normally our Fosdem meeting is completely volunteer based and people come without any sponsorship. Just because it is such a hassle to make someone responsible for managing and tracking money. But if you would like to help with sponsorship and coordination that would be very nice. Cheers, Mark signature.asc Description: This is a digitally signed message part
Some downtime
I posted this on the planet already since mailing it won't help since it is about the lists being down. But better to try to post it also to the list so it hopefully reaches people when the machines come back up again. It is Thanksgiving [1] in the USA which is where the primary GNU servers are. And since machines know the most inconvenient time to die, they apparently do during such holidays. See the status info on savannah [2] (now up again), lists and fencepost still down atm. Sorry for the inconvenience. [1] http://en.wikipedia.org/wiki/Thanksgiving [2] http://savannah.gnu.org/forum/forum.php?forum_id=4685 signature.asc Description: This is a digitally signed message part
Re: Japi diffs for classpath
On Fri, 2006-11-24 at 14:03 -0500, Stuart Ballard wrote: On 11/24/06, Stuart Ballard [EMAIL PROTECTED] wrote: -Methods: 24 missing. +Methods: 21 missing. -method java.beans.beancontext.BeanContextServicesSupport.getChildBeanContextServicesListener(java.lang.Object): not implemented in classpath -method java.beans.beancontext.BeanContextSupport.deserialize(java.io.ObjectInputStream, java.util.Collection): not implemented in classpath -method java.beans.beancontext.BeanContextSupport.serialize(java.io.ObjectOutputStream, java.util.Collection): not implemented in classpath I didn't see any message on -patches that would account for these. Anyone want to take credit? David Gilbert did those yesterday (including Mauve tests) but the patches list had a little trouble. It should now be in the archive. Cheers, Mark signature.asc Description: This is a digitally signed message part
Mauve regressions 0.92/0.93-pre
Hi, We seem to be doing pretty well on regression with respect to 0.92. Here is the current list. It would be good to get this list down a bit before we branch for 0.93. The number of new passes has gone up a lot. So it looks like 0.93 will be a much better release than 0.92. - gnu.javax.swing.text.html.parser.support.Parser.Text - gnu.javax.swing.text.html.parser.support.Parser.textPreProcessor_Test Both fail with subtle differences in the result of what gets parsed. is this caused by the changes on how to handle whitespace? - java.awt.datatransfer.Clipboard.clipboardFlavors - java.awt.datatransfer.DataFlavor.flavor Failures are in cases where the representation class is one of the standard classes like java.io.InputStream. I'll look into this. - java.awt.Frame.isDisplayable2 This might be a non-deterministic test. But it seems these two checks are regularly failing: FAIL: line 59: after showing dialog [1] -- boolean passed to check was false FAIL: line 61: after showing dialog [3] -- got false but expected true - java.awt.image.IndexColorModel.getAlpha Fails with the following stacktrace: java.lang.ArrayIndexOutOfBoundsException: 99 at java.awt.image.IndexColorModel.getAlpha(IndexColorModel.java:585) at gnu.testlet.java.awt.image.IndexColorModel.getAlpha.test(getAlpha.java:76) at RunnerProcess.runtest(RunnerProcess.java:360) at RunnerProcess.runAndReport(RunnerProcess.java:415) at RunnerProcess.main(RunnerProcess.java:227) - java.awt.List.ScrollbarPaintTest PaintTests can sometimes be undeterministic, but this one seems to fail not deterministically with: FAIL: line 75: [2] -- boolean passed to check was false - java.net.ServerSocket.AcceptTimeout This one fails undeterministifcally with either: FAIL: line 44: [1] -- got 200 but expected 0 Or the following stacktrace: java.net.BindException: Address already in use at gnu.java.net.VMPlainSocketImpl.bind(Native Method) at gnu.java.net.VMPlainSocketImpl.bind(VMPlainSocketImpl.java:302) at gnu.java.net.PlainSocketImpl.bind(PlainSocketImpl.java:306) at java.net.ServerSocket.bind(ServerSocket.java:254) at java.net.ServerSocket.init(ServerSocket.java:185) at java.net.ServerSocket.init(ServerSocket.java:159) at java.net.ServerSocket.init(ServerSocket.java:141) at gnu.testlet.java.net.ServerSocket.AcceptTimeout.test(AcceptTimeout.java:41) I suspect the second is caused by the later. - java.sql.Timestamp.TimestampTest - java.text.MessageFormat.format - java.text.MessageFormat.parse - java.text.NumberFormat.UK - locales.LocaleTest These all seem to be caused by the last Decimal/NumberFormat patch. We get a couple of new passes back for it, but it would be good to investigate these failures. - javax.swing.JSpinner.DefaultEditor.propertyChange - javax.swing.JSpinner.DefaultEditor.stateChanged Similar. Both have checks fail like: FAIL: line 49: (PropertyChangeEvent) [3] -- got 88.0 but expected 88 FAIL: line 46: (ChangeEvent) [3] -- got 99.0 but expected 99 - java.util.Vector.AcuniaVectorTest Fails because it expects a NullPointerException on a v.removeAll(null) and v.retainAll(null), where the Vector v is empty. This seems a little pedantic, but might be right. - javax.swing.border.TitledBorder.getBorderInsets All results seem slightly off with this test. - javax.swing.JToolTip.setTipText Has one new check failure: FAIL: line 53: [2] -- got 2 but expected 1 - javax.swing.text.StringContent.createPosition - javax.swing.text.StringContent.getChars Not investigated yet. Anybody with some more insight into these regressions please do mail to the list. In general we seem to be doing really well compared to 0.92. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: newbie question: compiling the examples
On Sun, 2006-11-26 at 17:23 +1100, Alexander Samad wrote: On Sun, Nov 26, 2006 at 05:03:33PM +1100, Alexander Samad wrote: I have just come across classpath, I am using debian amd64. I have downloaded the current version 0.92 When I try the examples I get [...] had a bit more of a play with it and I had to add in all the *.java files to command line, once it all compiled it ran fine Great! Hope you like the examples. There is also a Makefile in the examples dir when you build from CVS that generates an examples.zip file with everything you need 9which should be installed if you run from an installation). And there is a README in the examples dir that should give you all instructions you need when doing it by hand (attached). Cheers, Mark This directory contains example programs that show how the GNU Classpath library can be used. Each example has its own package under gnu.classpath.examples and has a class Demo which contains a main() method to run that particular example. The examples can be compiled and run with gcj as follows: gcj -o swingdemo --main=gnu.classpath.examples.swing.Demo \ gnu/classpath/examples/swing/Demo.java \ gnu/classpath/examples/swing/GNULookAndFeel.java ./swingdemo Or with a traditional byte code interpreter like: gcj -C gnu/classpath/examples/awt/Demo.java gij gnu.classpath.examples.awt.Demo The installation also comes with an examples.zip archive that contains all needed resources and compiled byte code class files that can be run as follows: kaffe -classpath examples.zip gnu.classpath.examples.awt.Demo kaffe -classpath examples.zip gnu.classpath.examples.swing.Demo The jawt Demo needs some extra support library that currently needs to be build by hand. The following assumes GNU Classpath was installed in /usr/local/classpath, if you installed it somewhere else then adjust the -I and -L paths accordingly. The included Makefile.jawt is setup this way. You can invoke it with: make -f Makefile.jawt Or you can compile by hand as follows: gcj -C gnu/classpath/examples/jawt/DemoJAWT.java gcjh -jni gnu.classpath.examples.jawt.DemoJAWT -o DemoJAWT.h gcc -g -O0 -Wall -I. -I/usr/X11R6/include -L. -L/usr/X11R6/lib \ -I/usr/local/classpath/include -L/usr/local/classpath/lib/classpath \ -lX11 -ljawtgnu -shared -o libDemoJAWT.so \ gnu/classpath/examples/jawt/DemoJAWT.c You can then run the example as follows: export LD_LIBRARY_PATH=.:/usr/local/classpath/lib/classpath jamvm gnu.classpath.examples.jawt.DemoJAWT The java2d benchmarking demos include a GTK widget to measure the native speed of some basic java2d options, without the JNI overhead. You can invoke it with: make -f Makefile.java2d Or you can compile by hand as follows: gcc -g -O0 -Wall -I./gnu/classpath/examples/java2d \ -o cairobench gnu/classpath/examples/java2d/bench.c \ `pkg-config --libs --cflags gtk+-2.0` You can then run the example as follows: ./cairobench All example code is distributed under the GNU General Public License (GPL). The example icons used in some of the examples come from gnome-icon-theme version 1.2.3 and are also distributed under the GPL. All these images are stored in the directory gnu/classpath/examples/icons/. More free icons can be found in the gnome-icon-theme package: http://ftp.gnome.org/pub/GNOME/sources/gnome-icon-theme/ GNU Classpath examples are free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. GNU Classpath examples are distributed in the hope that they will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with GNU Classpath examples; see the file COPYING. If not, write to the Free Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
Re: FYI: few DecimalFormat fixes
Hi Mario, On Mon, 2006-11-27 at 03:45 +0100, Mario Torre wrote: I've fixed some of them. There are a couple of them difficult to find, though. Nice one! This not only fixed most of the regressions, but according to the autobuilder mauve run on classpath-testresults this (plus some of the other patches made yesterday) made a lot of new tests PASS. I believe we are pretty close to branching for 0.93 now. For those that want to follow at home please take a look at: http://news.gmane.org/gmane.comp.java.classpath.testresults And investigate any regressions or unexpected FAILs you see there. Thanks, Mark signature.asc Description: This is a digitally signed message part
GNU Classpath, Sun, Java, GPL, Reflections The Future
Hi all, It has been 2 weeks now since the announcement that Sun will release Java under the GPL and will adopt the classpath exception for the j2se libraries to be compatible with all our efforts. And I must say I am still recovering from the happy surprise! :) I deliberately waited a little to let it all sink in and to be able to talk to several of you and read all the reactions on Planet Classpath. And to actually see the actions of Sun. They have delivered and having spoken to several Sun people now has convinced me they are really genuine. And the FSF agrees with that. We can include any GPL+exception parts from OpenJDK in GNU Classpath if they are useful. And other GPLed parts can of course be included in other GPL-compatible Free Software projects the community is working on. We used to be really suspicious about Sun and possible code contamination (accidental copyright infringement), but all this will soon be a thing of the past. The GPL acts as a covenant between all parties. There is no fear anymore that there is any copyright infringement going on between the projects (if you do keep track of the original copyright statements of course) since they will all use the same license. And the GPL acts like a patent shield between all parties. And it seems GNU Classpath hackers are really happy about this. Sure it sucks a little to have two duplicated free code bases for the core libraries in the future. But for Sun to make their license explicitly compatible is a really big thing. And they deserve major kudos for it. This means people and projects will be able to gradually shift between the various projects, mixing and matching just what is needed to get higher compatibility, performance and features. And I do hope that will happen, just as it has happened in the past with all the projects adopting and collaborating around GNU Classpath. The way Sun did this brings a high credibility to their effort and as Jonathan Schwartz said during the presentation of OpenJDK we can now start trying to figure out how from this point on we all can work together and not duplicate efforts: http://gnu.wildebeest.org/diary/index.php?p=171 The uptake and the drive behind GNU Classpath has been enormous. Just seeing the amount of patches flow in the last 2 weeks (it looks like this announcement made people work even harder to show off how cool GNU Classpath really is!) and the quality of the code (the regressions in Mauve are really minor - down to a handfull now - compared to the huge increase in features and code since the last release) is amazing. And it seems the adoption, features, maturity and collaboration have only been increasing over the years. I have the feeling our work, and our honest open collaborative nature, is substantially responsible for Sun's change in policy. This really is your victory. And we have now been promoted from Freedom Fighters that are trying to keep a free Java path to Libre Java platform innovators that will work on equal footing with the larger Java eco-system from now on. It is impossible to predict the future (and I haven't even thought about the implications that come from the fact that Sun decided to also release JEE and JME under the GPL, completing the whole Java picture). But it is clear that the future is very bright. It is also clear that we have some commitments to the community, the various projects around GNU Classpath and the users and distros relying on our work. Sun is really trying to do this correctly and by picking their development branch (1.7) for building up the free product and community they showed that they do understand how building a developer community works. this will allow them to incorporate the community input on a product that is still shaping up instead of dumping some source code as a finished product and project. But this also means it will not be all ready at once for our own community for immediate adoption. And even after half a year when all code should be out there it will still take time and effort to adopt. I think our commitment to our community, users and projects is that we should not regress on freedom. We will provide free versions of anything that Sun won't be able to release (yet). We will not regress in coverage. All the platforms, projects and programs that run now with GNU Classpath should run in the future. And we won't regress on having fun innovating and hacking together! Which to me means we should make it easy to adopt and collaborate. We want to make it easy for people to improve together with GNU Classpath and OpenJDK by helping also the small projects with less resources to adopt the new innovation (coordinating new VM and Platform interfaces, etc.) So now the short time roadmap. We are ready for a release of 0.93 this week. We will hopefully branch tomorrow and release by Friday unless some big disaster strikes. There seems general agreement that this will be our last push before going full steam with the 1.5
Re: ASM and gnu.bytecode
Hi Tom, On Tue, 2006-11-28 at 15:42 -0700, Tom Tromey wrote: Tom Ideally we could just import the ASM sources. I thought this idea was Tom rejected, but I can't find a link. I'd like to revisit this, since Tom this is the simplest way to solve the problem. And unfortunately it seems upstream recommends this since they don't promise a stable api. sigh. The code is available from asm.objectweb.org. The license is here: http://asm.objectweb.org/license.html That looks good. I would import whatever version currently works. Later we could import newer versions, as desired, and update our code to match. What is the exact version that works with all our tools atm? I like to go over the sources once and send a report about it to the fsf licensing team so they can OK it for external inclusion (I don't foresee any issues, since it looks like a fairly stable [except for the api...] project with a known upstream). I'd import the code into classpath/tools/external (a new directory created for this purpose) and update the build scripts to match. I wouldn't rename the classes or anything like that. I would just import them using their upstream names. This is ok, I think, because the resulting classes would only end up in tools.zip -- not in glibj.zip. Users setting CLASSPATH could still have problems, but this doesn't seem like a major issue. That means we would be exactly the same as upstream so we can easily update if necessary and it won't 'pollute' the bootclasspath package space which is good. Thanks, Mark signature.asc Description: This is a digitally signed message part
Re: ASM and gnu.bytecode
Hi Andrew, On Wed, 2006-11-29 at 10:50 +, Andrew Haley wrote: I would import whatever version currently works. Later we could import newer versions, as desired, and update our code to match. What is the exact version that works with all our tools atm? Implementation-Title: ASM all classes Implementation-Version: 2.2.3 Thanks. I cannot find that as a source download. But it seems they have at least tagged their CVS with ASM_2_2_3 so we could pull the code from there. We must make sure to properly document the way someone can grab the upstream sources in case we want to pull in bug fixes later. Cheers, Mark signature.asc Description: This is a digitally signed message part
0.93 branch created
Hi, With the mauve regressions cleaned up we finally have a branch for 0.93 (tagged as classpath-0_93-branch with classpath-0_93-branch-point as marker on the trunk). So things todo before release: - sync up generics branch again. - Run some larger applications as smoke tests eclipse, jfreecharts, jedit, megamek, hsql-frontends, some applets, etc. to make sure they still run as well as they did with 0.92. Reports welcome! I tried things like our examples, SwingSet2, Java2D and RSSOwl already and things look pretty good. - Fixup any last minute regresions if found (please do that on the trunk, they will be merged onto the branch if OK - CC me on any patch that you think should go on the release [and generics] branch). - Update NEWS (please add your cool stuff!) - Release! :) http://builder.classpath.org/dist/classpath-0.93-pre.tar.gz Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: 0.93 branch created
Hi Andrew, On Sat, 2006-12-02 at 10:47 +, Andrew John Hughes wrote: Great news Mark! What's the plan for the generics branch? From this, it sounds like we keep it around until the release itself, which seems sensible (so we have a 0.93 generics release). Yes that is a good plan. And if everything goes right then that will be till Monday at the latest. I guess after that it gets synchronized with HEAD again, and then the updated branch becomes HEAD (after creating a 1.4 branch). Does that sound about right? I don't believe you can 'switch' a branch to become the trunk with CVS. So after the resync with HEAD we need to actually merge the generics-branch changes onto the trunk (which should be just one big diff because they just got synced, but watch out for those added/removed files). Cheers, Mark
Re: 0.93 branch created
On Sat, 2006-12-02 at 11:08 +, Andrew Haley wrote: OK. I'd like to have a semi-official 0.93 generics release for gcj. If we have that then gcj can go to Java 5 at the end of next week (i.e. we'll merge gcj-eclipse branch to trunk.) Cool. Yes, the plan is to push out a fairly-official classpath-generics 0.93 release together with the classpath 0.93 release. Cheers, Mark
Re: 0.93 branch created
On Mon, 2006-12-04 at 11:57 +0100, Dalibor Topic wrote: David Gilbert wrote: Maybe the exception means something to someone more familiar with this part of GNU Classpath: [error] AWT-EventQueue-2: Exception during event dispatch: [error] AWT-EventQueue-2: java.lang.AbstractMethodError: setAnchor [error] AWT-EventQueue-2:at gnu.regexp.RE.makeCharIndexed(RE.java:2086) Looks weird to me, I thought the regexp package moved to gnu.java.util.regexp ? Yes it did (so as not to clash with projects shipping the old gnu.regex code). So this is an error in code bundled with jedit. But the AbstractMethodError shouldn't happen unless it is shipping broken byte code, or there is a VM bug not resolving the method correctly. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: 0.93 branch created
Hi Tom, On Mon, 2006-12-04 at 15:52 -0500, Thomas Fitzsimmons wrote: I'm attempting to run MegaMek on cacao + classpath-0_93-branch. I see many exceptions like this: Exception during event dispatch: java.lang.NullPointerException at gnu.java.awt.peer.gtk.GtkComponentPeer.paintComponent(GtkComponentPeer.java:316) at gnu.java.awt.peer.gtk.GtkComponentPeer.handleEvent(GtkComponentPeer.java:284) at gnu.java.awt.peer.gtk.GtkPanelPeer.handleEvent(GtkPanelPeer.java:63) at java.awt.Component.dispatchEventImpl(Component.java:5749) at java.awt.Container.dispatchEventImpl(Container.java:1922) at java.awt.Component.dispatchEvent(Component.java:2833) at java.awt.EventQueue.dispatchEvent(EventQueue.java:626) at java.awt.EventDispatchThread.run(EventDispatchThread.java:85) at java.lang.VMThread.run(VMThread.java:120) and (likely as a result of these exceptions) GTK widgets aren't being painted correctly. I'm investigating... Found that already. Lifting this patch from head to the release branch now: 2006-12-03 Mark Wielaard [EMAIL PROTECTED] * gnu/java/awt/peer/gtk/GtkComponentPeer.java (paintArea): Renamed to currentPaintArea. (paintComponent): Work with local reference to currentPaintArea. (updateComponent): Likewise. (coalescePaintEvent): Set currentPaintArea. Plus some of the others we found during testing this weekend. Please retest in half an hour when I flushed all appropriate patches to the branch. Thanks, Mark signature.asc Description: This is a digitally signed message part
Re: java.lang.management.ThreadInfo
Hi, On Sun, 2006-12-03 at 21:16 +, Andrew John Hughes wrote: On Sun, 2006-12-03 at 19:40 +, Robert Lougher wrote: While implementing the ThreadMXBean stuff in JamVM I noticed a couple of problems with the ThreadInfo class. The first constructor will throw NullPointerExceptions if the lock or lockOwner is null (which it will be if the thread isn't blocked), and in several accessors the BLOCKED state check should be negated (in fact, they can be removed, as the values are right anyway). I've attached a patch. Any chance this could be fixed for 0.93? Well spotted; this is why we really need people to implement this stuff... ;) Thanks, Robert. Mark, can you commit this for 0.93? Committed as follows to trunk and 0.93 as: 2006-12-04 Robert Lougher [EMAIL PROTECTED] * java/lang/management/ThreadInfo.java (ThreadInfo): Check whether given a null lock and lockOwner. (getLockName): Switch condition. (getLockOwnerId): Likewise. (getLockOwnerName): Likewise. On the generics brach I only applied the constructor fix: 2006-12-04 Robert Lougher [EMAIL PROTECTED] * java/lang/management/ThreadInfo.java (ThreadInfo): Check whether given a null lock and lockOwner. Thanks, Mark signature.asc Description: This is a digitally signed message part
Re: 0.93 branch created
Hi David, On Mon, 2006-12-04 at 10:44 +, David Gilbert wrote: (1) The JFreeChart 1.0.3 demo. This is working pretty well. There are a couple of graphical glitches, which I'll report as bugs, but I don't think these are regressions and certainly they're not release blockers; (2) StatCVS 0.2.3. This is working well, I ran it on the Mauve CVS log file. I'll post the report shortly. (3) JEdit 4.2. Roman's HTML work has certainly improved the first impressions in JEdit, it looks really good - I was able to read through the help files, clicking hyperlinks etc. Very nice! Thanks for all this testing. Seems our little release is shaping up nicely. Also thanks for the new cvsstat reports on your blog and planet classpath. Hope the web server crash you reported wasn't caused by some bug in classpath clobbering your kernel somehow. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: 0.93 branch created
Hi Roman, On Mon, 2006-12-04 at 21:21 +0100, Roman Kennke wrote: I just tried out BeanShell GUI and it seems quite badly broken. AFAICS, this has to do with some reflection magic. Exception during event dispatch: java.lang.reflect.UndeclaredThrowableException at $Proxy3.internalFrameActivated(Unknown Source) at javax.swing.JInternalFrame.fireInternalFrameEvent(JInternalFrame.java:707) at javax.swing.JInternalFrame.setSelected(JInternalFrame.java:1664) at javax.swing.JDesktopPane.setSelectedFrame(JDesktopPane.java:267) at javax.swing.DefaultDesktopManager.activateFrame(DefaultDesktopManager.java:298) at javax.swing.plaf.basic.BasicInternalFrameUI.activateFrame(BasicInternalFrameUI.java:1754) at javax.swing.plaf.basic.BasicInternalFrameUI $BorderListener.mousePressed(BasicInternalFrameUI.java:345) at javax.swing.plaf.basic.BasicInternalFrameUI $GlassPaneDispatcher.mousePressed(BasicInternalFrameUI.java:761) at java.awt.Component.processMouseEvent(Component.java:3812) at java.awt.Component.processEvent(Component.java:3674) at java.awt.Container.processEvent(Container.java:1027) at java.awt.Component.dispatchEventImpl(Component.java:5741) at java.awt.Container.dispatchEventImpl(Container.java:1922) [...] Many of these are thrown and it basically seems to prevent the thing from working at all. I only see this when trying to work with the Class Browser in bsh, everything else seems to work perfectly. Also this only seems to happen with jamvm, not with cacao (from SVN). So I suspect a bug in jamvm, not in the class libraries. I don't have a simple testcase though. If someone is interested in tracking this down: simple try running bsh (1.3.0) jamvm -jar bsh.jar and right clicking on the jdesktop to get a popup select Class Browser and you get the above stack trace (plus some extra info). Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: FYI: Proposal for RuleBasedCollator and 1.3 completeness
Hi Mario, On Wed, 2006-12-06 at 13:18 +0100, Mario Torre wrote: This patch moves the logic to build a CollationElementIterator from RuleBasedCollator and Collator into the class CollationElementIterator itself. *This is not a fix*. Infact, actually the new Constructor just read a string out of the iterator, without any processing. But in the old code the decomposing is done, although not really in the classpath case, only in the case of libgcj. Could you explain the difference between classpath/libgcj here and how this actually helps us? Can't we use the libgcj version? This way we can declare the 1.3 completeness and I can start fixing the CollationElementIterator in just one place. I would like to have this in for 0.93, but I understand that this is not a fix... What do you think? It doesn't really add or remove functionality it seems. How is the user better of with this version than they were with the old one? If it helps you structure the code in a way that makes improving it better please do go for it. But if the functionality doesn't really change I am not sure the user will actually care which version is in 0.93 (I am not opposed to adding it though). Cheers, Mark signature.asc Description: This is a digitally signed message part
Please go nuts!
Hi, 0.93 tagged (classpath-0_93-release and generics-0_93-release), tarred and available at ftp.gnu.org (and soon your favorite mirrors): ftp://ftp.gnu.org/gnu/classpath/classpath-0.93.tar.gz ftp://ftp.gnu.org/gnu/classpath/classpath-0.93-generics.tar.gz Plus updated documentation at http://developer.classpath.org/doc/ Official announcement and release note to follow (hopefully tonight, but maybe Monday as I will be offline this weekend). Please go nuts on the trunk and/or merging the generics branch to trunk. It is probably best if Andrew posts some merge plan (do we want to do this all at once, package-for-package, resync-trunk-to-branch during a quiet period and then a full merge back-at-once, ...?) so we don't step on each others toes too much and to make this go as smooth as possible. Cheers, Mark signature.asc Description: This is a digitally signed message part
GNU Classpath 0.93 Dreamland released
community know about their plans and willingness to work with the existing free software communities. The GNU Classpath community is happy with this development and although it is too early to see what the future might bring we know we have the following commitments to our developers, users, projects and GNU/Linux distros depending on our work: - We will not regress on freedom. For anything Sun cannot release (now) under the GPL we will provide free replacements. - We will not regress on coverage. The platforms, architectures, projects and programs that run now with GNU Classpath should run in the future. - We will not regress on having fun, innovating and hacking together! We want to make it easy to adopt and collaborate. We want to make it easy for people to improve together with GNU Classpath and OpenJDK by helping also the smaller projects and platforms with less resources to adopt the new innovation (coordinating new VM and Platform interfaces) Various individual GNU Classpath hackers have made personal statements about all this (from Planet Classpath - http://planet.classpath.org/): - Mario Torre Watch out, we have changed history... http://jroller.com/page/neugens?entry=watch_out_we_have_changed - Roman Kennke First Rays of a New Rising Sun http://kennke.org/blog/?p=25 - Brian Jones Nov. 13 2006, is a notable bookmark in the history of free software http://cbj.livejournal.com/234857.html - David Gilbert On Walled Gardens http://jroller.com/page/dgilbert?entry=on_walled_gardens - Anthony Green Now that's what I call harmony... http://spindazzle.org/greenblog/index.php?/archives/43-Now-thats-what-I-call-harmonyhtml - Casey Marshall Free Java! http://metastatic.org/text/Concern/2006/11/13/107/ - Andrew Hughes Victory! Pigs Fly as Java is GPLed and javac compiles Freely http://blog.fuseyism.com/?p=18 - Dalibor Topic San i java http://robilad.livejournal.com/2056.html - Jeroen Frijters Sun Open Sourcing Java http://weblog.ikvm.net/PermaLink.aspx?guid=3620697a-52f4-4067-9afa-863b3066317b - Andrew Overholt Sun commits to GPL + Exceptioning Their Java Implementation http://overholt.ca/wp/?p=74 - Thomas Fitzsimmons The New Free Java Project http://fitzsim.org/blog/?p=13 - Mark Wielaard Collaborate http://gnu.wildebeest.org/diary/index.php?p=171 GNU Classpath, Sun, Java, GPL, Reflections The Future http://gnu.wildebeest.org/diary/index.php?p=175 - Tom Tromey Sun Frees Java http://tromey.com/blog/?p=293 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. A documentation generation framework for java source files used by the GNU project. Full documentation on the currently implementated packages and classes can be found at: http://developer.classpath.org/doc/ 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.93 can be downloaded from ftp://ftp.gnu.org/pub/gnu/classpath/ or one of the ftp.gnu.org mirrors http://www.gnu.org/order/ftp.html File: classpath-0.93.tar.gz MD5sum: ffa9e9cac31c5acbf0ea9eff9efa923d SHA1sum: 336cae589ec91a4fe212c2149c57b51dab2ca002 File: classpath-0.93-generics.tar.gz MD5sum: 9d3f5941b9fc0d8bc056344cb07a5c86 SHA1sum: 4362433a4bd985baf00a00586c355939905861ff New in release 0.93 (Dec 8, 2006) (See the ChangeLog file for a full list of changes.) * CORBA objects that exist on the same virtual machine and only are connected to another ORB are now accessed directly and no longer via network. It is the same feature that RMI implementation provides. These faster calls should be completely transparent, as the parameters are cloned, where required. Currently the direct calls are only possible for the non-deprecated objects that are connected to the ORB via POA. * The 'javah' tool has been added. It requires the ASM library (see asm.objectweb.org); it can be enabled with the --with-asm
Re: GNU Classpath 0.93 Dreamland released
Hi, On Thu, 2006-12-14 at 10:35 -0800, David Daney wrote: Mark Wielaard wrote: We are proud to announce the release of GNU Classpath 0.93 Dreamland Most excellent! Now in addition to having a version number, we have a wacky word version name to go with it. These version names are sure to bring many benefits in the future. :) But this isn't the first release with a wacky word version name. Releases 0.00 till 0.15 had only numbers. Starting with 0.16 till 0.20 only some had code names. And after the jump from 0.20 to 0.90 all had releases have had a name associated with the release. Except for the first code name, all other names were chosen in a completely undemocratic way by the release dictator. Here is the list in case you ever get into a classpath trivia quiz: 0.16 Harmony! 0.19 95% and counting 0.90 A La Mort Subite 0.91 All for One, One for All 0.92 Bling! Bling! 0.93 Dreamland Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: GNU Classpath 0.93 Dreamland released
On Fri, 2006-12-15 at 11:09 +0100, Mark Wielaard wrote: Here is the list in case you ever get into a classpath trivia quiz: 0.16 Harmony! 0.19 95% and counting 0.90 A La Mort Subite 0.91 All for One, One for All 0.92 Bling! Bling! 0.93 Dreamland I got reminded that although 0.17 didn't officially have a 'wacky word version name', it was called slightly different from the rest: 0.17 GNU Classpatchy This concludes the official GNU Classpath trivia contest roundup. Figuring out the Why behind each and every wacky word name is left as an exercise to the reader. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: [cp-patches] FYI: Add Enum.finalize()
Hi (moved to main list since I think this might be interesting for
runtime hackers),
On Tue, 2006-12-19 at 00:37 +, Andrew John Hughes wrote:
This adds the finalize() method added to Enum
in 1.6. Should fix a few JAPI errors...
Changelog:
2006-12-19 Andrew John Hughes [EMAIL PROTECTED]
* java/lang/Enum.java:
(finalize()): Implemented.
[...]
+ /**
+ * Enumerations can not have finalization methods.
+ *
+ * @since 1.6
+ */
+ protected final void finalize()
+ {
+ }
Interesting. Even though Enums should never be initialized by hand
this is something a garbage collector should be aware of. Do garbage
collectors already handle empty finalize() methods as if there was no
finalizer?
Cheers,
Mark
signature.asc
Description: This is a digitally signed message part
FOSDEM! Classpath/DevJam/OpenJDK
Hi, On Tue, 2006-12-19 at 09:19 +, Andrew Haley wrote: Petter Reinholdtsen writes: OK, we are rolling with this. The next DevJam will be during FOSDEM, 24th and 25th February 2007 in Brussels, Belgium. Those of you who are interested in joining need to put your name on URL:http://wiki.debian.org/Java/DevJam/2007/Fosdem quickly, to give us an estimate on how many will join and how much sponsoring is needed. I hope the java maintainers from all the linux distributions will show up. The discussion currently is held at #debian-java (irc.oftc.net). I've had a conversation with the organizers, and apparently this is not an attempt to replace the usual Classpath get-together, but a renaming. There will be a Classpath meeting, as usual, and you won't have to decide to go to the DevJam instead. Yes. Sorry if that was not clear. Since we wanted to have three sessions at Fosdem and had already decided those would be about GNU Classpath Friends, OpenJDK and GNU/Linux distro Packaging it made sense to officially turn this into a shared meeting. As http://wiki.debian.org/Java/DevJam/2007/Fosdem says: We are organizing a meeting which is a merger of two events and what we hope will be the start of a close collaboration of the free software community with the new Sun OpenJDK project. In the past several years there were two main events around libre java for the GNU/Linux platform. The Fosdem Escape the Java Trap event organized by the GNU Classpath community, coordinating technical issues around implementing core libraries, compilers, tools and free runtimes. And DevJam, a GNU/Linux distro packaging conference organized by Debian, but meant as a cross-distribution coordination meeting to set common guidelines for packaging java programs and libraries. Please do add your name to the wiki if you are interested in coming. And whether or not you would need sponsorship to come. It is a little late to try and get sponsorship (oops, everybody seems to be on Christmas break already...) but we will try. No promises of course, but we do need a list of interested, cool, hip hackers to start the conversations to show that people are really interested in coming together and make magic happen. So please add you name now if you are: http://wiki.debian.org/Java/DevJam/2007/Fosdem You will need to create a Wiki login. If you rather not please just email me with your details and I will add you. Thanks, Mark signature.asc Description: This is a digitally signed message part
Re: [cp-patches] FYI: Add Enum.finalize()
On Thu, 2006-12-21 at 11:43 +, Robert Lougher wrote: JamVM therefore records a class as having a finalizer only if it has overridden the one in java.lang.Object. The assumption is that it will only provide it's own finalizer if it actually has something to do, so the code currently doesn't check if it is empty or not. I will add this check. I hope the optimization is actually worth it. It occurred to me that enums are of course by design singletons. So in that case you might not actually find so many instances of them anyway. If someone implements this 'empty-finalizer-erasure' it might be interesting to have a statistic of how many empty finalizers there actually are in the wild (say by running some bigger programs like eclipse or tomcat to see whether or not it actually occurs for real users, or only is an issue in case of contrived benchmarks). Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: [cp-patches] FYI: Add Enum.finalize()
Hi Christian, On Thu, 2006-12-21 at 15:07 +0100, Christian Thalinger wrote: An eclipse-3.2.1 startup-and-shutdown: 3808 class loads 10 classes have a finalizer 4of them are empty Make your own decision :-) Thanks for those stats! But aren't we actually interested in the number of instances of those 4 classes with empty finalizers (as percentage of object instances with and without finalizers)? I assume that the accounting and processing is per instance of such classes that are garbage collected. Then again I clearly have never written a garbage collector, especially not one that has to take into account all the tricks of java finalization. Is there any measurable runtime difference between the version that does and doesn't do empty-finalizer-erasure? Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: Mauve vs 1.5
Hi Tom, On Mon, 2006-12-25 at 14:23 -0700, Tom Tromey wrote: Mark == Mark Wielaard [EMAIL PROTECTED] writes: [ CharArrayWriter and Appendable ] Mark Now this is of course easily fixed by using -1.5 so the compiler knows Mark about covariant return types and makes all these tests that define Mark classes that extend some Writer class compile again. Yes, let's do that... Mark But now we have another problem. Shown by anything that has implements a Mark retrofitted ComparableT interface like Integer: Mark 1. ERROR in gnu/testlet/java/lang/Integer/compareTo.java line 98: Mark harness.check(zero.compareTo(o) == 0); Mark^ Mark The method compareTo(Integer) in the type Integer is not applicable for the arguments (Object) In this code, 'o' is just 'zero' cast to an Object. You could just change it to use compareTo(zero), but that doesn't test the same thing... You could change it to: harness.check(((Comparable) zero).compareTo(o) == 0); This will check using the raw Comparable and preserve the meaning of the test, more or less. Nice. I hadn't thought about that solution. And it does seem to test the thing that the original code was testing. Attached is the patch that I'll commit to switch to -1.5 by default now. Most issues were fixed by the above trick. Some others were done by supplying more specific types for some (local) variables. There are some tests disabled now regarding getEventListeners() for classes that don't extend EventListener. I don't see a way to adapt these tests, but they also look like something that nobody would every do in real world code. But if someone has a trick to test this for some real-world cases that would be nice. 2006-12-27 Mark Wielaard [EMAIL PROTECTED] * Makefile.am (JAVACFLAGS): Use -1.5. * Makefile.in: Regenerated. * gnu/testlet/java/awt/Component/getListeners.java: Disable non-compiling test. * gnu/testlet/javax/swing/table/DefaultTableColumnModel/ getListeners.java: Likewise. * gnu/testlet/java/awt/Container/getListeners.java: Likewise. * gnu/testlet/javax/swing/DefaultListSelectionModel/ getListeners.java: Likewise. * gnu/testlet/javax/swing/JComponent/getListeners.java: Likewise. * gnu/testlet/javax/swing/event/EventListenerList/add.java: Use more specific local variable types. * gnu/testlet/javax/swing/event/EventListenerList/ getListenerCount.java: Likewise. * gnu/testlet/javax/swing/event/EventListenerList/ getListenerList.java: Likewise. * gnu/testlet/javax/swing/event/EventListenerList/getListeners.java: Likewise. Disable non-compiling test. * gnu/testlet/javax/swing/event/EventListenerList/remove.java: Likewise. * gnu/testlet/java/lang/Double/compareTo.java: Add Comparable cast. * gnu/testlet/java/lang/Float/compareTo.java: Likewise. * gnu/testlet/java/lang/Integer/compareTo.java: Likewise. * gnu/testlet/java/math/BigDecimal/DiagBigDecimal.java: Likewise. * gnu/testlet/java/math/BigInteger/compareTo.java: Likewise. * gnu/testlet/java/util/Date/compareTo.java: Likewise. * gnu/testlet/javax/imageio/spi/ServiceRegistry/setOrdering.java: Use correct class literal. Cheers, Mark Index: Makefile.am === RCS file: /cvs/mauve/mauve/Makefile.am,v retrieving revision 1.32 diff -u -r1.32 Makefile.am --- Makefile.am 26 Nov 2006 16:30:03 - 1.32 +++ Makefile.am 27 Dec 2006 15:44:57 - @@ -3,7 +3,7 @@ ## FIXME: dependencies AUTOMAKE_OPTIONS = foreign subdir-objects no-dependencies -JAVACFLAGS = -g +JAVACFLAGS = -g -1.5 TESTFLAGS = Index: Makefile.in === RCS file: /cvs/mauve/mauve/Makefile.in,v retrieving revision 1.41 diff -u -r1.41 Makefile.in --- Makefile.in 26 Nov 2006 16:30:03 - 1.41 +++ Makefile.in 27 Dec 2006 15:44:57 - @@ -154,7 +154,7 @@ sysconfdir = @sysconfdir@ target_alias = @target_alias@ AUTOMAKE_OPTIONS = foreign subdir-objects no-dependencies -JAVACFLAGS = -g +JAVACFLAGS = -g -1.5 TESTFLAGS = check_DATA = $(STAMP) harness_files = \ Index: gnu/testlet/java/awt/Component/getListeners.java === RCS file: /cvs/mauve/mauve/gnu/testlet/java/awt/Component/getListeners.java,v retrieving revision 1.1 diff -u -r1.1 getListeners.java --- gnu/testlet/java/awt/Component/getListeners.java 23 Nov 2005 14:52:58 - 1.1 +++ gnu/testlet/java/awt/Component/getListeners.java 27 Dec 2006 15:44:57 - @@ -69,6 +69,7 @@ } harness.check(pass); + /* Doesn't compile with 1.5 // try a class that isn't a listener pass = false; try @@ -80,6 +81,7 @@ pass = true; } harness.check(pass); + */ } public void componentResized(ComponentEvent e) Index: gnu/testlet/java/awt/Container/getListeners.java
Re: Moving developer.classpath.org Xen session
Hi Jim, On Thu, 2006-12-28 at 00:54 -0800, Jim Pick wrote: Okay. It looks like the move worked. If I missed anything, please send me an email. Thanks! Everything seems to work just fine. Mail flows again, the developer.classpath.org mediation wiki works and the planet shows your post about the move :) Cheers, Mark
Re: awt without x server
On Wed, 2007-01-10 at 11:03 -0500, Francis Kung wrote: I've also heard that xvfb works quite well with Classpath (and uses the GTK toolkit, which is less buggy than headless). Yes, xvfb is used to run all mauve tests for example on builder.classpath.org (which doesn't have a display attached). Debian has a xvfb-run command which makes it easy to run any command under a virtual X server environment. Cheers, Mark signature.asc Description: This is a digitally signed message part
[Fwd: javac and HotSpot interest at FOSDEM?]
Hi hackers, For those of you not following the openjdk discussion mailinglists yet, Tom Marble is preparing the OpenJDK involvement for Fosdem. Please let him know if you are interesting in having more javac/hotspot engineers around (I am!). And please do add yourself to the Classpath/Devjam/OpenJDK Fosdem interest wiki page at http://wiki.debian.org/Java/DevJam/2007/Fosdem Cheers, Mark ---BeginMessage--- All: We are considering the appropriate kind of representation Sun should have at FOSDEM [1], and, specifically if we can justify attendance by core javac and/or HotSpot engineers. If you are planning to attend FOSDEM and would see value from having javac and/or HotSpot developers present please let me know! Thanks, --Tom [1] http://www.fosdem.org/2007/about/fosdem ---End Message---
Re: [Fwd: Mail delivery failed: returning message to sender]
On Wed, 2007-02-14 at 23:20 +, Andrew John Hughes wrote: I got the following message when committing to the gjdoc project. Looks like the associated commit mailing may need a change... :) Oops. My fault. I have asked the savannah-hackers to redirect the commit mails from the cp-tools module to the commit-classpath list. Thanks, Mark signature.asc Description: This is a digitally signed message part
Re: 10 years CACAO
Hi, On Mon, 2007-02-19 at 12:23 +0100, Christian Thalinger wrote: our previously closed-source JIT compiler ports for the Arm and MIPS (o32) architecture have been released also under the GPL. Furthermore, it is now possible to use Sun's phoneme CLDC-1.1 classes with CACAO out-of-the-box. Woot! This is so great! I cannot wait for the GNU Classpath Runtime Rumble at Fosdem. http://www.fosdem.org/2007/schedule/events/java_classpath_runtime_rumble You certainly delivered a great opening punch! Happy Birthday, Mark signature.asc Description: This is a digitally signed message part
Fosdem Food Drinks
Hi, We selected a few places to meet, eat and drink in Brussel during Fosdem (thanks to David Delabassee for calling the restaurants to see if they were open had room). The rough estimate currently is 30 people. To see if that is an good estimate please do add yourself to the wiki under interested people and add whether you would like to take part on Friday, Saturday and/or Sunday. http://wiki.debian.org/Java/DevJam/2007/Fosdem Thanks, Mark The list of addresses. The wiki contains maps of the area thanks to Tom Marble): - Friday Ricotta Parmesan at 18:30 Rue de l'Ecuyer 31 (Schildknaapsstraat) +32 2 513.78.81 http://www.ricottaparmesan.be Afterwards Roy d'Espagne Grand Place 1 (Grote Markt) +32 2 513.08.07 http://www.fosdem.org/2007/beerevent - Saturday L'Element Terre at 19:00 Chée.de Waterloo 465 (Waterloosesteenweg) +32 2 649.37.27 http://www.resto.com/lelementterre/ Afterwards A La Mort Subite 7 rue Montagne aux Herbes Potageres +32 2 513.13.18 http://www.alamortsubite.com/ - Sunday Apocalypse at 19:00 Adolphe Buyllaan 20 +32 2 647.07.18 http://sites.resto.com/apocalypse/ Afterwards Suggestions welcome. signature.asc Description: This is a digitally signed message part
Re: [Devjam] Re: Fosdem Food Drinks
On Thu, 2007-02-22 at 14:07 +, Andrew Haley wrote: Mark Wielaard writes: We selected a few places to meet, eat and drink in Brussel during Fosdem (thanks to David Delabassee for calling the restaurants to see if they were open had room). The rough estimate currently is 30 people. To see if that is an good estimate please do add yourself to the wiki under interested people and add whether you would like to take part on Friday, Saturday and/or Sunday. http://wiki.debian.org/Java/DevJam/2007/Fosdem Debian Wiki is FUBAR. It is back up now. Note that it contains some addresses of bars and restaurants and maps of Brussel so better print that out now before you leave (or the machine accidentially gets unplugged again). And for those that haven't seen it yet, there is now also a full color poster describing some of the events taking place: http://gnu.wildebeest.org/diary/2007/02/22/fosdem-gnu-classpathopenjdk-devjam-developer-room-poster/ Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: New release?
Hoi, On Mon, 2007-03-12 at 18:06 +0100, Jeroen Frijters wrote: When is the next release due? The current release (0.93) has the incorrect daylight savings rules for the US and I've already had one IKVM user run into this. I'm probably going to release an IKVM update that is based on GNU Classpath 0.93 + the cvs version of TimeZone, but it would be nice to release 0.94 in the not too distant future. Yes, the TimeZone issue is much bigger than I anticipated. I see Red Hat even did an update of gcc for their enterprise product: https://rhn.redhat.com/errata/RHBA-2007-0101.html This is also the patch that Andrew backported to classpath. (Thanks Jakub, thanks Andrew) I admit that I have been waiting a bit on the gcj hackers to get all the bugs out of the new 1.5 support (which they seem to do - thanks gcj hackers!). But people seem hungry for a release now so lets aim for a release at the end of the week. Things to figure out are: - Regressions in mauve. According to classpath-testresults there are some. Lets figure out what they are and how to fix them. - Go through bugzilla and look for anything embarrasing that really needs fixing (but lets focus on regressions). - Make sure we have all the configure/build stuff correct now. There seem to be needed some patches for the new automake 1.10 that is starting to pop up in distros now. Check that both ecj and javac are supported. And do we have the plugin stuff now finally correct? Anything else? Anyone up to making lists for points 1 and 2? Cheers, Mark signature.asc Description: This is a digitally signed message part
savannah/CVS
Hardware knows when we want to prep for a release... The server for savannah.gnu.org has experienced a complex hardware failure. Replacement parts are being shipped next-day air and should be installed the afternoon (EDT) of 14 March. We're sorry for the inconvenience -- the GNU sysadmins. So savannah.gnu.org and cvs are out till tomorrow at least.
Re: savannah/CVS
On Tue, 2007-03-13 at 20:56 +0100, Mark Wielaard wrote: Hardware knows when we want to prep for a release... The server for savannah.gnu.org has experienced a complex hardware failure. Replacement parts are being shipped next-day air and should be installed the afternoon (EDT) of 14 March. We're sorry for the inconvenience -- the GNU sysadmins. So savannah.gnu.org and cvs are out till tomorrow at least. Latest status is as follows: The server for savannah.gnu.org has experienced a multiple disk failure. New disks were received. SV is being brought to the offsite backup location (eta. 14 March 9PM GMT), where it will be sync'd (eta. ???) and brought back to the colocation at quincy, ma (est. 1/2h?). We're sorry for the inconvenience. | Last confirmed full backup was completed circa 20:30 EDT on Sunday 11 March. So much for relying on a raid5 setup for making sure you can survive a disk-failure... Cheers, Mark
Re: savannah/CVS
Hi, As you probably noticed from watching the cvs and patches mailinglist savannah is back up again (see the attached email from the savannah admins). We lost only 2 patches. One configure patch I did just before the disk crash, which I have already put back. And the InputStreamReader and OutputStreamWriter revisited patch from Roman, which I haven't put back yet (Roman, let me know if you want me to put it in or whether you do it). Cheers, Mark ---BeginMessage--- Hi, Savannah is up and running again after about 2 days 1/2 downtime. The system was completely restored using the backup from Sunday night, and a partial backup from Monday night (Boston time). We still have concerns about the RAID hardware (3 old + 1 new SCSI disks failed); we're going to order more parts and replace them asap. We'll post more info on the Savannah homepage in a bit. Thanks to everybody among the FSF Sysadmins and the Savannah Hackers who stayed up late working on the recovery! -- Sylvain On Thu, Mar 15, 2007 at 12:00:05AM +0100, Sylvain Beucler wrote: Hi, The server for savannah.gnu.org has experienced a multiple disk failure, bypassing the RAID5 safety. New disks were received (March 14 AM). SV was brought to the offsite backup location (14 March 9PM GMT), where the FSF sysadmins are trying to recover the filesystem, or if that fails, restore the latest backup image. Then the machine will be brought back to the colocation at Quincy, MA (about 1h30 drive away afaik). We're sorry for the inconvenience. We posted a notice about the downtime at gnu.org and fsf.org. Webpages, mailing lists, ftp|alpha.gnu.org and other GNU services are not affected. ___ Savannah-announce@gnu.org mailing list http://lists.gnu.org/mailman/listinfo/savannah-announce ---End Message---
Re: jetty-5.1.11 regression
Hi Christian, On Fri, 2007-03-23 at 12:26 +0100, Christian Thalinger wrote: I've found another regression with current head. jetty-5.1.11 does not serve pages anymore (while it does for 6.1.1): $ telnet localhost 8080 Trying 127.0.0.1... Connected to localhost.localdomain. Escape character is '^]'. Connection closed by foreign host. There are no exceptions during startup. This happens since a few days (or a week). I noticed various Mauve Socket regressions on classpath-testresults: http://lists.gnu.org/archive/html/classpath-testresults/2007-03/ But haven't yet tracked down when they started. If someone wants to dig into this, the regressions are: FAIL: java.net.HttpURLConnection.postHeaders FAIL: java.net.HttpURLConnection.responseCodeTest FAIL: java.net.ServerSocket.AcceptGetLocalPort FAIL: java.net.ServerSocket.ServerSocketTest FAIL: java.net.ServerSocket.security FAIL: java.net.Socket.SocketTest FAIL: java.net.Socket.jdk13 FAIL: java.net.Socket.jdk14 FAIL: java.util.logging.SocketHandler.publish And I suspect the CORBA related regressions are also caused by this. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: Question about license
Hi 'hultul', On Sat, 2007-03-31 at 10:18 +0900, hultul wrote: I'm developing JVM implementation which uses GNU Classpath as runtime class library. I have two questions about the license of GPLv2 with GNU Classpath Exception, though I'm not sure whether those questions are adequate for GNU Classpath community. Since this is a developer list focused on code it is best is to ask specific legal questions to [EMAIL PROTECTED] They are happy to answer any legal question around free software, there is also the Software Freedom Law Center http://www.softwarefreedom.org/ that handles such things. For proprietary software you can also contact the FSF Compliance Lab http://www.fsf.org/licensing/compliance.html 1. Can I bundle GNU Classpath binary without any modification and my JVM(thought to be not under GPL), and distribute that not under GPL? 2. If I make some proprietary classes(e.g. java.lang.ClassLoader) be loaded prior to GNU Classpath's classes, am I modify GNU Classpath? If so, are those proprietary classes and/or JVM implementation should be under GPL? If you combine GNU Classpath with independent modules to produce an executable you can copy and distribute the resulting executable under terms of your choice. See http://www.gnu.org/software/classpath/license.html and http://www.gnu.org/software/classpath/faq/faq.html#faq2_1 But we do of course hope you will release your program as free software under the GPL whenever possible to share with the community. We try to set things up so that you don't have to override or change any of the core classes directly (they should be [and are!] easily sharable between lots of runtimes). For the connection between ClassLoader and the runtime there is VMClassLoader which handles all VM interaction. See http://www.gnu.org/software/classpath/docs/vmintegration.html Please do let us know if these VM/Platform interfaces are not flexible enough, we would love to help and improve them. Cheers, Mark
Re: dacapo jython regression
Hi Christian, On Wed, 2007-03-28 at 20:36 +0200, Christian Thalinger wrote: Another regression (it works with 0.93): $ cacao -jar dacapo-2006-10-MR2.jar -s small jython This should have been fixed by Roman's reversal of the io streams patch on 2007-03-28 (we will try again after the release), could you confirm? Thanks, Mark
Re: xml/dom regression
Hi Christian, On Mon, 2007-03-12 at 18:01 +0100, Christian Thalinger wrote: I'm having a regression with SPECjbb2005 (this worked with 0.93, just verified): Is this still a problem with current CVS? If so, could you give some more info (especially what do the XMLTransactionLog static constructor and the NewOrderTransaction constructor try to do) and/or file a bug report? Thanks, Mark Exception in thread main java.lang.ExceptionInInitializerError at spec.jbb.NewOrderTransaction.init(Unknown Source) at spec.jbb.Company.loadInitialOrders(Unknown Source) at spec.jbb.Company.primeWithDummyData(Unknown Source) at spec.jbb.JBBmain.increaseNumWarehouses(Unknown Source) at spec.jbb.JBBmain.doItForValidation(Unknown Source) at spec.jbb.JBBmain.main(Unknown Source) Caused by: gnu.xml.dom.ls.DomLSException: unable to resolve external entity: jbb-document.dtd at gnu.xml.dom.ls.DomLSParser.doParse(DomLSParser.java:320) at gnu.xml.dom.ls.DomLSParser.parse(DomLSParser.java:159) at gnu.xml.dom.ls.DomLSParser.parseURI(DomLSParser.java:175) at gnu.xml.dom.DomDocumentBuilder.parse(DomDocumentBuilder.java:165) at spec.jbb.infra.Util.XMLTransactionLog.clinit(Unknown Source) Caused by: org.xml.sax.SAXParseException: unable to resolve external entity: jbb-document.dtd at gnu.xml.stream.SAXParser.parse(SAXParser.java:662) at gnu.xml.dom.ls.DomLSParser.doParse(DomLSParser.java:308) ...4 more Caused by: javax.xml.stream.XMLStreamException: unable to resolve external entity: jbb-document.dtd at gnu.xml.stream.XMLParser.error(XMLParser.java:4147) at gnu.xml.stream.XMLParser.pushInput(XMLParser.java:1566) at gnu.xml.stream.XMLParser.readDoctypeDecl(XMLParser.java:1852) at gnu.xml.stream.XMLParser.next(XMLParser.java:1164) at gnu.xml.stream.XMLParser.hasNext(XMLParser.java:1018) at gnu.xml.stream.SAXParser.parse(SAXParser.java:379) ...5 more signature.asc Description: This is a digitally signed message part
Re: Thread.getState() return value
On Thu, 2007-04-05 at 12:26 +0200, Christian Thalinger wrote: Finally I had some time to implement Thread.getState() and noticed that we still return a java.lang.String. Shouldn't we change that since we are now 1.5 on head? I assume you are talking about VMThread.getState(). I would rather keep the current interface returning a static String instead of adding Enums to the VM interface at this point. Cheers, Mark signature.asc Description: This is a digitally signed message part
[commit-cp] classpath ChangeLog autogen.sh configure.ac nat...
CVSROOT:/cvsroot/classpath Module name:classpath Changes by: Mark Wielaard mark07/04/05 12:05:48 Modified files: . : ChangeLog autogen.sh configure.ac native/jawt: Makefile.am native/jni/gconf-peer: Makefile.am native/jni/gtk-peer: Makefile.am native/jni/midi-alsa: Makefile.am native/jni/midi-dssi: Makefile.am native/jni/qt-peer: Makefile.am Log message: * autogen.sh: Recognize automake 1.10. * configure.ac (AM_INIT_AUTOMAKE): Add -Wno-portability. * native/jawt/Makefile.am (libjawt_la_LDFLAGS): Add AM_LDFLAGS. * native/jni/gconf-peer/Makefile.am (libgconfpeer_la_LDFLAGS): Likewise. * native/jni/gtk-peer/Makefile.am (libgtkpeer_la_LDFLAGS): Likewise. * native/jni/midi-alsa/Makefile.am (libgjsmalsa_la_LDFLAGS): Likewise. * native/jni/midi-dssi/Makefile.am (libgjsmdssi_la_LDFLAGS): Likewise. * native/jni/qt-peer/Makefile.am (libqtpeer_la_LDFLAGS): Likewise. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.9211r2=1.9212 http://cvs.savannah.gnu.org/viewcvs/classpath/autogen.sh?cvsroot=classpathr1=1.16r2=1.17 http://cvs.savannah.gnu.org/viewcvs/classpath/configure.ac?cvsroot=classpathr1=1.200r2=1.201 http://cvs.savannah.gnu.org/viewcvs/classpath/native/jawt/Makefile.am?cvsroot=classpathr1=1.8r2=1.9 http://cvs.savannah.gnu.org/viewcvs/classpath/native/jni/gconf-peer/Makefile.am?cvsroot=classpathr1=1.5r2=1.6 http://cvs.savannah.gnu.org/viewcvs/classpath/native/jni/gtk-peer/Makefile.am?cvsroot=classpathr1=1.50r2=1.51 http://cvs.savannah.gnu.org/viewcvs/classpath/native/jni/midi-alsa/Makefile.am?cvsroot=classpathr1=1.4r2=1.5 http://cvs.savannah.gnu.org/viewcvs/classpath/native/jni/midi-dssi/Makefile.am?cvsroot=classpathr1=1.8r2=1.9 http://cvs.savannah.gnu.org/viewcvs/classpath/native/jni/qt-peer/Makefile.am?cvsroot=classpathr1=1.7r2=1.8
0.95 branch created
Hi, A release branch has been created 'classpath-0_95-branch' I'll try to pick up any fixes made on the trunk, but if you feel some patch is release critical please do CC me. Mauve results and smoke tests (examples, eclipse, swingset 2d demo, jboss, jfreechart) look pretty good. There are some docs generated with sinjdoc at http://developer.classpath.org/sinjdoc/ (it doesn't look as good as the old gjdoc ones and it is missing support for -linksource, -licensetext, -validhtml, and @Link support in comments, but has to do for now). Build has been cleaned up to better detect various browser plugin environments and automake 1.10 systems (although Dalibor has some cleanups and documentation pending). It looks pretty good to me, but if there are still bugs you want to get fixed then now would be the time to do it! If cleanups and testing go well over the weekend/easter we will hopefully have a release by Tuesday. And if you did something cool for this release make sure you have updated the NEWS file! Mauve regressions that should be fixed/investigated: FAIL: gnu.java.security.jce.TestOfHttps FAIL: java.net.URLConnection.getHeaderFields (Seems to have to do something with how we handle the cacerts file) FAIL: javax.swing.TransferHandler.createTransferable (I thought this was fixed with Francis latest patch, but builder still has trouble with it for some reason) FAIL: javax.swing.table.JTableHeader.AccessibleJTableHeader.AccessibleJTableHeaderEntry.getFont (Not investigated yet) Also I am seeing some out of memory issues with images in some applications that needs looking into. Cheers, Mark signature.asc Description: This is a digitally signed message part
RE: 0.95 branch created
On Sat, 2007-04-07 at 08:03 +0200, Jeroen Frijters wrote: Mark Wielaard wrote: A release branch has been created 'classpath-0_95-branch' Shouldn't that have been 0.94? Yeah, the branch was created, then I realized my mistake. But the revisionist history is that 0.95 is such a huge step forward (and so late) that it deserves a 0.02 version bumb. And it ends in a 5 which shows our commitment to 1.5+ from here on. :) I'll try to pick up any fixes made on the trunk, but if you feel some patch is release critical please do CC me. I'd really like to see the removal of the META-INF/services/*xml* go in. Yes, that seems like a good idea. libgcj also did I believe that and the fallbacks are in place. Besides the four service files you mention they also remove the following 2 though: META-INF/services/org.relaxng.datatype.DatatypeLibraryFactory META-INF/services/org.w3c.dom.DOMImplementationSourceList The first has always (more than a year been there when Chris added relaxng support, second was added a few weeks ago by Gary. Should these also not be there? The rule being if it is a service in the core classes we default to in in code not through service files? Then what about the prefs and sound ones? Cheers, Mark signature.asc Description: This is a digitally signed message part
RE: 0.95 branch created
Hi, On Sat, 2007-04-07 at 17:48 +0200, Jeroen Frijters wrote: Yeah, I wasn't sure about these two (I don't know very much about all the xml apis, so I was being conservative and requesting to at least remove the ones that I have personally seen cause problems), but if libgcj removed them we probably should too. OK, I did some quick test runs with this patch and will commit it to trunk and the release branch: 2007-04-07 Mark Wielaard [EMAIL PROTECTED] * resource/META-INF/services/javax.xml.parsers.DocumentBuilderFactor, resource/META-INF/services/javax.xml.parsers.SAXParserFactory, resource/META-INF/services/javax.xml.parsers.TransformerFactory, resource/META-INF/services/org.relaxng.datatype.DatatypeLibraryFactory, resource/META-INF/services/org.w3c.dom.DOMImplementationSourceList, resource/META-INF/services/org.xml.sax.driver: Removed. Cheers, Mark Index: resource/META-INF/services/javax.xml.parsers.DocumentBuilderFactory === RCS file: resource/META-INF/services/javax.xml.parsers.DocumentBuilderFactory diff -N resource/META-INF/services/javax.xml.parsers.DocumentBuilderFactory --- resource/META-INF/services/javax.xml.parsers.DocumentBuilderFactory 25 May 2005 22:26:30 - 1.1 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1 +0,0 @@ -gnu.xml.dom.DomDocumentBuilderFactory Index: resource/META-INF/services/javax.xml.parsers.SAXParserFactory === RCS file: resource/META-INF/services/javax.xml.parsers.SAXParserFactory diff -N resource/META-INF/services/javax.xml.parsers.SAXParserFactory --- resource/META-INF/services/javax.xml.parsers.SAXParserFactory 27 Dec 2005 19:56:16 - 1.4 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1 +0,0 @@ -gnu.xml.stream.SAXParserFactory Index: resource/META-INF/services/javax.xml.parsers.TransformerFactory === RCS file: resource/META-INF/services/javax.xml.parsers.TransformerFactory diff -N resource/META-INF/services/javax.xml.parsers.TransformerFactory --- resource/META-INF/services/javax.xml.parsers.TransformerFactory 25 May 2005 22:26:30 - 1.1 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1 +0,0 @@ -gnu.xml.transform.TransformerFactoryImpl Index: resource/META-INF/services/org.relaxng.datatype.DatatypeLibraryFactory === RCS file: resource/META-INF/services/org.relaxng.datatype.DatatypeLibraryFactory diff -N resource/META-INF/services/org.relaxng.datatype.DatatypeLibraryFactory --- resource/META-INF/services/org.relaxng.datatype.DatatypeLibraryFactory 13 Feb 2006 19:27:24 - 1.1 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1 +0,0 @@ -gnu.xml.validation.datatype.TypeLibraryFactory Index: resource/META-INF/services/org.w3c.dom.DOMImplementationSourceList === RCS file: resource/META-INF/services/org.w3c.dom.DOMImplementationSourceList diff -N resource/META-INF/services/org.w3c.dom.DOMImplementationSourceList --- resource/META-INF/services/org.w3c.dom.DOMImplementationSourceList 7 Mar 2007 13:30:26 - 1.1 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1 +0,0 @@ -gnu.xml.dom.ImplementationSource Index: resource/META-INF/services/org.xml.sax.driver === RCS file: resource/META-INF/services/org.xml.sax.driver diff -N resource/META-INF/services/org.xml.sax.driver --- resource/META-INF/services/org.xml.sax.driver 29 Dec 2005 09:14:20 - 1.2 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1 +0,0 @@ -gnu.xml.stream.SAXParser
[commit-cp] classpath ChangeLog resource/META-INF/services/...
CVSROOT:/cvsroot/classpath Module name:classpath Changes by: Mark Wielaard mark07/04/07 18:30:07 Modified files: . : ChangeLog Removed files: resource/META-INF/services: javax.xml.parsers.DocumentBuilderFactory javax.xml.parsers.SAXParserFactory javax.xml.parsers.TransformerFactory org.relaxng.datatype.DatatypeLibraryFactory org.w3c.dom.DOMImplementationSourceList org.xml.sax.driver Log message: * resource/META-INF/services/javax.xml.parsers.DocumentBuilderFactor, resource/META-INF/services/javax.xml.parsers.SAXParserFactory, resource/META-INF/services/javax.xml.parsers.TransformerFactory, resource/META-INF/services/org.relaxng.datatype.DatatypeLibraryFactory, resource/META-INF/services/org.w3c.dom.DOMImplementationSourceList, resource/META-INF/services/org.xml.sax.driver: Removed. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.9225r2=1.9226 http://cvs.savannah.gnu.org/viewcvs/classpath/resource/META-INF/services/javax.xml.parsers.DocumentBuilderFactory?cvsroot=classpathr1=1.1r2=0 http://cvs.savannah.gnu.org/viewcvs/classpath/resource/META-INF/services/javax.xml.parsers.SAXParserFactory?cvsroot=classpathr1=1.4r2=0 http://cvs.savannah.gnu.org/viewcvs/classpath/resource/META-INF/services/javax.xml.parsers.TransformerFactory?cvsroot=classpathr1=1.1r2=0 http://cvs.savannah.gnu.org/viewcvs/classpath/resource/META-INF/services/org.relaxng.datatype.DatatypeLibraryFactory?cvsroot=classpathr1=1.1r2=0 http://cvs.savannah.gnu.org/viewcvs/classpath/resource/META-INF/services/org.w3c.dom.DOMImplementationSourceList?cvsroot=classpathr1=1.1r2=0 http://cvs.savannah.gnu.org/viewcvs/classpath/resource/META-INF/services/org.xml.sax.driver?cvsroot=classpathr1=1.2r2=0
[commit-cp] classpath ChangeLog resource/META-INF/services/... [classpath-0_95-branch]
CVSROOT:/cvsroot/classpath Module name:classpath Branch: classpath-0_95-branch Changes by: Mark Wielaard mark07/04/07 18:32:40 Modified files: . : ChangeLog Removed files: resource/META-INF/services: javax.xml.parsers.DocumentBuilderFactory javax.xml.parsers.SAXParserFactory javax.xml.parsers.TransformerFactory org.relaxng.datatype.DatatypeLibraryFactory org.w3c.dom.DOMImplementationSourceList org.xml.sax.driver Log message: * resource/META-INF/services/javax.xml.parsers.DocumentBuilderFactor, resource/META-INF/services/javax.xml.parsers.SAXParserFactory, resource/META-INF/services/javax.xml.parsers.TransformerFactory, resource/META-INF/services/org.relaxng.datatype.DatatypeLibraryFactory, resource/META-INF/services/org.w3c.dom.DOMImplementationSourceList, resource/META-INF/services/org.xml.sax.driver: Removed. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathonly_with_tag=classpath-0_95-branchr1=1.9222.2.2r2=1.9222.2.3 http://cvs.savannah.gnu.org/viewcvs/classpath/resource/META-INF/services/javax.xml.parsers.DocumentBuilderFactory?cvsroot=classpathonly_with_tag=classpath-0_95-branchr1=1.1r2=0 http://cvs.savannah.gnu.org/viewcvs/classpath/resource/META-INF/services/javax.xml.parsers.SAXParserFactory?cvsroot=classpathonly_with_tag=classpath-0_95-branchr1=1.4r2=0 http://cvs.savannah.gnu.org/viewcvs/classpath/resource/META-INF/services/javax.xml.parsers.TransformerFactory?cvsroot=classpathonly_with_tag=classpath-0_95-branchr1=1.1r2=0 http://cvs.savannah.gnu.org/viewcvs/classpath/resource/META-INF/services/org.relaxng.datatype.DatatypeLibraryFactory?cvsroot=classpathonly_with_tag=classpath-0_95-branchr1=1.1r2=0 http://cvs.savannah.gnu.org/viewcvs/classpath/resource/META-INF/services/org.w3c.dom.DOMImplementationSourceList?cvsroot=classpathonly_with_tag=classpath-0_95-branchr1=1.1r2=0 http://cvs.savannah.gnu.org/viewcvs/classpath/resource/META-INF/services/org.xml.sax.driver?cvsroot=classpathonly_with_tag=classpath-0_95-branchr1=1.2r2=0
Re: 0.95 branch created
On Sat, 2007-04-07 at 00:51 +0200, Mark Wielaard wrote: FAIL: javax.swing.TransferHandler.createTransferable (I thought this was fixed with Francis latest patch, but builder still has trouble with it for some reason) This has nothing to do with the issue that Francis fixed (that is properly fixed). This is because of a bug introduced in cacao that doesn't do a proper access check and lets the test (indirectly) invoke a method that it shouldn't be able to access. It was introduced in cacao by: r7418 | twisti | 2007-02-28 21:07:06 +0100 (Wed, 28 Feb 2007) Cheers, Mark signature.asc Description: This is a digitally signed message part
Method.invoke() on a non-public class from another package
On Sun, 2007-04-08 at 12:53 +0200, Christian Thalinger wrote:
Grrr, I hate this access checks. I'll try to fix that _again_.
This seems to be pretty subtle and we found multiple runtimes (jamvm,
cacao, gcj and kaffe at least) that seem to get this wrong. And the
online documentation is not very precise. As it says just:
throws IllegalAccessException - if this Method object enforces Java
language access control and the underlying method is inaccessible.
But the JCL (second edition, volume 1) is more precise:
When invoke() is called, the JVM performs the access checks described
in the JLS, First Edition, Section 6.6.1. These checks compare the
identity of the caller of invoke() with the access permission and
identity of the method being called. It is as if the caller of invoke()
had a staticly compiled call to the selected method. the access cgecks
take into account both the accessibility of the method itself and the
accessibility of its class.
And JLS, First Edition, Section 6.6.1 says:
If a class or interface type is declared public, then it may be
accessed by any Java code that can access the package in which it is
declared. If a class or interface type is not declared public, then it
may be accessed only from within the package in which it is declared.
A member (field or method) of a reference (class, interface, or array)
type or a constructor of a class type is accessible only if the type is
accessible and the member or constructor is declared to permit access:
[...]
So when Method.invoke() is called on an method member of an object which
class type isn't public then it should only be allowed to successfully
call the method if the caller is in the same package.
Attached is a simplified test case (3 classes - c1 is in package p1, c2
and c3 are in package p2, c2 is not public, p1.c1 is the entry point)
that should throw an IllegalAccessException on the line:
m.invoke(o, new Object[0]);
Cheers,
Mark
package p1;
import java.lang.reflect.Method;
public class c1
{
public static void main(String[] args) throws Exception
{
Object o = p2.c3.getc2();
Class c = o.getClass();
Method m = c.getDeclaredMethod(m, new Class[0]);
m.invoke(o, new Object[0]);
}
}
package p2;
// package private class
class c2
{
public void m() { }
}
package p2;
public class c3
{
public static Object getc2() { return new c2(); }
}
builder now runs Debian GNU/Linux 4.0 (etch)
Hi, To increase the release pressure a bit builder.classpath.org got upgraded to the Debian Easter release. builder was running with some backported packages and this was a good opportunity to refresh our autobuilder and see whether anything broke. Happily Debian stable now once again provides all the right versions of our dependencies. Hint for our Debian lovers, for compiling the applet webplugin you will need the libxul-dev package and dependencies. It will then be build against xulrunner. Fresh build logs should appear soon again on classpath-testresults. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: 0.95 branch created
Hi Paul, On Tue, 2007-04-10 at 13:57 +0100, Paul Jenner wrote: On Sat, 2007-04-07 at 00:51 +0200, Mark Wielaard wrote: A release branch has been created 'classpath-0_95-branch' Can the latest build of the release candidate be made available for download on builder.classpath.org as it was for the previous releases? I think it would help those who want to test but don't stay up to date with CVS. Good point. I activated the ClasspathRelease script on builder that should produce a tar.gz for the release candidate (classpath-0.95-rc.tar.gz) at http://builder.classpath.org/dist/ Also checked the normal script and re-enabled to creation of classpath-latest.tar.gz. Don't know why that was disabled. But it is fixed now (I hope, please yell and scream if it isn't refreshed in the next 24 hours). Thanks, Mark signature.asc Description: This is a digitally signed message part
Re: 0.95 branch created
Hi, On Thu, 2007-04-19 at 12:58 -0400, Francis Kung wrote: All of these pass for me as well, with one exception. In general I've found robot / visual tests (as many of these are) are very finicky, and require that you not be using your computer at all while they are running. Here too, but indeed they are a little fragile. Thanks for the extra testing! Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: gnu classpath with sun java vm
Hi Michel, On Thu, 2007-04-19 at 15:23 +0200, [EMAIL PROTECTED] wrote: When trying to start gappletviewer, I get a missing resource-bundle-error. Now, I saw that the resource-bundles are inside glibj.zip. I added this zip-file to the Xbootclasspath-parameter of the gappletviewer, but then I get a stackoverflow-error. Is there any way I can get the applet-support to work with the java-vm from Sun? Which resource bundle is missing? That might be a bug where we accidentally put a resource in glibj.zip that should be in tools.zip. Adding glibj.zip to the bootclasspath is certainly not going to work since it will have classes in it that conflict with the bootclasses from the sun java-vm. Try adding it to the classpath instead. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: gnu classpath with sun java vm
On Thu, 2007-04-19 at 23:19 +0200, Michel Brabants wrote: thank you for helping out. Well, from what I saw. There are no resourcebundles present in tools.zip at all. In my case it is trying to find nl_BE, but I suppose it depends on your locale. If you need more info, feel free to ask :). How are you trying to run what and which output does it produce? signature.asc Description: This is a digitally signed message part
[commit-cp] classpath ChangeLog m4/acinclude.m4 [classpath-0_95-branch]
CVSROOT:/cvsroot/classpath Module name:classpath Branch: classpath-0_95-branch Changes by: Mark Wielaard mark07/04/20 12:13:12 Modified files: . : ChangeLog m4 : acinclude.m4 Log message: 2007-04-19 Andrew John Hughes [EMAIL PROTECTED] * m4/acinclude.m4 (CLASSPATH_FIND_JAVAC): Allow detected JAVAC. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathonly_with_tag=classpath-0_95-branchr1=1.9222.2.20r2=1.9222.2.21 http://cvs.savannah.gnu.org/viewcvs/classpath/m4/acinclude.m4?cvsroot=classpathonly_with_tag=classpath-0_95-branchr1=1.15r2=1.15.2.1
Re: [Off-Topic] TCK Certification
Hi Davanum, On Fri, 2007-04-20 at 10:46 -0400, Davanum Srinivas wrote: Wanted to poll everyone on what their thoughts are regarding certification. Feathercast has an interview with Geir [1] outlining our current situation and the open letter [2] we sent to Sun. - Would anyone working of the VM's based on classpath be interested in the TCK? (Yes, i know Dalibor tried once before) Yes, but the TCK is many things. Source code tests, compatibility claims, certification processes, trademarks, branding rights obligations, etc. Some of these don't really make sense for a free software project, or at least to the . Certification is often tied to a specific binary release on a specific hardware/platform. GNU Classpath does only release source code for example. But extra tests are always welcome. We did indeed try to get access to the JCK (that is the TCK covering the core java platform) about 2.5 years ago. But that soon stopped because of NDA restrictions that just don't make sense for any open distributed collaborative effort like GNU Classpath, Kaffe, GCJ, etc. - If so, Would you be willing to accept Field of Use restriction basically telling downstream users where/how they can use your code? It was unclear what these 'restrictions' actually were from reading that letter and the faq. Do they hold for the source code or only for the certified binaries for a specific platform? Anyway, the only 'restrictions' that we would accept for the GNU Classpath code would be that people share-and-share-alike as stipulated in the GPL. Cheers, Mark
Re: [Off-Topic] TCK Certification
Hi Dalibor, On Fri, 2007-04-13 at 03:18 +0200, Dalibor Topic wrote: The time line of events is probably important as well: We started the negotiation after the Boston runtime summit, after the release of Java 1.5, and spent some time clarifying the terms I was unfamiliar with. Eventually, the ASF wanted to get in on the game, so, since the ASF had experience with getting and managing TCKs, I switched gears and rather than certifying Kaffe/Classpath worked on turning Harmony into the unifying project for different VMs, making ASF embrace GNU Classpath, and all that idealistic fun stuff that you're read me talking about back in the day. Thanks for your well thought out email on this subject. I posted some more of my own thoughts on these issues in my blog: http://gnu.wildebeest.org/diary/2007/04/21/openjck/ Cheers, Mark signature.asc Description: This is a digitally signed message part
ANN: gjdoc 0.7.8 (Naughty Puppy) released
We are pleased to announce gjdoc 0.7.8 (Naughty Puppy). gjdoc is the GNU documentation generation framework for java source files. gjdoc is part of the GNU Classpath Tools: http://www.gnu.org/software/classpath/cp-tools/ This release is mainly to make sure that gjdoc can handle the new 1.5 language features introduced in the upcoming releases of gcj and GNU Classpath. The support for the 1.5 language features isn't complete, but this release of gjdoc should be able to at least handle the basics and generate documentation for java source code files that contain generics, annotations and enumerations. Help for extending the support and update the gjdoc parser are highly appreciated. New in release 0.7.8 * Naughty 1.5 release * GJDoc can now successfully run against the new 1.5-based version of GNU Classpath, including generics, annotations and enumerations. * Includes gjdoc/25876: Basic annotation support for gjdoc contributed by Stephan Michels Special thanks to Andrew Hughes for preparing this release. Also thanks to Stephan Michels, Ben Konrath, Dalibor Topic, Andrew Overholt and Tom Tromey for reporting bugs, suggesting, testing and fixing things in this release. The latest release of GNU gjdoc can always be found at ftp://ftp.gnu.org/gnu/classpath/ This new version of gjdoc has been used to generate class documentation for the GNU Classpath CVS source files: http://developer.classpath.org/doc/ signature.asc Description: This is a digitally signed message part
GNU Classpath 0.95 Take Five released
://developer.classpath.org/mediation/ClasspathBanners GNU Classpath 0.95 can be downloaded from ftp://ftp.gnu.org/pub/gnu/classpath/ or one of the ftp.gnu.org mirrors http://www.gnu.org/order/ftp.html File: classpath-0.95.tar.gz MD5sum: 08638bb9221460cc311a1c5508083ed8 SHA1sum: 9a3b276853a07ecc8753217a6db24afffab2cb2c New in release 0.95 (Apr 23, 2007) (See the ChangeLog file for a full list of changes.) * Full merge of 1.5 generics work. * Added 1.6 java.util.ServiceLoader support. * The ASM library is now included. A separate copy is no longer needed. gjavah works out of the box now. * The setReadTimeout and getReadTimeout methods have been added to java.net.URLConnection. They are now fully implemented for http URLs. * The java.lang.management implementation now includes the new features added in 1.6 * java.util.TimeZone now reads time zone information from the system zoneinfo files (see also runtime interface changes below). * The collection classes have been updated to support all the 1.6 additions. * java.util.spi 1.6 package has been added and is used in java.text. * Bootstrappable with OpenJDK javac compiler (use configure --with-javac). * Large speedups (and locking behaviour updated) in Graphics2D cairo and freetype support. * Better detection of browser plugin mechanism for mozilla, iceweasel, firefox on various platforms. * Inclusion of generic javadoc classes in tools.zip to support more javadoc processing tools. * Added documentation for command lines options for the included GNU Classpath Tools gjar, gjavah, gnative2ascii, gorbd, grmid, grmiregistry, gserialver and gtnameserv. Runtime interface changes: * gnu.java.lang.management.VMThreadMXBeanImpl has gained three new optional native methods to allow the 1.6 version of the threading bean to be supported. One (getMonitorInfo) fills in information about object monitor locks held by a thread and is only required if the monitoring of object monitor locks is supported by the VM. The other two (findDeadlockedThreads and getLockInfo) are related to ownable synchronizers (part of the java.util.concurrent suite) and only required if monitoring of locks relating to these is supported by the VM. * java.util.VMTimeZone and java.util.TimeZone have been refactored to simplify the reference implementation. VMTimeZone.readtzFile() and VMTimeZone.skipFully() have been removed, and a new method VMTimeZone.readSysconfigClockFile() has been introduced. * VMs need to set the system property gnu.java.util.zoneinfo.dir to point to the directory where zoneinfo files live. In libgcj this is set to the value of the TZDATA environment variable, or /usr/share/zoneinfo if this is not set. * VMFile has been extended to support new 1.6 methods (canExecute, setReadable, setWritable, setExecutable). The following people helped with this release: Andreas Tobler, Andrew Haley, Andrew John Hughes, Cameron McCormack, Casey Marshall, Chris Burdess, Christian Thalinger, Dalibor Topic, David Daney, Edwin Steiner, Francis Kung, Gary Benson, Ito Kazumitsu, Jakub Jelinek, Jeroen Frijters, Keith Seitz, Kyle Galloway, Marco Trudel, Mario Torre, Mark Wielaard, Matthias Klose, Petteri Raty, Rafael Teixeira, Raif S. Naffah, Roman Kennke, Stepan Kasal, Sven de Marothy, Tania Bento, Thomas Fitzsimmons and Tom Tromey We would also like to thank the numerous bug reporters and testers! signature.asc Description: This is a digitally signed message part
[commit-cp] classpath ChangeLog doc/www.gnu.org/newsitems.t...
CVSROOT:/cvsroot/classpath Module name:classpath Changes by: Mark Wielaard mark07/04/23 12:52:12 Modified files: . : ChangeLog doc/www.gnu.org: newsitems.txt doc/www.gnu.org/downloads: downloads.wml Added files: doc/www.gnu.org/announce: 20070423.wml Log message: * doc/www.gnu.org/newsitems.txt: Add 0.95. * doc/www.gnu.org/downloads/downloads.wml: Likewise. * doc/www.gnu.org/announce/20070423.wml: New file. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.9283r2=1.9284 http://cvs.savannah.gnu.org/viewcvs/classpath/doc/www.gnu.org/newsitems.txt?cvsroot=classpathr1=1.42r2=1.43 http://cvs.savannah.gnu.org/viewcvs/classpath/doc/www.gnu.org/announce/20070423.wml?cvsroot=classpathrev=1.1 http://cvs.savannah.gnu.org/viewcvs/classpath/doc/www.gnu.org/downloads/downloads.wml?cvsroot=classpathr1=1.20r2=1.21
Re: Compilation Time
On Mon, 2007-04-23 at 09:33 -0600, Tom Tromey wrote: Martin == Martin Schlienger [EMAIL PROTECTED] writes: Martin Each time we change the ClassLoader.java class, compilation Martin lasts quite a long and I am not really convinced that Martin everything need to be recompiled. I am quite a beginner with Martin Makefile but it seems that no real check is done and Martin everything is compiled by default. Martin Maybe you can give me some tricks on that or tell me what method you Martin use when hacking Classpath. IMNSHO, the best way to do incremental development on Classpath is to use Eclipse. It will only recompile the minimum necessary when you make a change. There a HOWTO for setting this up on the wiki -- it isn't as trivial as we would like, but it is doable, and once you have it set up you rarely have to tweak it. That page is here btw: http://developer.classpath.org/mediation/ClasspathHackingWithEclipse It is slightly easier than described there now that the CDT is usually available in most distros out of the box. It sounds like an interesting hack to the ClassLoader. Please do let us know how it works out. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: Mingw32 port
Hi Chris, On Wed, 2007-04-25 at 10:29 -0400, Chris Cole wrote: My diffs for mingw32 port have been mailed to classpath-patches. I believe that my mail is being held pending list-moderator approval due to their heft. Yep, write smaller patches please :) They should appear any second now on the list. Sorry about the delay. Thanks for going through the paperwork for this contribution. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: Bug 32030, RandomAccessFile truncates on rw access
Hi Robin, On Wed, 2007-05-30 at 16:57 +1000, Robin Garner wrote: Steve Blackburn reported this bug a week ago, including a regression test and a patch. Could someone take a look at it - it fixes our major outstanding bug with dacapo eclipse on JikesRVM, and looks like a pretty important bug to fix. Thanks for the reminder and sorry for not following up on this earlier. Mauve tests have been added and Steve's fix has been applied. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: OpenJDK, CLasspath - where are things happening?
On Sun, 2007-06-03 at 04:21 +0200, Thorbjørn Ravn Andersen wrote: I was very excited by the release of OpenJDK under GPL, and was expecting the Classpath community to rise to the occasion and basically select the best tidbits for a common merge. Which is basically what is happening in the background, see the work by the JNode team or IKVM, but things take some time. It isn't always simple mix-and-match. And people have their current projects to take care of. GNU Classpath is used by so many projects that we do keep fixing and improving it as is, not everybody has been upgraded to our latest 0.95 release for example. I have been reluctant to contribute to any Java clone simply because the JVM's we are using are all Sun based, so it would not be beneficial to me - that is before now. I would therefore like to know what has happened. Is Classpath being abandoned as everybody is flocking to the openjdk forums? Is everybody just talking over IRC? Or something else? There is some coordination work being done on some of the openjdk lists and on irc. There are many many openjdk lists, so you have to search a little to get all the threads. See http://blogs.sun.com/tmarble/date/20070531 Big picture overviews can generally be found on http://planet.classpath.org/ I built the OpenJDK under Linux, just to see it was possible. The first thing I wondered about was that the Java code was built by Make instead of Ant, so already there there is a great deal of possible improvements. :) I am not sure inserting ant in the build process will improve things. But autoconfiscating openjdk would be nice. A bigger problem is that there all these binary blobs that need to be replaced before it really is buildable on and as a free software project. But there are some people working on replacements to get things going. Cheers, Mark
Re: OpenJDK, CLasspath - where are things happening?
On Sun, 2007-06-03 at 10:38 +0100, Andrew Haley wrote: Mark Wielaard writes: :) I am not sure inserting ant in the build process will improve things. Me either. I'd like to fix the build dependencies so that make -j could speed things up on machines with many processors, but switching to Ant wouldn't help that at all. But autoconfiscating openjdk would be nice. That would effectively be a fork, unless we could persuade upstream to accept autoconf as well. What would the benefits of autoconf be? It would potentially make it much more portable like we have with for example gnu classpath gcj (although I keep seeing complaints on other lists from people who cannot make things work on things like solaris or aix - please report those bugs upstream people! - so maybe these days autoconf isn't as sure proof a way to get things portable as it used to be, or maybe GNU/Linux really is the only interesting posix-like system left). But, yeah, it was also a bit of a joke, I regard antifiscation and autoconfiscation equally likely to happen (although at least the later seems to be in the works by at least Andrew and Dalibor for the tools and javac in openjdk). Cheers, Mark signature.asc Description: This is a digitally signed message part
Meeting with the Bobs (legal Q/A)
Hi all, I have finally setup a meeting Monday evening with two FSLC lawyers and Brett Smith from the FSF to clear up any legal issues/questions we might still have with GNU Classpath vs OpenJDK. Sorry this took some time, but people were really busy on getting the final call draft of GPLv3 out the door (go read it, it looks really good, but this is the last chance to get things changed/cleared up if you have any doubts with respect to GPLv3: http://gplv3.fsf.org/). And I really wanted to make sure I knew what people wanted to do with respect to the various projects before making any lawyers jump through hoops. I explained that GNU Classpath is as much a specific GNU project with a specific technical goal of providing a core class library (plus tools now) for the java programming language. A project that is an official GNU project with the FSF as legal guardian. As it is a social group, that we often refer to as GNU Classpath Friends. Which is a loose conglomerate of projects and people around the GNU Classpath code base and related projects. Which is why I explicitly asked the Software Freedom Law Center to help both the FSF/GNU project as the community at large with legal advise. Looking at what people are already working on I can see that people will move forward anyway, even without waiting for the lawyers to proclaim that we are in the clear :) And that is how it should be, the project must provide the (safe and legal) framework for the community to do their thing, not the other way around. Everybody is pretty enthusiastic helping out making sure our communities can keep working together and moving forward. And making sure we can all cooperate with Sun's GPLed openjdk java effort in any way you feel appropriate. The general feeling was that there was some due diligence to do, but no major obstacles. Our goals are to be able to use all or parts of openjdk for keeping innovating the GNU Classpath Friends projects that currently exist, being able to contribute to openjdk in a way that is safe for the community (the general feeling seem to be that there is a trust in Sun at this moment, they have already changed the language of their contributor agreement based on recommendations from us, but we do want to be careful), and being able to use and recommend openjdk as a full free java platform (after replacing any troublesome parts with GNU Classpath code) so we can turn the java reference implementation that is used all over the world into a pool and seed for a new GPLed Java world that will ultimately help us innovate through the projects we all love to work on. So based on that I'll try to get us a (hopefully quick) timeline on legal advise on the SCA agreement, interaction of the SCA with the FSF paperwork, grantback process to follow if wanted, distributing classpath-dropin-replacement packages to solve any encumbrances in openjdk, analysis of the Assembly Exception in openjdk, GPLv2-only vs GPLv2-or-later, GPLv3 and the classpath exception interaction, analysis of external code and list of licenses in THIRD_PARTY_README from openjdk. To keep things contained I am not seeking any legal advise on trademarks or jcp and tck issues for now, since those are more questions for Sun to clear up than for the community to make a decision on (the status on those didn't really change, we are, and always have been, all about source code in the first place, just like openjdk is, so lets concentrate on that for now). Please let me know if I forgot any specific issue and I try to get it on the agenda Monday evening and hopefully get us all some advise soon. Cheers, Mark
Re: How is mauve ran on builder.classpath.org?
Hi Timo, On Wed, 2007-06-06 at 14:11 +0300, Timo Juhani Lindfors wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32082 is an example of a mauve testcase that fails on my own computer but apparently passes on builder.classpath.org. It also seems to run fine on my machine. I do see the java.awt.Graphics.clearRect FAIL though. I'd like to hunt the bug more but I can only guess how builder runs the tests. The testframework scripts running on builder are actually available from CVS: http://sources.redhat.com/cgi-bin/cvsweb.cgi/builder/?cvsroot=mauve HTTP headers suggest it runs debian. Could somebody with an account on builder provide me an output of dpkg -l? Attached. It is a Debian stable (3.0/etch) system btw. Of course, In the perfect world builder would just export its hard disk image and I could reproduce the bug with qemu ;-) Exporting the whole disk image might not be practical. But if there is anything useful you would like to see exposed through http please yell. Cheers, Mark packages.list.gz Description: GNU Zip compressed data
Experimental Build Repository at icedtea.classpath.org
This announcement might be exciting news for some. IcedTea is basically a OpenJDK/GNU Classpath hybrid that can be used to bootstrap OpenJDK using only Free Software. You will need the latest gcj ecj versions (Fedora 7 has them, but build instructions for other GNU/Linux distros more than welcome of course) to play with it. We agreed to host it at http://icedtea.classpath.org/ because it is such a valuable effort for the whole libre java community. But IcedTea isn't an official GNU Classpath effort. Participants are encouraged to push all their changes upstream into classpath and openjdk. It is basically a staging area for people to play with till all legal and technical issues of merging the code bases have been worked out. Please join the openjdk distro-dev mailinglist to discuss this effort. http://mail.openjdk.java.net/mailman/listinfo/distro-pkg-dev ---BeginMessage--- At the present time it's not possible to build a fully Free Software version of OpenJDK, because of the presence of some binary plugs. Quoting http://openjdk.java.net/: Not all of the source code that makes up the JDK is available under an open-source license. In order to build an OpenJDK binary from source code, you must first download and install one or more of the following files from which the build process will copy over 'binary plugs' for these encumbered components. In addition to this, it's necessary to download an unfree JDK to build OpenJDK. We have been working within Red Hat to replace these binary plugs with free software based on GNU Classpath and to remove the need for bootstrapping with unfree software. This is important for a number of reasons, the most pressing being that only free software may be used to build operating systems like Fedora. We intend this build repository, based on OpenJDK, to provide a basis on which to experiment. It's not a fork from OpenJDK, and doesn't contain the OpenJDK source code. We have used the name IcedTea because JDK and OpenJDK are trademarks and we wish to make it perfectly clear that, while this project uses source code from the OpenJDK project, it is not OpenJDK. I'm sure some people will wonder why we've set up this repository rather than submitting our replacements for the binary plugs to openjdk.java.net. Sun hasn't set up a Mercurial repository yet, and we need a public version control system system to work in. Also, this is not mature tested code, it's an experiment. We've been doing this experiment inside Red Hat, and we know from experience that working in the open is better than working behind closed doors. The next question that arises is will you be submitting these changes to the OpenJDK process? The answer is yes, we will, once the legal and technical issues are resolved. These binary plugs are not complete: they do not replicate all the functionality of the binary plugs used in the OpenJDK. If you need a fully-functional OpenJDK, follow the instructions on http://openjdk.java.net/. However, these binary plugs are sufficient to allow IcedTea to build itself without any software that is not free. It's important to show that we can do this, if only as a proof of concept. We'd like to thank the GNU Classpath hackers (and Jim Pick in particular) for sharing the infrastructure at classpath.org that makes this possible. And, of course, for writing the code in GNU Classpath. Andrew. To get started on a Fedora 7 GNU/Linux system with yum: $ sudo yum install /usr/bin/ecj mercurial cups-devel lesstif-devel libXp-devel xalan-j2 xerces-j2 libXt-devel libgcj Then: $ hg clone http://icedtea.classpath.org/hg/icedtea $ cd icedtea Full build instructions are in INSTALL, but this works for me: $ ./configure $ make When this completes you'll have a usable IcedTea in openjdk/control/build/linux-i586 or openjdk/control/build/linux-amd64. Alternatively, you can bootstrap by building IcedTea twice, once with ecj/gcj and then with IcedTea: $ make bootstrap -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 ---End Message---
Re: Experimental Build Repository at icedtea.classpath.org
Hi Stuart (CC [EMAIL PROTECTED]), On Sat, 2007-06-09 at 11:11 -0400, Stuart Ballard wrote: I thought it'd be interesting to see how IcedTea fares japiwise. I suppose that becomes less interesting if the stuff IcedTea is missing isn't reflected in the API itself, but still... That would be cool! But we currently don't have the build setup (currently investigating how to get it all going on Debian 3.0/Etch, because people have till now only used Fedora 7 to bootstrap, but almost all our classpath infrastructure machines are Debian based) nor do we really have the capacity to do such a massive build, but maybe we can add it to builder.classpath.org later on. So you will have to do with compiling from source yourself for now. Japi-wise it really is more-or-less fully complete with respect to the public api (but since some things aren't fully connected between the openjdk and classpath parts and some small parts are stubbed, only the non-gui parts really work well). Results would of course still be cool because it would capture api-changes between the official 1.6 and icedtea. Hopefully we can keep using your JDK matrix for that for now http://sab39.netreach.com/Software/Japitools/JDK_Results/46/ The JDK 7 Beta part should be more or less identical to what Icedtea would give. At a certain point I suspect an OpenJDK/Icedtea branch that focuses on getting a full JDK6-like GPL build will emerge and then we definitely want to add that to japi of course. Cheers, Mark
legal/policy questions (Was: [cp-patches] RFC: AWT Peers update)
Hi, Moving to the main list. On Fri, 2007-06-22 at 11:40 +0200, Dalibor Topic wrote: Mark Wielaard wrote: And the plan always was to upgrade to gplv3 because it provides some much needed improvements. I'll have a meeting with Eben Moglen this weekend where I will discuss this and other pending legal issues. But it would be nice to get some assurance from Sun that they also want to upgrade. [... lots of bad scenarios ...] Sorry for coming up with worst case scenarios but I figured if you are meeting Eben, we could get them all out of the way at once. :) Thanks and indeed we should. So if anybody else has any scenarios and would like feedback then please ping me and I try to sneak them in the conversation I will have tomorrow. I don't know how much time I have and there is already a list of legal/policy issues to go through with respect to classpath/openjdk but I can always try. Cheers, Mark
Re: legal/policy questions (Was: [cp-patches] RFC: AWT Peers update)
On Fri, 2007-06-22 at 11:36 -0400, Stuart Ballard wrote: On 6/22/07, Mark Wielaard [EMAIL PROTECTED] wrote: Thanks and indeed we should. So if anybody else has any scenarios and would like feedback then please ping me and I try to sneak them in the conversation I will have tomorrow. I don't know how much time I have and there is already a list of legal/policy issues to go through with respect to classpath/openjdk but I can always try. Do you have this list of issues in an easily-postable form? I think that if so seeing the list would be helpful to the discussion, both from the perspective of avoiding duplication, and because the items already on the list might inspire someone to think of a new one. Yeah, but we are not really looking for new trouble :) More for solutions to specific concrete issues. I am in the train now and don't have access to the archives, but see Dalibor's message on classpath-patches [RFC: AWT Peers update] and my previous message on this list [Meeting with the Bobs (legal Q/A)] (which also had a list of issues we are not exploring at the moment). Most of this isn't really that interesting it is mostly boring legal bureaucratic checking all terms and conditions of all the openjdk stuff (see the huge list of 40+ external code all with slightly different conditions in THIRD_PARTY_README of openjdk) and determining which combinations of all those licenses are compatible with GPLv2, GPLv3 and the exception statements. Double checking the files not mentioned in the THIRD_PARTY_README, most of which are fine and the few files having wrong notices have already been reported to Sun and are in the process to be fixed (policy here is to first inform Sun to check whether it is a misunderstanding or oversight). Then there is the procedure to follow if people would want to have a grantback of rights as allowed under FSF contracts (people for who this is an issue are already in contact with me), how such grantbacks interact with the SCA that Sun requires, hopefully get some advise on the SCA and how strong it is for the community to trust Sun to participate nicely in the future, whether gpl +exception packages from classpath could be distributed together with the openjdk code, procedures to follow when distributing such split-up classpath, how to orderly upgrade to GPLv3 (plus exception) next month as the GNU Classpath, GCC/GCJ and some of the Kaffe hackers have said they wanted, but what are the implications if Sun decides not to upgrade openjdk (since they explicitly choose GPLv2-only, but with the classpath-exception for large parts of the core class libraries), what are the implications for Apache compatibility, etc. When all those issues are answered and/or advise is given how to make such issues easy to resolve then there is a second phase of defining policy based on the outcome (note that the SFLC legal people can analyze and give advise on legal matters, but they don't have a legal-magic-wand to just make any issue just disappear if it comes up). But that is then up to the individual contributors, the FSF, Sun, and the various projects. It is important to note that the FSF is slightly restricted by the 140+ companies and individuals that it has signed contracts with over the years about their contributions to GNU Classpath and GCJ (saying their contribution will always remain free software) and Sun is slightly constraint by their demand to have a bit more rights than the community at large to only include contributions to openjdk which they can explicitly turn proprietary to hand over to their partners. Neither is super flexible and they have somewhat different goals, which is why I explicitly asked the SFLC to give advise both to the FSF/GNU project and to the larger GNU Classpath Friends community/projects. One last note is that everybody is super busy pushing out GPLv3 end of this month. And that although Eben has been briefed about the ongoing stuff by the SFLC lawyers who are helping us, this meeting was more of a chance since he happened to come through the Netherlands. I don't know how much time he has, or if I can get more out of him than an acknowledgment of the issues. But I thought I should at least try to get to talk to him to get a sense of how quickly we can move forward with this all. Cheers, Mark
Re: NPE in gnu.xml.transform.WithParam.getValue
On Sun, 2007-06-24 at 14:12 +0200, Christian Thalinger wrote: When building HotSpot in OpenJDK with CACAO I get this NPE: /home/twisti/tmp/cacao/bin/java -classpath /home/twisti/cacao/sun/openjdk/jdk/control/build/linux-amd64-debug/hotspot/outputdir/linux_amd64_compiler2/jvmg/../generated/jvmtifiles jvmtiGen -IN /home/twisti/cacao/sun/openjdk/jdk/hotspot/src/share/vm/prims/jvmti.xml -XSL /home/twisti/cacao/sun/openjdk/jdk/hotspot/src/share/vm/prims/jvmtiEnter.xsl -OUT /home/twisti/cacao/sun/openjdk/jdk/control/build/linux-amd64-debug/hotspot/outputdir/linux_amd64_compiler2/jvmg/../generated/jvmtifiles/jvmtiEnter.cpp -PARAM interface jvmti Exception in thread main java.lang.NullPointerException at gnu.xml.transform.WithParam.getValue(WithParam.java:89) at gnu.xml.transform.ApplyTemplatesNode.doApply(ApplyTemplatesNode.java:112) at gnu.xml.transform.TemplateNode.apply(TemplateNode.java:79) at gnu.xml.transform.TextNode.doApply(TextNode.java:102) snip Does anyone know what the problem is? Do you have more context? (pun intended) The part of the stacktrace you posted just pushes a 'null' context reference around which is dereferenced and generates the NullPointerException in the end. We need to see more to know why context is null in the first place. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: Float/Double compare
Hi Ian,
On Sat, 2007-06-30 at 15:25 -0400, Ian Rogers wrote:
public static int compare(float x, float y)
{
int ix = floatAsIntBits(x);
int iy = floatAsIntBits(y);
if (ix == iy) return 0;
if (isNaN(x)) return 1;
if (isNaN(y)) return -1;
int ix_sign = ix31;
int iy_sign = iy31;
if (ix_sign == iy_sign) {
return x y ? 1 : -1;
} else {
return ix_sign - iy_sign;
}
}
I am not really comfortable with writing this as is since unless the
compiler is smart you will do a multiple isNaN() and floatToIntBits()
calls even if not necessary. Could we try to do something smarter and
factor some of this out like:
// First check for NaNs
if (x != x || y != y)
{
int ix = floatToIntBits(x);
int iy = floatToIntBits(y);
if (ix == iy)
return 0;
if (x != x)
return 1;
if (y != y)
return -1;
}
else
{
// Normal cases, or positive/negative zeros
if (x y)
return 1;
if (y x)
return -1;
// Either equal or positive/negative zeros
if (x == 0 y == 0)
{
int ix = floatToIntBits(x);
int iy = floatToIntBits(y);
int ix_sign = ix 31;
int iy_sign = iy 31;
return ix_sign - iy_sign;
}
return 0;
}
But maybe I am not giving the compiler/jit enough credit for actually
producing such an optimized version in the first place. And this isn't
actually the same as your code since I moved the NaN checks first again.
The above assumes the NaN test (x != x) is relatively cheap since NaN is
a canonical value is java. That might be a wrong assumption. You might
be able to do something more clever with the actual ordering of floats
according to (since if any argument is NaN or both are zero it
evaluates to false) or with the ordering of floatToIntBits, but my head
was spinning trying to keep all the corner cases right (this calls for
expanding the Mauve Float.compareTo() test).
There may be a bug I can't see in this code :-)
Same with mine (I admit to not even having tried to compile it...)
Cheers,
Mark
