August 2008 - challenge-discuss

OpenJDK Innovators' Challenge Update
by Ray Gans 25 Aug '08

25 Aug '08

The judging of projects has been completed and winners have been selected. It is taking a bit longer than we had hoped to go through the legal review (i.e., verifying winners are all eligible per contest rules) but we should be informing them all shortly. Public announcement may be delayed a few weeks to coincide with announcement of all the Community Innovation Awards http://www.sun.com/software/opensource/awards/index.jsp ....so I apologize for the delay. Pleased stay tuned. Thanks again to everyone who participated. -Ray

3 3

XRender pipeline - updated benchmark analysis
by Clemens Eisserer 14 Aug '08

14 Aug '08

Hello, The benchmark results submitted as part of the project documentation for the XRender pipeline project showed not that impressive results for swing benchmarks (the non-remote cases) and small operations (e.g. 20x20 image tests). I did extensive profiling to find the causes and one major problem seems to be very high per-primitive costs in Xorg-server-1.5 (caused by an expensive implementation of dixLookupPrivate). A fix is already in the works. A more detailed analysis can be found in the updated benchmarks.html attached. Thanks, Clemens

1 0

challenge
by Mario Torre 14 Aug '08

14 Aug '08

Hi! I just wanted to say congratulations to the finalist! My experience was very great with the challenge, and we surely had lot of fun in doing it. I hope that this was the same for anyone. A big thank you to Sun for giving us the opportunity to study the code and propose our own ideas, this was also another great moment of sharing within the Classpath community and the OpenJDK community (I think I can really say that now we are the *same* community!) Thanks, Mario -- Mario Torre, Software Developer, http://www.jroller.com/neugens/ aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-53 pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim Geschäftsführer: Dr. James J. Hunt Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/

3 2

Small fixlet
by Mario Torre 08 Aug '08

08 Aug '08

Dear Judges, Dear List, I would like to submit this small fix to our repository on java.net. The fix does not add new code, just removes one patch that can cause a StackOverflow. If you think we should not be allowed to push this patch, in order to still be able to test our code, please, do *not* apply "SunGraphicsEnvironment-cleanup.patch" to the patch queue. In case you prefer to use our branched repository, we will upload the fix shortly. Thanks, Mario -- Mario Torre, Software Developer, http://www.jroller.com/neugens/ aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-53 pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim Geschäftsführer: Dr. James J. Hunt Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/

3 2

Small fixlet
by Mario Torre 06 Aug '08

06 Aug '08

Dear Judges, Dear List, I would like to submit this small fix to our repository on java.net. The fix does not add new code, just removes one patch that can cause a StackOverflow. If you think we should not be allowed to push this patch, in order to still be able to test our code, please, do *not* apply "SunGraphicsEnvironment-cleanup.patch" to the patch queue. In case you prefer to use our branched repository, we will upload the fix shortly. Thanks, Mario -- Mario Torre, Software Developer, http://www.jroller.com/neugens/ aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-53 pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim Geschäftsführer: Dr. James J. Hunt Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/

1 0

FINAL PROJECT: Common Virtual Machine Interface
by Andrew John Hughes 05 Aug '08

05 Aug '08

Dear all, This e-mail constitutes the submission of the CVMI project for the OpenJDK challenge. The main source of documentation for this project is currently: http://fuseyism.com/openjdk/cvmi and the two Mercurial repositories: http://hg.openjdk.java.net/cvmi/cvmi http://fuseyism.com/hg/jamvm The first repository contains an OpenJDK tree with changes made in experimentation with a new CVMI variant. At present, this is just a proof of concept, java.lang.Object/java.lang.VMObject as there is still more work to be done in this area. The second contains a port of JamVM to the OpenJDK VM interface. This is nearly at the point of being able to start a HelloWorld application (it gets as far as trying to load in some of the non-existent VM methods in OpenJDK, having initialised JNI, threads, etc.). Changes on the CVMI port will hopefully complete this work. I'd like to close this mail by thanking Sun and the OpenJDK community for the opportunity to participate in this challenge. I had hoped to produce more in the way of code, but time has unfortunately not been on my side. However, I feel much more benefit has been gained from having the opportunity to work on the OpenJDK codebase and that the documentation I have produced so far and my own expanded knowledge will turn out to be the more valuable product of this challenge. Back at the start of the challenge period, I had very little knowledge of the OpenJDK source code. Since then, I have also worked a lot with the IcedTea hackers, patching and building this code base and although this isn't an explicit product of this challenge, this has resulted in an up-to-date IcedTea tree for JDK7, thus easing the process of working on OpenJDK and allowing further experimentation with new ideas. My hope is that this project can continue post-challenge, and that the end of this period will now allow others to get involved and truly produce a VM interface we can all benefit from. Thanks again, -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

1 1

FINAL PROJECT: Provide date and time library from JSR-310
by Stephen Colebourne 05 Aug '08

05 Aug '08

The JSR-310 team of Michael and myself are pleased to submit our final project for the OpenJDK challenge. Full details about the submitted project are available online at: https://jsr-310.dev.java.net/source/browse/jsr-310/tags/OpenJDKChallenge/Op… This contains hyperlinks to all the major resources. The full codebase being submitted is a tagged subversion repository at java.net (java.net login required): https://jsr-310.dev.java.net/svn/jsr-310/tags/OpenJDKChallenge This can be browsed online at (no login required): https://jsr-310.dev.java.net/source/browse/jsr-310/tags/OpenJDKChallenge/ For reference, the subversion repository before the start of the project stage was at revision 285 (it is now 560): https://jsr-310.dev.java.net/source/browse/jsr-310/trunk/jsr-310-ri/?rev=285 We've tried to aid evaluation with the provision of an ant build (including fetching libraries, compilation, tests and coverage). We have also built online javadoc and an example program runnable using 'ant examples'. Thanks, Michael and Stephen

2 2

FINAL PROJECT: Closures for Java
by Neal Gafter 05 Aug '08

05 Aug '08

This is a final submission for the Closures for Java project described at http://mail.openjdk.java.net/pipermail/challenge-discuss/2008-February/0000… HOW TO ACCESS THE CODE: The complete implementation may be found in the openjdk Mercurial forest at ssh://hg.openjdk.java.net/closures/closures/ The forest can also be found on the openjdk mercurial website at http://hg.openjdk.java.net/closures/closures/ Most of the changes for this project are found in the langtools tree, though there are some changes to supporting libraries in the jdk tree. A binary build of the project, suitable for use with an existing Java SE 5 or Java SE 6 platform implementation, may be found at http://www.javac.info/closures.tar.gz Other resources relating to the project can be found on the website http://www.javac.info/ As an openjdk Project, copyrights in these sources have been contributed to Sun Microsystems under the terms of the SCA. The implementation supports all features described in the specification and noted in the project proposal. Based on community feedback, there are some changes reflected in the implementation suitable for inclusion in a revision of the prototype, including the addition of support for "method references". For details of the differences from the specification, see http://www.javac.info/PrototypeDifferences.html which is also included, below. =================== Differences Between the Prototype and the Spec (v0.5) Here is a summary of the differences between the current prototype and the last published specification (v0.5). These changes reflect feedback from the user community and are suitable for inclusion in the next revision of the specification. * Renamed Unreachable to Nothing We adopt the name used by Scala to represent the same concept. * Removed support for the type null We used null as a placeholder for an exception type when none can be thrown. The type Nothing now serves that purpose; null is no longer supported as the name of a type. * Overhauled restricted versus unrestricted In the specification, an interface is considered restricted if it extends a marker interface. Unfortunately, the specification only provides a syntax for function type interfaces that are unrestricted. We modified the syntax so that a function type written using the => token designates a restricted function type, while one written using the newly introduced ==> token represents an unrestricted function type. This allows programmers to easily write APIs that restrict (or don't restrict) the operations of closure expressions passed as parameters. * Refined restrictions We modified the distinction between restricted and unrestricted closures. As before, it is not legal to convert an unrestricted closure to a restricted interface type, nor is it legal to break, continue, or return from inside a restricted closure to a target outside the closure. However, a restricted closure is allowed to refer to a non-final local variable from an enclosing scope. In this case a warning is given unless one of the following conditions holds: 1. The variable is not the target of any assignment, or 2. The variable is annotated @Shared It is possible to suppress the warning by annotating some enclosing construct @SuppressWarnings("shared"). * Relaxed the closure conversion In response to user feedback, we've relaxed the relationship between a closure parameter's type and the target interface's parameter type. Rather than requiring them to be of the same type, they are now allowed to be related by an assignment conversion, including boxing or unboxing. * for-qualified method declarations The for keyword on a method declaration, meant to introduce a control abstraction method that works like a loop, is now treated syntactically like a modifier rather than appearing immediately before the method name. This helps make the declaration site more similar to the use site. * Added support for method references We added extensive support for treating a reference to a method as a closure using a newly introduced token #. The syntax is borrowed from the FCM proposal. The semantics are as follows: A method reference written as Primary # Identifier ( TypeList ) where the Primary designates an expression (as opposed to a type) is treated the same as a closure { Type x0, Type x1 ... => tmp.Identifier(x0, x1 ...) } or { Type x0, Type x1 ... => tmp.Identifier(x0, x1 ...); } Where tmp is a temporary value that holds the computed value of the primary expression. The former translation is used when the resolved method has a non-void return type, while the latter is used when the resolved method has a void return type. If the primary resolves to a type, then this is translated to { Type x0, Type x1 ... => Primary.Identifier(x0, x1 ...) } or { Type x0, Type x1 ... => Primary.Identifier(x0, x1 ...); } when the resolved method is static, or { Primary x, Type x0, Type x1 ... => x.Identifier(x0, x1 ...) } or { Primary x, Type x0, Type x1 ... => x.Identifier(x0, x1 ...); } when the resolved method is an instance method. In addition, optional explicit type arguments, between angle brackets, may be placed immediately after the # token. These are used directly in the translated method invocation to resolve the method to be invoked. * Implemented a classfile format for the for qualifier We've impleemnted a class file representation of the for qualifier to support separate compilation.

1 0

FINAL PROJECT: Free Software synthesizer implementation for the OpenJDK project
by Karl Helgason 05 Aug '08

05 Aug '08

Here is a brief status report on the Gervill Synthesizer which is hereby submitted as a final project for the OpenJDK challenge. At the May 30, [1] Gervill Synthesizer was released as part of OpenJDK 6 b10. And this meant the SMNP was only encumbrances left. And at that same time IcedTea project had already incorporated Gervill. [2] On June 19 it was reported that IcedTea project has passed the Java Test Compatibility Kit (TCK) and that meant it behaved just like any Java 6 implementation. [3] And Gervill Synthesizer was one of key elements to enable IcedTea pass the TCK. Gervill Synthesizer was also in the highlight at the JavaOne 2008, when it was shown how easy it was to use Gervill at the JFugue Talk [4]. There was shown that having the SoundFont support enabled playing Midi Files in High Quality using High Quality Soundfont. At the Midi.Org web forumn it was noticed that Gervill Synthesizer is the "only" or one of few synthesizer known to fully response to all MIDI Tuning messages. [5] Currently an updated version of Gervill will be released as part of OpenJDK 6 b12. [6] Access to source code, tests, change log, documentation is available at the Gervill Project Homepage: https://gervill.dev.java.net Communication regarding this project can be found at following mailing lists: http://mail.openjdk.java.net/mailman/listinfo/audio-engine-dev http://mail.openjdk.java.net/mailman/listinfo/sound-dev http://mail.openjdk.java.net/mailman/listinfo/distro-pkg-dev http://mail.openjdk.java.net/mailman/listinfo/jdk6-dev Regards, Karl Helgason --- [1] http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-June/000060.html [2] http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2008-April/001855.html [3] Java is finally Free and Open - http://blog.softwhere.org/archives/196 [4] JavaOne 2008, TS-5263, Jamming with Java Technology: Making Music with JFugue and JFrets - http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-5263&… [5] MIDI.org Web Forum › General Boards › MIDI Technology › misleading midi tuning specifications? - http://www.midi.org/cgi-local/forum/forum.pl?b-T_help/m-1203665116/s-all/ [6] http://mail.openjdk.java.net/pipermail/sound-dev/2008-July/000058.html

1 0

FINAL PROJECT : "Implement XRender pipeline for Java2D"
by Clemens Eisserer 05 Aug '08

05 Aug '08

Hello, This is the "FINAL PROJECT" email for the openjdk xrender project. * The sourcecode can be checked out from the project's mercurial repository located at: http://hg.openjdk.java.net/xrender/xrender/jdk/. Simply cloning the repository to the local hard disk using "hg clone http://hg.openjdk.java.net/xrender/xrender/jdk/" should be sufficient. * Project documentation and other project materials are located at the project page at: http://openjdk.java.net/projects/xrender/ The poject page contains instructions for building and enabling the pipeline, as well as benchmarks, documentation , ... * A "development diary" can be found on the project's blog, located at: http://linuxhippy.blogspot.com/ Thanks a lot, Clemens

1 0