From fabrizio.giudici at tidalwave.it Fri Feb 1 10:46:46 2008 From: fabrizio.giudici at tidalwave.it (Fabrizio Giudici) Date: Fri, 1 Feb 2008 19:46:46 +0100 Subject: Quick clarification Message-ID: Hello. Can you please clarify what "original idea" means? Should it be something that is brand new, or a project that has been already started can participate? Thanks. -- Fabrizio Giudici, Ph.D. - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog Fabrizio.Giudici at tidalwave.it - mobile: +39 348.150.6941 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/challenge-discuss/attachments/20080201/481f7665/attachment.html From wmeissner at gmail.com Fri Feb 1 23:16:38 2008 From: wmeissner at gmail.com (Wayne Meissner) Date: Sat, 2 Feb 2008 17:16:38 +1000 Subject: Draft Proposal - Java foreign function interface Message-ID: <4ccee320802012316nccd0993hfedcec9c271d5a57@mail.gmail.com> I'll preface this one by saying I'm not sure if this proposal meets the originality requirements (its mostly a re-implementation of existing ideas), nor if it is desirable for OpenJDK (some might call the idea heretical). But, until other proposals start showing up, I thought I'd get the ball rolling, and people could at least practice critiquing proposals :-) The proposal is far from complete, mostly at the "brain dump, slightly reformatted" stage. Draft Proposal - Java Foreign Function Interface 1.0 Outline This proposal is for a project to provide Java programmers with easier access to native libraries. Although JNI already provides programmers with access to native libraries, it has some drawbacks: a) It requires compilation of a native library for each potential target platform. This places an extra burden on developers. b) The complexity of JNI programming is greater than that of a pure java project. It is also usually more complex than the native APIs that the programmer wants to call. For many tasks, being able to access native APIs using java syntax, with all the hairy details of JNI programming hidden away would be a good thing. 2.0 Need. Although everyone would like to have 100% pure java libraries and programs, that is not practical if Java is to compete with e.g. C# as a modern desktop or systems programming language. There will always be native APIs that are not exposed in the current JRE and there will always be a lag between the latest JREand what the majority are using. Although JNI can be used to access native APIs, it is somewhat more complex than either java or the native APIs that programmers are trying to access, and as such presents a higher barrier of entry than programmers would desire. Although there is a viewpoint that this barrier encourages development of pure java libraries, in the case of highly complex native frameworks (e.g. media libraries), re-implementation in java is impractical. Another need is from the JRuby and Jython communities - where the ability to provide a more accurate implementation of the Ruby/Python environment to programs written in those languages would be eased by the ability to access the same native libraries that the original implementations of those languages allow. The benefit is not just restricted to implementation of JRuby/Jython features in Java - these languages will also be able to directly call native functions. Even within the JDK itself, having easier access to native libraries might enable faster feature implementation where access to native APIs is needed. 3.0 Concept Viability. The concept of simplified native library is not new - there are several projects, both commercial and open source. For example, the JNA project[1] has been used to successfully build bindings for the gstreamer multimedia framework. The resulting bindings are pure java (except for a dependency on JNA itself), and run without modification on Linux/x86, Linux/amd64, Windows/x86, MacOSX/x86, Solaris(x86, sparc, sparcv9) and FreeBSD/x86. The gstreamer-java[2] bindings also demonstrate that it is possible to produce reasonably performant native bindings using this method - the bindings can render video into a lightweight swing component at better-than DVD resolution, with no native code other than the common JNA stub. The JRuby project is also now using JNA to provide access to native libraries to Ruby programs so they can run un-altered on the JVM. Although the idea of providing direct access to native resources from java code might seem abhorrent to some, it is not without precedent. The sun.misc.Unsafe, java.nio.Bits classes already provide the ability to allocate, read and write native memory directly from java. 4.0 Proposal Details. This project proposes to implement a minimal set of java and JNI components that facilitate calling native functions directly from Java, and to enable java code to be called from native code (closures). Although the project will not include higher level C language features (e.g. structures, unions, custom mapping between java types and native types) it will provide sufficient functionality to allow these features to be implemented by other java libraries without requiring native code. 4.1 Dependencies The proposal depends on libffi - part of gcc, but licensed under a more liberal license than the GPL - for the low-level native dispatch functionality. [ What else should go in this section? Technical details. e.g. - exact description of what the java interface would look like? - what native types are supported as arguments? - gory details of the java->native argument marshalling/unmarshalling? - perceived advantages vs existing implementations? I did have a bunch of technical stuff here, including the above information, but it was basically a brain dump, and somewhat incoherent. ] 5.0 References: [1] JNA http://jna.dev.java.net [2] gstreamer-java http://code.google.com/p/gstreamer-java From Ray.Gans at Sun.COM Tue Feb 5 10:34:36 2008 From: Ray.Gans at Sun.COM (Ray Gans) Date: Tue, 05 Feb 2008 10:34:36 -0800 Subject: Quick clarification In-Reply-To: References: Message-ID: It does not have to be a new idea, submitting a proposal for an existing project is fine as long as it can be contributed under the SCA. We want to make sure that the first proposer of an idea gets priority treatment if identical proposals are made for the same idea. Since all proposals should be made available for open discussion in draft form, we want the original drafter to get the credit. On Feb 1, 2008, at 10:46 AM, Fabrizio Giudici wrote: > Hello. > > Can you please clarify what "original idea" means? Should it be > something that is brand new, or a project that has been already > started can participate? Thanks. > > -- > Fabrizio Giudici, Ph.D. - Java Architect, Project Manager > Tidalwave s.a.s. - "We make Java work. Everywhere." > weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog > Fabrizio.Giudici at tidalwave.it - mobile: +39 348.150.6941 > > From lafortune at users.sourceforge.net Wed Feb 6 11:06:08 2008 From: lafortune at users.sourceforge.net (Eric Lafortune) Date: Wed, 06 Feb 2008 20:06:08 +0100 Subject: FINAL PROPOSAL: An automatic process to shrink and optimize the OpenJDK run-time libraries Message-ID: <47AA0520.7040804@users.sourceforge.net> Staying in the spirit of the goals of this project, here's my short FINAL PROPOSAL An automatic process to shrink and optimize the OpenJDK run-time libraries Eric Lafortune 1. Summary ---------- The renewed enthusiasm for Java on the desktop and on the web has pushed the size of the Java run-time libraries into the limelight again. This project aims to create an automatic process to shrink and optimize the OpenJDK run-time libraries. Processing the entire set of run-time classes is far from trivial, essentially due to introspection and interaction with native code. However, early experiments show that it is feasible, and that such a process can achieve a significant reduction of the library sizes. The tool of choice in this process is ProGuard, a free shrinker, optimizer, obfuscator, and preverifier for java bytecode. ProGuard is already highly successful with developers of commercial software and software for constrained devices. As the developer of ProGuard, I have the required expertise to make this project a success. Experience gained in this project will benefit the ProGuard project as well. 2. Goals -------- The goals of this project are twofold: 1) Create an automatic process for shrinking, optimizing, and obfuscating the OpenJDK run-time libraries. The obvious result of this process are smaller libraries that continue to offer the same functionality with the same API. Smaller library sizes are beneficial for all Java users, with smaller code archives, faster download times, and smaller memory footprints. Notably, projects that build on the OpenJDK run-time libraries and that target constrained devices can apply the results directly. 2) More generally, gain experience in the automatic processing of the OpenJDK run-time libraries. The run-time libraries illustrate many common and less common code constructs. Notably, it contains many types and implementations of introspection. This knowledge may further the development of ProGuard and supporting tools, extending detection techniques and optimization strategies. It will also provide additional insights in the structure of the OpenJDK run-time classes. 3. Previous work ---------------- In the context of the size of the Java run-time environment, the Java Kernel project by Ethan Nicholas at Sun has been receiving a lot of positive interest recently. It mitigates the potentially long download time of the JRE, by partitioning the libraries into sets that are downloaded individually and as needed. This proposed project attacks the heart of the problem: the size of the run-time libraries. The idea of automatically optimizing the library sizes is not new. Yet, somewhat surprisingly, there are no reports of successful attempts. Only the section with results on the ProGuard website presents some experimental results. ProGuard is a free Java class file shrinker, optimizer, obfuscator, and preverifier, available under the terms of the GPL: http://proguard.sourceforge.net/ In this experiment, ProGuard processed the Java 6 run-time libraries. The configuration was composed by myself, based on debug output, instrumentation, trial and error, custom tools, experience, and some old-fashioned hacking. Its length of more than 1500 lines provides an indication of the complexity of the problem. The combined shrinking, optimization, and obfuscation reduces the total library size by an impressive 66% (from 53 MB to 18 MB). The resulting run-time environment is still perfectly capable of running ProGuard and the ProGuard GUI, for instance. However, one can expect the configuration to be incomplete. As a result, ProGuard is undoubtedly optimizing away classes, fields, and methods that other applications require. Further investigations and work are therefore required. 4. Approach ----------- The planning consists of a number of steps, iterating when necessary: 1) Starting point: As mentioned in the previous section, an internal, experimental ProGuard configuration for processing the Java 6 run-time classes already exists. The project will start from this configuration. 2) Development: Since the OpenJDK has been released under the GPL, it is now possible to review and to instrument the source code of the run-time environment. The project will make full use of these possibilities, for extending the initial ProGuard configuration. 3) Testing: At the same time, Sun's Java Compatibility Kit is becoming available under an open license. This license encourages testing run-time environments that are derived from the OpenJDK. This is a perfect match for this project, so the JCK will be used for testing the processed run-time libraries. Once the processed run-time libraries pass the tests of the JCK, they can be confidently used as compact drop-in replacements for the original set of libraries. 4) Evaluation: The results will then be summarized, providing test results, statistics, and configurations. The most interesting statistic should be the final size of the processed libraries. The configurations will allow to reproduce all results. 5. Deliverables --------------- The success of the project will be measured by its final deliverables: 1) Any custom tools and procedures that were developed to generate the processing configurations. 2) The ProGuard configurations that allow to successfully shrink and optimize the OpenJDK run-time libraries. 3) For reference, the actual processed OpenJDK run-time libraries that are generated using the above configurations. 4) The test results of the Java Compatibility Kit that demonstrate the conformance of the processed OpenJDK run-time libraries. 5) A final report that evaluates the results and provides additional statistics. 6. Developer ------------ Eric Lafortune has received a PhD in computer science from the Katholieke Universiteit Leuven, Belgium. He has then worked as a post-doc at Cornell University's Program of Computer Graphics. He is currently working at Luciad, a company that develops high-performance software for GIS in Java. He has been developing and maintaining ProGuard in his spare time, since 2002. 7. Prize -------- If this project gets awarded, the associated prize will go to the work of sister Jeanne Devos: http://zusterjeannedevos.org/JDenglish/index%20JDengels.html From linuxhippy at gmail.com Thu Feb 7 05:46:25 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Thu, 7 Feb 2008 14:46:25 +0100 Subject: Are residents of Austria not allowed to participate? Message-ID: <194f62550802070546r60218b6al48197efdcaa66286@mail.gmail.com> Hi again, I just read that Austria is not in the list of the countries allowed to participiate. Austria is in terms of law quite equal to Germany and is member of the EU since 1995 (and of the EG longer than I can think of). So are Austrians really not allowed to participiate, or, was Austria just forgotten because its too small? If it has just not been considered important enough, is there any chance to get Austria in the list? (Italy, Germany, Poland, ... are also there) Thanks, lg Clemens From Richard.Sands at Sun.COM Thu Feb 7 06:15:38 2008 From: Richard.Sands at Sun.COM (Rich Sands) Date: Thu, 07 Feb 2008 09:15:38 -0500 Subject: Are residents of Austria not allowed to participate? In-Reply-To: <194f62550802070546r60218b6al48197efdcaa66286@mail.gmail.com> References: <194f62550802070546r60218b6al48197efdcaa66286@mail.gmail.com> Message-ID: <47AB128A.8080502@sun.com> Clemens and all, We are working on adding a few more countries to the list including Austria. No promises, but we hear you! Unfortunately, while it might appear simple to add countries, the actual process is quite cumbersome and expensive because we are very careful to do the legal due diligence. Just so you all understand what that means, we are working with a outside specialist law firm on contests and sweepstakes, with offices around the world. Our Official Rules get reviewed top to bottom by lawyers in each jurisdiction we include, and we have found that despite appearances that countries are similar, in fact each country's laws on running such promotions are different in complex ways. Since the OpenJDK Challenge is part of a larger Sun Community Awards initiative and we want to make all the contests that are part of this program have the same list of eligible countries, this process is repeated 6 times for 6 sets of Official Rules, as each community is running a different contest that is suited to the community's needs. So it takes time, and incurs a significant expense, to add more countries. We are also trying to get an answer to the question about Sun contractor eligibility. Thanks for your patience! -- rms Clemens Eisserer wrote: > Hi again, > > I just read that Austria is not in the list of the countries allowed > to participiate. > Austria is in terms of law quite equal to Germany and is member of the > EU since 1995 (and of the EG longer than I can think of). > > So are Austrians really not allowed to participiate, or, was Austria > just forgotten because its too small? If it has just not been > considered important enough, is there any chance to get Austria in the > list? (Italy, Germany, Poland, ... are also there) > > Thanks, lg Clemens -- Rich Sands Phone: +1 781 881 4067 / x81524 Community Marketing Manager Email: richard.sands at sun.com Java SE Marketing SMS: 6172830027 at vtext.com Sun Microsystems, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From linuxhippy at gmail.com Thu Feb 7 10:48:07 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Thu, 7 Feb 2008 19:48:07 +0100 Subject: =?UTF-8?Q?DRAFT_PROPOSAL:_Port_of_=E2=80=9EConsumer_?= =?UTF-8?Q?JRE=E2=80=9C_features_to_Unix/X11_platforms?= Message-ID: <194f62550802071048j5fc2c28fv2fa36dcc663c7faa@mail.gmail.com> Hi again, Below is an early version of my Draft Proposal. There are some open questions like: - Is it possible to write code-parts for other projects (GTK+) in this cause if OpenJDK would benefit, and its not possible to work arround these problems in OpenJDK? I am a bit afraid that my code would not be included in GTK not because of technical problems but rather because of ideological or just because nobody is interested in reviewing it - so would it be still be sucessful if I point that out? - I am an Austrian citizen which is not on the list of allowed countries. Hope this can be fixed. I would be happy about comments, spelling mistakes or sections I should formulate more detailed - so if you have any suggestions please let me know. How important is it to get an recommendation from anuniversity professor or researcher? Port of ?Consumer JRE" features to Unix/X11 platforms 1.) Introcuction Since the release of Java-5 many improvements have been made in order to make the JAVA platform better suited for deskop use. With the release of Java6_update10 many exciting, new, and very useful features will be available for desktop users which use the Windows operating system. However, because many of the changes are very platform specific like the new Direct3d-9 Java2d pipeline many improvements can not be ported easily to other operating systems like Solaris and Linux. The aim of the proposal would be to start a project which ports many of those platform sepcific enhancements to X11 based Unix platforms in an as portable as possible manner. 2.) Goals This would allow developers to rely on the same set of features and the same level of implementation quality across whole set of platforms supported by Java, instead of cutting for example visual appearance down on one platform because of performance problems. Users would be able to run applications across all of their platforms and could enjoy the same behaviour and performance. A detailed list of changes would be: Port the Java-Quick-Starter (JQS) to Linux (and if possible to other Unix operating systems as well) Implement a new Java2D backend which utilizes the Xrender extension provided by modern implementations of the X11 standard. Enhance GTK+ to make it more suitable for themeing Extend the GTKLookAndFeel to use the improved theming interface of GTK+ 2.1) Java-Quick-Starter (JQS) for Unix: The Java-Quick-Starter is part of JDK6_u10 and keeps files which are typically used at JRE startup in memory (if the computer is not running on battery). Although the code is not open till now it should not be too hard to port the existing code to Unix and refactor out all platform specific details. Because Linux/Solaris are more and more used on desktops, a fast cold-start is as important as for Windows users. Furthermore a fast cold-start could help to improve the reputation of Java on those platforms of starting slow which could help to improve the adaption rate of the open-source community. Sun dependence: A 1:1 port would require the JDK6-u10 source code to be released, or at least be opend for the developer(s) working on this project if the code is intended to be released later. If the code is not planned to be released anytime soon it would not be too hard to write a new quickstarter for Unix ? however it would not be possible to base both on a common codebase which could make maintenance simpler. 2.2 Java2D Xrender backend: Also with JDK-u10 a new Java2D backend will be introduced based on Direct3D-9. A very powerful OpenGL backend is available on all supported platforms which shares a lot common code with the Direct3D based pipeline. The X11 pipeline used mainly on Unix systems is only capable of accalerating basic operations and falls back to software rendering for anything from antialiased text to translucent images sometimes causing expensive VRAM readbacks. However unlike Windows where Microsoft starting with Windows Vista more or less deprecated all interfaces except Direct3D, on Unix good OpenGL drivers are still rare and only proprietary drivers are till now able to run the OpenGL pipeline. Even those proprietary drivers are often optimized for heavy-weight 3D applications like games and are not really suited for rendering light-weight simple 2D applications. Furthermore, although GLX exists, remote support is not as great as it could be. Because of those problems the OpenGL pipeline won't be able in the short term to step in as a replacement for the existing X11 pipeline. The XRender design has a lot in common with OpenGL/Direct3D, so one of two possible implementations would be to create a brand new backend based on the shared code developed for the OpenGL/Direct3D pipelines in JDK6-u10, however this would require Sun to release this part of code or at least send it to the developer(s) if its opening is planned. If this approach would not be successful an extension to the current X11 pipeline could be developed which could address the current shortcomings but rely on X-Core-Drawing for already implemented functionality. 2.3) Enhance GTK+ to make it more suitable for themeing: GTK+ drawing functionality is limited to drawing on X11-server-side resources, however the GtkLookAndFeel would need the data on the client-side. Furthermore things have to be drawn twice and compared in a costly operation to determine transparent/translucent parts of the resulting image, which means many client/server roundtrips per drawn widget (if not cached) and CPU expensive operations. A solution would be a new theming API which would allow to pass a cairo-drawing-context to GTK, and if the installed theme supports the new API, all operations could be done on an system-memory surface, with cairo even preserving the transparent/translucent parts. Note: This code itself is not targeted to OpenJDK but to the GTK+ project. However if it could be donated to Sun/OpenJDK which would also support (in the term of saying OpenJDK would favour the integration) the integration of the new code it could make acceptance of the new code much better. 2.4) Extend the GTKLookAndFeel to use the improved theming interface of GTK+ The existing GTKLookAndFeel would need an adaption to take advantake of the new theming interface mentioned above as well as a fallback-mechanism in the case that: the installed version of GTK+ does not support the new theme API the installed theme was written for an old version of GTK Note that also GtKLookAndFeel (as well as the new Nimbus-LnF) would benefit from an enhanced Java2D-XRender backend as both use translucent images as well as antialiasing. 3.) Project plan: The planning as well as the implementation consists of several milestones: Milestone1: Implement the changes to the GTK theming interfaces (prototype does exist). This will be done first because it will take some time until GTK+ maintaines (if at all) will accept the patch and until the new version of GTK+ and themes have spread on desktops. The success of the project can't be defined wether the patch is accepted by the maintainers or not, however I will try hard to eliminate valid concerns and technical problems. Milestone2: Implement the Xrender-Java2d backend Milestone2.1: Ensure performance and quality of the Java2d backend by extensive testing and profiling. Milestone3: Implement the changes to GtkLookAndFeel and do extensive profiling and benchmarking to ensure the performance is on par with the WindowsLookAndFeel. Milestone4: Implement JQS for Unix platforms. 4. Results: The sucess of the projects will be measured by the success in planning and implementing the features mentioned above. 5. Developer(s): Clemens Eisserer is Student at the Technical University of Vienna (Informatics), has submited a few patches to jdk-collaboration and OpenJDK and sucessfully finished commercial projects about client-server architectures. From charles.nutter at sun.com Thu Feb 7 17:27:05 2008 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Thu, 07 Feb 2008 20:27:05 -0500 Subject: Support for Wayne Meissner's proposal Message-ID: Just wanted to mention that an FFI or DL like layer for programmatically loading and calling C libraries has been on my short list of "must have" features for a long time. We're shipping JNA with JRuby and both Java and Ruby users alike have been astounded by the power and potential of such a library. This needs to happen. - Charlie From wmeissner at gmail.com Thu Feb 7 23:23:53 2008 From: wmeissner at gmail.com (Wayne Meissner) Date: Fri, 8 Feb 2008 17:23:53 +1000 Subject: =?WINDOWS-1252?Q?Re:_DRAFT_PROPOSAL:_Port_of_=84Consume?= =?WINDOWS-1252?Q?r_JRE=93_features_to_Unix/X11_platforms?= In-Reply-To: <194f62550802071048j5fc2c28fv2fa36dcc663c7faa@mail.gmail.com> References: <194f62550802071048j5fc2c28fv2fa36dcc663c7faa@mail.gmail.com> Message-ID: <4ccee320802072323i4680ffd7yac93d8a9bbd06ecb@mail.gmail.com> Hi Clemens, On 08/02/2008, Clemens Eisserer wrote: > Hi again, > > Below is an early version of my Draft Proposal. > 2.2 Java2D Xrender backend: Since the question of "why not just write a cairo backend?" will get asked, it might be a good idea to put in a link to some of the discussions of this, such as http://www.nabble.com/Best-way-organizing-XRender-additions-for-the-X11-pipeline--td14152122.html Also, references to the classpath work done on a pure-java X11 backend (which I think supports XRender?) could be useful, for people to compare. You will want to pick which way you're going to go with implementing this (the X11 pipeline extension seems the easiest way, but I don't know the technical details) before the final draft. > Even those proprietary drivers are often optimized for heavy-weight 3D > applications like games and are not really suited for rendering > light-weight simple 2D applications. Furthermore, although GLX exists, > remote support is not as great as it could be. > Because of those problems the OpenGL pipeline won't be able in the > short term to step in as a replacement for the existing X11 pipeline. It might be worthwhile listing which drivers have good XRender support - do opensource drivers for various cards/chipsets have better XRender support than OpenGL support? If so, it would be something that gives more support to this idea for mainstream users, and a fully opensource desktop, not just remote X users. From linuxhippy at gmail.com Fri Feb 8 01:24:42 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Fri, 8 Feb 2008 10:24:42 +0100 Subject: =?UTF-8?Q?Re:_DRAFT_PROPOSAL:_Port_of_=E2=80=9EConsume?= =?UTF-8?Q?r_JRE=E2=80=9C_features_to_Unix/X11_platforms?= In-Reply-To: <4ccee320802072323i4680ffd7yac93d8a9bbd06ecb@mail.gmail.com> References: <194f62550802071048j5fc2c28fv2fa36dcc663c7faa@mail.gmail.com> <4ccee320802072323i4680ffd7yac93d8a9bbd06ecb@mail.gmail.com> Message-ID: <194f62550802080124ica6bd8dkbef5764d8b8aada6@mail.gmail.com> Hi Wayne, Thanks a lot for the suggestions, especially to mention the references to discussions and other projects - I've completly forgotten to include references ;) > You will want to pick which way you're going to go with implementing > this (the X11 pipeline extension seems the easiest way, but I don't > know the technical details) before the final draft. Well, it also depends wether the code of the new Direct3D/OpenGL pipelines will be opened early enough. There are some contraints about which code may be used. The disadvantage I see with extending the existing pipelines is code duplication and not so maintenance friendly code, on the other side already a lot of stuff already works so its some kind of tradeof. I'll play a bit with it and see what can be done how ;) > It might be worthwhile listing which drivers have good XRender support > - do opensource drivers for various cards/chipsets have better XRender > support than OpenGL support? > If so, it would be something that gives more support to this idea for > mainstream users, and a fully opensource desktop, not just remote X > users. Absolutly, thats the main reason why I think XRender as Java2D backend makes sence (thanks, seems I've not mentioned this enough). Some of the open-source drivers bundled with Xorg already accalerate XRender (Intel, ATI/AMD), and because EXA will be the default accaleration architecture soon, in the mid-term almost all drivers will have good XRender accaleration. I'll put some explanations and links to the proposal to make this more clear. Thanks a lot for your suggestions, lg Clemens From wmeissner at gmail.com Sat Feb 9 23:25:28 2008 From: wmeissner at gmail.com (Wayne Meissner) Date: Sun, 10 Feb 2008 17:25:28 +1000 Subject: =?WINDOWS-1252?Q?Re:_DRAFT_PROPOSAL:_Port_of_=84Consume?= =?WINDOWS-1252?Q?r_JRE=93_features_to_Unix/X11_platforms?= In-Reply-To: <194f62550802080124ica6bd8dkbef5764d8b8aada6@mail.gmail.com> References: <194f62550802071048j5fc2c28fv2fa36dcc663c7faa@mail.gmail.com> <4ccee320802072323i4680ffd7yac93d8a9bbd06ecb@mail.gmail.com> <194f62550802080124ica6bd8dkbef5764d8b8aada6@mail.gmail.com> Message-ID: <4ccee320802092325u641566dbs9484bb8c5f421a4@mail.gmail.com> On 08/02/2008, Clemens Eisserer wrote: > > It might be worthwhile listing which drivers have good XRender support > > - do opensource drivers for various cards/chipsets have better XRender > > support than OpenGL support? > > If so, it would be something that gives more support to this idea for > > mainstream users, and a fully opensource desktop, not just remote X > > users. > Absolutly, thats the main reason why I think XRender as Java2D backend > makes sence (thanks, seems I've not mentioned this enough). You mentioned it, I just thought being more explicit (i.e. opensource driver Foo for popular chipset Bar has better support for XRender than opengl) lends more weight to your idea. > Some of the open-source drivers bundled with Xorg already accalerate > XRender (Intel, ATI/AMD), and because EXA will be the default > accaleration architecture soon, in the mid-term almost all drivers > will have good XRender accaleration. > I'll put some explanations and links to the proposal to make this more clear. I've read a smattering of XRender/EXA/XAA/OpenVG/Gallium3D stuff this afternoon, and it would be nice to see a brief explanation of: 1) exactly what Java2D things XRender can accelerate. 1b) How that relates to and speeds up common software (e.g. the Nimbus L&F, the Substance L&F, JavaFX) that is or will become important in java-on-the-desktop. 2) what the state of XRender is in various open & closed source drivers (e.g. last time I used nvidia on linux, XRender was buggy). 3) How XRender compares to OpenVG or Cairo for accelerating java2D. A couple of lines on each, with links to further information should do. It wouldn't hurt to be a bit verbose here, you can always cut it down later. Sidenote: Would it be better to make the XRender proposal independent of the other parts? They seem to be only linked by the "linux-desktop" angle, and they're not inter-dependent - and it looks like it would be a substantial chunk of work all by itself. From linuxhippy at gmail.com Fri Feb 15 06:54:34 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Fri, 15 Feb 2008 15:54:34 +0100 Subject: DRAFT PROPOSAL: Implement XRender pipeline for Java2D Message-ID: <194f62550802150654l32c0ab22w3550004d7a226f45@mail.gmail.com> Hi again, Attention: I am from Austria, as long as Austria is not in the list of countries allowed to participiate I may not work on this :-/ I reworked my previous proposal and focused only on the XRender backend, because thats the core functionality the old proposal focused on. I think its better to get this done right instead of many half-done ("ready for showcase") features. The adaption of GTK is almost done and the adoption of the theme should not be a lot of work, so these are things I plan to do in my spare-spare time. As last time it would be great if you could review my proposal, I would be really happy about comments and critics. 1.) Introduction Since its introduction, Java2D supports very advanced rendering operations, although only very basic operations were accelerated by hardware, because the underlying APIs were very poor. Because visual appearance is getting more and more attention these days those operations are also used for performance critical applications like games, graphical user interfaces (e.g. nimbus) or animations ? leading to poor performance for graphical intensive applications. Modern 3D graphic APIs, like OpenGL or Direct3D, allow to map most of Java2D's functionality without the need for expensive read-backs and/or software rendering. To make that functionality available to the Java platform two new ?pipelines" where created: The OpenGL pipeline for non Windows platforms, and the Direct3D pipeline for the Microsoft Windows operating systems only. However OpenGL on Unix in general has some disadvantages compared to X11 for typical desktop applications, because of poor drivers its often not possible to use that new functionality and Java falls back to the default X11 rendering pipeline. An Xrender backend for Java2D would provide almost the same features as the existing OpenGL pipeline, however would run on a much larger set of hardware and would integrate better into existing X11 based desktops. With the Xrender backend developers and users could rely on almost the same set of functionality accelerated by default on all platforms supported currently by OpenJDK. 2.) Status Quo The existing X11 pipeline used on Unix systems is only capable of accelerating basic operations and falls back to software rendering even for often used operations like antialiasing (even for text!) or translucent images often causing expensive VRAM readbacks. Because of X11's very limited rendering capabilities Xrender was introduced back in 2001, and after a long delay first drivers are available which accelerate large areas of Xrender. XRender allows to accelerate most of Java2D's functionality, and it is considered to be the de-facto standard for advanced 2D graphics, already used by a large set of libraries and toolkits like Cairo, GTK+, QT4 and KDE4. Because of the broad and extensive use of Xrender there is currently major work ongoing to modify drivers for better Xrender performance. There is already an OpenGL backend for Java2D which is about as powerful as its Direct3D counterpart on Windows. A small overview about the advantages/disadvantages Xrender has compared to OpenGL: + Lower per-primitive overhead: Because Xrender is compared to OpenGL a lot simpler, there is less work for the accelerating driver to do for each primitive rendering operation. This is especially important for complex shapes which are transformed to many rectangles which then are passed to the underlying graphic API. To make it short: Because Xrender focuses on only a small set of ?simple" operations, driver implementers can focus on making those few operations as fast as possible. + Support for higher-level primitives: Xrender has support for client-side font rendering, which means glyphs which are cached in vram can be shared across different applications. For OpenGL each application has to upload its glyphs into a private texture wasting large amounts of Vram. Because it was designed with 2D graphics in mind many features can be directly mapped to Xrender without the need of complex shaders. + Reliable AntiAliasing: Because Xrender specifies exactly how antialiasing has to be done, Java2D can rely on Xrender's antialiasing capabilities. The Direct3D and OpenGL pipelines render a alpha-mask in software, upload it to vram and only let the GPU only do the final composition step. Because of this, the amount of data transferred between the Xserver and the Java application would be reduced a lot, making antialising even usable over slow remote connections. + Better driver support: On Linux only proprietary OpenGL implementations provide enough functionality to let the OpenGL pipeline run. However even those proprietary drivers were/are buggy in the code-paths exercised by the OpenGL pipeline. For Xrender there are already many optimized drivers, both open-source (Intel, ATI, ...) and proprietary (Nvidia). Because of the high adaption rate of Xrender lately (KDE4, Cairo, GTK+, ...) it can be expected that soon more and more drivers will support Xrender acceleration. + Better desktop integration: Xrender applications are ?native" X11 applications, and therefor work well with composition managers. They also get visuals optimized for 2D, and do not waste Vram with additional buffers they get, although they are not used. + Better fallback behaviour: If a driver does not accalerate some operations, its much more likely that the operation still can be done ?fast enough", because the whole data-moving between the X-Server and Java is removed. This also removes the burden of lowest-level optimization in the Java2D software loops ? this is now done by the X-Server. + Better network transparency: Although OpenGL can also be made network-transparent via GLX, the OpenGL API was not designed to perform especially well in a network environment. X11/XRender relies on the Client-Server approach and therefor is optimized for exactly this case. - Not programmable: A disadvantage of Xrender is that its not as flexible as OpenGL. OpenGL allows to use shaders to implement features not provided by fixed functionality, the only solution for a Xrender based backend is to fall back to software rendering. Unlike on Windows where Microsoft starting with Windows Vista more or less deprecated all interfaces except Direct3D, and therefor forces GPU/driver manufacturers to create drivers well suited also for 2D rendering, on Unix good OpenGL drivers are still rare and only proprietary drivers are till now able to run the OpenGL pipeline. However those proprietary drivers are often optimized for heavy-weight 3D applications like games and are not really suited for rendering light-weight simple 2D applications. 3.) Goals The goal of this proposal is to make use of Xrender for accelerating advanced Java2D functionality. This would allow multimedia content to take advantage of modern hardware, and would bring JDK6 Update10 graphic features also to X11/Unix based platforms. Some of the most important enhancements compared to the X11 pipeline include: * Accelerated text rendering for normal, antialiased and subpixel antialiased text. * Support for translucent images * Composition (colors with alpha values, ...) * Antialiasing 4.) Approach XRender has a lot in common with OpenGL/Direct3D and is a very low-level API which supports only a limited number of drawing primitives but it is very flexible which type of operations it operates on those primitives. Therefor the approach would be to create a brand new backend based on the shared code developed for the OpenGL/Direct3D pipelines in JDK6-u10. The advantage of this approach would be a ?clean start", as well as a lot shared code between OpenGL/Direct3D/XRender backends. The downside is that some highly optimized primitives which are supported by X11's core drawing (Arcs, Elipses, ..) maybe perform a little bit less well. Furthermore new code needs a lot of testing. 5.) Milestones 5.1) Create a skeleton which is able to use the shared OpenGL/Direct3D code 5.2) Implement only enough to functionality to make software-rendering-loops work. 5.3) Extend the created skeleton, accelerate basic operations -> Make typical Swing/Ocean applications work well. 5.4) Accelerate more advanced functionality like gradients, composition and antialising -> Accalerate most of Java2Demo, make the Nimbus LnF work well. 5.5) Extensive profiling an compatibility testing, using self written, Sun's jtreg and real- world tests, reporting performance and implementation problems back to driver programmers. Make sure large graphical applications work well. 6.) Developer Clemens Eisserer is Student at the Technical University of Vienna (Information Technology) and: * Has submitted patches to jdk-collaboration and OpenJDK (Java2D) * Ported Kaffe's XAWT to GCJ: http://sf.net/projects/xawt * Is working on an open-source remote-swing project: http://juibrowser.sourceforge.net/ * Compiled and packaged a free JVM for the Nokia770 internet tablet (got discounted N800 for that work) * Finished many commercial projects written in Java with focus on client-server architectures 7.) Links, References, ... http://keithp.com/~keithp/render/ http://www.nabble.com/Best-way-organizing-XRender-additions-for-the-X11-pipeline--td14152122.html http://www.phoronix.com/scan.php?page=article&item=934&num=1 From wmeissner at gmail.com Sat Feb 16 22:38:34 2008 From: wmeissner at gmail.com (Wayne Meissner) Date: Sun, 17 Feb 2008 16:38:34 +1000 Subject: DRAFT PROPOSAL: Implement XRender pipeline for Java2D In-Reply-To: <194f62550802150654l32c0ab22w3550004d7a226f45@mail.gmail.com> References: <194f62550802150654l32c0ab22w3550004d7a226f45@mail.gmail.com> Message-ID: <4ccee320802162238q732096a9pe5b3487b10d7ca5a@mail.gmail.com> On 16/02/2008, Clemens Eisserer wrote: > Hi again, > > Attention: I am from Austria, as long as Austria is not in the list of > countries allowed to participiate I may not work on this :-/ I hope Sun fixes that up quickly. This proposal looks excellent now. The only suggestion I have is it might be nice to have a table illustrating the primitives each backend can accelerate. e.g. | GL | D3D | XRender | X11 ------------------------------------------------------------ Anti-aliasing | Y | Y | Y | Translucent Img | Y | Y | Y | I'm not sure if thats feasible for all the things XRender can acclerate, but it gives a visual indicator of how equivalent to GL/D3D Xrender can be. From tor-einar at jarnbjo.name Mon Feb 18 06:42:55 2008 From: tor-einar at jarnbjo.name (Tor-Einar Jarnbjo) Date: Mon, 18 Feb 2008 15:42:55 +0100 Subject: DRAFT PROPOSAL: JavaSound extensions and service providers for Ogg/Vorbis and Ogg/FLAC Message-ID: <15295157.8995101203345774863.JavaMail.root@yggdrasil.jarnbjo.name> Hi, first a short draft proposal, to see if this may be of any interest, in which case a more detailed description will of course follow. * Proposed goals: - Add JavaSound service providers for reading Ogg/Vorbis and Ogg/FLAC. There are several RFEs touching this subject, e.g. 4671067, 6405350 and 4499904. I am not going to reinvent the wheel for this, but I would refurbish the code from my J-Ogg project (www.j-ogg.de) and donate it to the OpenJDK project. I beleive that J-Ogg is mostly bug free, but the code base could need some refactoring and cleanup. Some specific points to consider: - add generics - migrating to NIO may make it easier to support different datasources - better abstraction of the different datasources, especially when it comes to caching and positioning - Extend AudioInputStream to optionally support positioning within the audio stream. To make JavaSound a feasible backing technology for e.g. simple media (audio) players, AudioInputStream should support public methods for positioning. Although this functionality is offered by JMF, it makes sense to me, to offer such functionality in the standard J2SE API. boolean AudioInputStream#isSeekable(); long AudioInputStream#getFramePos(); void AudioInputStream#setFramePos(long newpos); The last methods acting on the protected field AudioInputStream#framePos. - Extend AudioFileReader to support further seekable sources for raw data. Currently, AudioFileReader can read an audio stream from either a File, an InputStream or a URL. This means, that to propagate "seekability" to the AudioInputStream without much fuzz, the source has to be a File, since InputStreams and URLs per se, are not offering a public interface for positioning. In practice however, some InputStream implementations are indeed seekable, e.g. ByteArrayInputStream and FileInputStream and depending on the underlying protocol, InputStreams returned from URL/ URLConnection may be seekable as well. Positioning in the stream from a file URL should always be possible, and utilizing the range header in HTTP, positioning in the stream from an HTTP URL may also be possible (and desired, e.g. for audio streaming over HTTP) if the server supports that functionality. Considering that positioning with a stream can be useful in many other situations as well, my suggestion would be to either introduce a new interface java.io.SeekableInputStream, or perhaps just as well add the following methods to InputStream directly: boolean ...#isSeekable(); long ...#getPosition(); void ...#setPosition(long newpos); Having the methods directly in the InputStream class, would make it easier for delegating implementations of InputStream to propagate the functionality, e.g. if a seekable stream is wrapped by a BufferedInputStream. In InputStream, these methods would of course be implemented to return false and throw UnsupportedOperationException, but as a starter, it would be very easy to add this functionality to at least the following classes: - ByteArrayInputStream - FileInputStream - FilterInputStream - BufferedInputStream At some further point (it's not part of this actual proposal), it should also be considered to add this functionality to the InputStreams return by URL/URLConnection, if the protocol used supports positioning. Regards, Tor From anders.bjorklund at sajtopia.se Fri Feb 22 12:24:19 2008 From: anders.bjorklund at sajtopia.se (=?ISO-8859-1?Q?Anders_Bj=F6rklund?=) Date: Fri, 22 Feb 2008 21:24:19 +0100 Subject: DRAFT PROPOSAL: Meta-compiler for non-java code to run on the java virtual machine Message-ID: <47BF2F73.3070201@sajtopia.se> Hi all, I propose to implement A meta-compiler for non-java code to run on the java virtual machine. -------------------------------------------------------------------------------------------------------- 1.0 Specifics A system consisting of: A representation of class files with utility methods to translate to and from the internal binary representation. This representation could also be used outside of the compiler for other binary formats. An instrumentation to manipulate the internal bytearrays of the representation, shielding users of the system from implementation details. Bytecode needed in the compilation stage would be created with most code calling a language-type library written in java. That way most parts of a language implementation can be made using java, with just some minor parts as bytecode from the language developer. I belive such a system would decrease the time it would take to implement a new language on the jvm. Performance would be lower, but once the new language is up and running, focus can turn to changing those non performing sections into bytecode, all the time having a working language. Operations could be mapped to a specific command class defined in the language-type library. Eventually the library may be discarded once the entire new language has been properly implemented as bytecode. -------------------------------------------------------------------------------------------------------- 2.0 Goals To simplify the creation and manipulation of binary files - in particular the java class format. To simplify the migration of one or more computer languages to the java platform. -------------------------------------------------------------------------------------------------------- 3.0 Status I already have the binary parsing and the resulting representation working as a graph of objects. When it comes to parsing source code, I have previously created the lexer/parser "HiLexed" (available from SourceForge under GPL 2). Using HiLexed I am able to map most computer languages using a format similar to Backus Naur, into callbacks to the would-be compiler. The binary representation is functional and I can look at classfiles accessing bytecode in separate methods, read the constant pool and look at access modifiers of fields etc. The representation graph can be saved into a classfile again after manipulation. -------------------------------------------------------------------------------------------------------- 4.0 Complete implementation As evaluation of my proposal, I suggest to build an implementation of a small new language running on the jvm. This language would be extendable, supporting reading from the keyboard, loops, some operation on collected input as well as writing the results back to the console. (Submitter: Anders Bjorklund__AT__sajtopia.se) From scolebourne at joda.org Sun Feb 24 11:21:03 2008 From: scolebourne at joda.org (Stephen Colebourne) Date: Sun, 24 Feb 2008 19:21:03 +0000 Subject: DRAFT PROPOSAL: Provide date and time library from JSR-310 Message-ID: <47C1C39F.10802@joda.org> Well, it seems I'll be the first to suggest a JSR derived project for the challenge. Hopefully the JSR/Challenge combo will be acceptable to any legal people: DRAFT PROPOSAL The provision of a date and time library suitable for inclusion in OpenJDK Stephen Colebourne 1. Summary ---------- Two of the least liked APIs of the JDK are those of Date and Calendar. The classes are mutable when they shouldn't be, have unusual performance characteristics and months where January is zero. Having previously tackled this issue via Joda-Time [1] I am now co-spec lead of JSR-310 Date and Time API. This JSR is developing, using an open process a new date and time API targetting the Java 7 release. 2. Goals and deliverables ------------------------- The goal of this project is to provide a complete working Reference Implementation of JSR-310 as agreed by the JSR-310 working group [2]. It should be noted that the JSR is unlikely to be complete within the timeframe of the challenge. As such, the goal for this project is to complete the RI as required by the working group. Although a commitment cannot be made here, it is intended that this should be used to publish the RI for the JCP Early Draft Review milestone. JSR-310 and this RI project shall cover as a minimum - immutable classes for timestamps, dates, times, datetimes, timezone, timezone offset, alternate calendar systems, duration, period, interval, formatting and parsing. 3. Previous work ---------------- Work on the RI has already started [2] and continues to guide the working group. This project represents the continuation of that development. The Reference Implementation is BSD licensed. It is not proposed to change that as it is compatible with the GPL license. 4. Deliverables --------------- The deliverables are: 1) The source code of the Reference Implementation of JSR-310. 2) The source code of any existing JDK classes modified as part of JSR-310. 3) Source code documentation in the form of javadoc suitable for inclusion in the JDK. 4) Tests with 90%+ test coverage. It is expected that the deliverables will correspond to the JCP Early Draft Review stage. 5. Dependencies on Sun ---------------------- There are no known dependencies on Sun over and above those Sun has already agreed to with the JSR-310 working group. 6. Developer ------------ Stephen Colebourne has worked with Java since 1997 and in Open Source since 2000. He is a Member of the Apache Software Foundation, creator and project lead of Joda-Time [1], creator of Kijaro [3] and co-author of FCM closures. He is currently a hands-on architect at SITA ATS Ltd building airline e-commerce systems. [1] http://joda-time.sourceforge.net [2] http://jsr-310.dev.java.net [3] http://kijaro.dev.java.net From anto.cuni at gmail.com Mon Feb 25 12:50:05 2008 From: anto.cuni at gmail.com (Antonio Cuni) Date: Mon, 25 Feb 2008 21:50:05 +0100 Subject: Question about the SCA Message-ID: <47C329FD.2070606@gmail.com> Hi all, I am one of the core developer of PyPy_. We are considering writing and sending a proposal about a backend for `PyPy's JIT generator`_ targeting the JVM (and/or maybe the new Da Vinci Machine). I won't discuss the details of the proposal here because it is not ready yet, but I would like a clarification about the Sun Contributor Agreement, which you need to sign to enter the challenge, according to the rules. After having read it, I seem to understand that the Sun Contributor Agreement applies only to the code that goes into a project directly managed or owned by Sun; what it's not clear to me is how this interacts with the projects that would eventually be sponsored by Sun but are not directly managed by it, as in the case of our proposal, for which the code developed would go into PyPy's codebase, which is clearly not owned nor managed to Sun. Our questions are: 1. Is it possible to enter the challenge even if the code being developed would be part of an existing project/codebase not directly related to Sun? 2. Does the Sun Contribution Agreement still apply also to that code? 3. (In case the answer to (2) is "yes") Which parts of the codebase will Sun have rights on? Only the new code developed under the terms of the challenge, even if that code it's not usable without the existing code? I hope that the Challenge does not require to give to Sun the rights over all the whole codebase, because it wouldn't be practical to find all the 70 existing developers of PyPy that currently hold the copyright of the various pieces of code. Thanks, Antonio .. _PyPy: http://codespeak.net/pypy/ .. _`PyPy's JIT generator`: http://codespeak.net/pypy/dist/pypy/doc/jit.html From neal at gafter.com Mon Feb 25 22:58:19 2008 From: neal at gafter.com (Neal Gafter) Date: Mon, 25 Feb 2008 22:58:19 -0800 Subject: DRAFT PROPOSAL: Implement BGGA Closures for Java Message-ID: <15e8b9d20802252258m2f6d73f9t1884004603420025@mail.gmail.com> DRAFT PROPOSAL: Implement Closures for Java Neal Michael Gafter neal at gafter.com Implement Lambda Expressions, Function Types, and Control Abstraction I propose to produce a feature-complete prototype of the Java bytecode compler (javac) features for the Closures specification appearing at http://www.javac.info/closures-v05.html, suitable for integration into the openjdk javac compiler as part of the reference implementation of a future platform specification. The specification includes the following major features - closure literals (sometimes called lambda expressions) - function types - control invocation statements This includes support for the following component features - restricted and unrestricted forms - the closure conversion - exception type parameters - union types - definite assignment - the type Unreachable (to be renamed Nothing) - loop abstractions - access to non-final variables within a closure The prototype shall be complete in providing support for all features of the specification, including those described above, as well as supporting "nonlocal" return, break, and continue in unrestricted contexts. The Clear Need A discussion of the needs satisfied by this proposal appears in a draft JSR proposal at http://www.javac.info/consensus-closures-jsr.html. In summary, the draft specification supports the development and use of APIs that significantly improve the use of concurrency for multicore systems, and enables the development of APIs that significantly reduce boilerplate for some common programming patterns. A community vote at java.net identified this approach to closures as most preferred among those who voted. Development Guidelines Devlopment of the prototype shall take place as an openjdk project to be created within the openjdk compiler group, in accordance with the prevailing community governance procedures for such development. The prototype shall be contributed under the Sun Contributor Agreement. Dependence on Sun and other resources While the development of the specification is outside the scope of this project, it is likely that the specification will evolve in response to community feedback. For example (as discussed in the draft JSR specification) I expect to add support for constructing a closure by reference to an existing Java method ("method reference"). Any such changes in the specification shall be followed by inclusion of those changes in the scope of the project. Development of the prototype shall take place independently of Sun Microsystems. I expect involvement of Sun Microsystems employees - particularly Alexander Buckley, the editor of the Java Language Specification, and Maurizio Cimadamore, a specialist in type systems, in refining the specification and providing feedback about specification changes that will be necessary to integrate the work into the Java Language Specification and to integrate it with other language changes that might be under consideration. Such specification refinements shall be reflected in the prototype. In addition, I expect continued collaboration with other authors on the draft specification, including specifically Gilad Bracha, James Gosling, and Peter von der Ahe. Additional work may be desireable in the virtual machine or core libraries in support of this work. For example, it would be useful for the virtual machine to provide support for proper tail recursion and to generate function type interfaces on demand. It would be helpful to extend the reflection libraries to support the new features. Such additional specification and implementation work is outside the scope of this project. Project Plan and Milestones Development shall proceed as follows: - 2008-04-30: An initial prototype shall be published as an openjdk patch, providing support for most of the features of the specification with unit tests and regression tests. - 2008-05-30: An extension of the com.sun.source, javax.lang.model, and javadoc APIs shall be included in a revision of the prototype. - 2008-06-30: An update to the prototype shall be published that provides support for nonlocal return, break, and continue, and any other remaining features from the initial specification. - 2008-07-18: Any specification changes preceding 2008-06-01 shall be reflected in a revision of the prototype. - 2008-08-03: Final, feature-complete submission of the Closures prototype shall be delivered at this time. In addition to these milestones, I expect to provide regular prototype updates in response to bug reports from users of the prototype. While not formally part of the project, I expect to recommend JVM, library, and other platform changes that are likely to improve performance, usability, or integration with the platform or other language changes likely to be included at the same time as closures. Copyright This proposal, in its entirety, is hereby contributed under the terms of the Sun Contributor Agreement. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/challenge-discuss/attachments/20080225/73929cea/attachment.html From linuxhippy at gmail.com Tue Feb 26 02:11:36 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Tue, 26 Feb 2008 11:11:36 +0100 Subject: DRAFT PROPOSAL: Implement BGGA Closures for Java In-Reply-To: <15e8b9d20802252258m2f6d73f9t1884004603420025@mail.gmail.com> References: <15e8b9d20802252258m2f6d73f9t1884004603420025@mail.gmail.com> Message-ID: <194f62550802260211i66cf5935w361fcde95095896a@mail.gmail.com> Hi, Without any doubt this proposal is challenging and will require significant amount of work, its cool and professional. By the way the rules say the final proposal has to be plain-text, so maybe you would like to change this. However what worries me is that there still hasn't been a descision about which closure type will be choosen and saying that BGGA is the preferred closure implementation is a bit canting - 42.7% favoured BGGA and 37.7% said they don't want any closure implementation. So what I fear is that this will end up with an completly implemented closure specification which will be choosen just because its already implemented. If BGGA is the best or not, it could also lead to some angry voices arguing that BGGA did it just because it took part at the challenge and that it "bypassed" the JCP this way. Please don't get me wrong, I like your proposal and the way its done ... its just a very hot topic. Furthermore I have to admit that I am not viewless when it comes to closures (I have a general opinion, I don't favour any implementation), so my opinion may be too very politic or I am biased. lg Clemens From linuxhippy at gmail.com Tue Feb 26 02:19:18 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Tue, 26 Feb 2008 11:19:18 +0100 Subject: DRAFT PROPOSAL: Provide date and time library from JSR-310 In-Reply-To: <47C1C39F.10802@joda.org> References: <47C1C39F.10802@joda.org> Message-ID: <194f62550802260219q2452baedxffa00992e0a67bc7@mail.gmail.com> Hi Stephen, Your proposal seems quite cool - I did not even know that this is in the working. Good to know :) How "large" do you think this task is? It would be great if you could extend your proposal a bit with whats missing in the RI and what you would like to do, maybe something like a plain-text table or something like that. Good luck, lg Clemens From linuxhippy at gmail.com Tue Feb 26 02:24:24 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Tue, 26 Feb 2008 11:24:24 +0100 Subject: Whats the definition of "milestones"? Message-ID: <194f62550802260224n2687e33bv79d34ebb0b58484e@mail.gmail.com> Hi there, The challenge-rules mention that the proposal should include "milestones". Should those milestones be a date (or is it preferred) or is it ok to list one milestone after another and its ok when all milestones are done one after another? Thanks, lg Clemens From neal at gafter.com Tue Feb 26 07:29:59 2008 From: neal at gafter.com (Neal Gafter) Date: Tue, 26 Feb 2008 07:29:59 -0800 Subject: DRAFT PROPOSAL: Implement BGGA Closures for Java In-Reply-To: <194f62550802260211i66cf5935w361fcde95095896a@mail.gmail.com> References: <15e8b9d20802252258m2f6d73f9t1884004603420025@mail.gmail.com> <194f62550802260211i66cf5935w361fcde95095896a@mail.gmail.com> Message-ID: <15e8b9d20802260729x7eab673dg7aea1b4194e686a@mail.gmail.com> Yes, I will need to put it in plain-text format. This is not intended to bypass the JCP or to propose changes to the language specification, but rather to provide a complete implementation of one option. I can certainly imagine that other proposals might take part in the challenge as well. This proposal augments BGGA with "method references", which appears to be the main reason that some people prefer another approach. Still, my reference to the poll is probably not constructive; I certainly don't believe in language design by popular vote. Realistically, closures may not make it into JDK7 due to schedule pressures; JDK8 may be more realistic. We'll know more once Sun provides some schedule guidance. Regards, Neal On Tue, Feb 26, 2008 at 2:11 AM, Clemens Eisserer wrote: > Hi, > > Without any doubt this proposal is challenging and will require > significant amount of work, its cool and professional. By the way the > rules say the final proposal has to be plain-text, so maybe you would > like to change this. > > However what worries me is that there still hasn't been a descision > about which closure type will be choosen and saying that BGGA is the > preferred closure implementation is a bit canting - 42.7% favoured > BGGA and 37.7% said they don't want any closure implementation. > So what I fear is that this will end up with an completly implemented > closure specification which will be choosen just because its already > implemented. > If BGGA is the best or not, it could also lead to some angry voices > arguing that BGGA did it just because it took part at the challenge > and that it "bypassed" the JCP this way. > > Please don't get me wrong, I like your proposal and the way its done > ... its just a very hot topic. > Furthermore I have to admit that I am not viewless when it comes to > closures (I have a general opinion, I don't favour any > implementation), so my opinion may be too very politic or I am biased. > > lg Clemens > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/challenge-discuss/attachments/20080226/76e492f4/attachment.html From charles.nutter at sun.com Tue Feb 26 10:09:11 2008 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Tue, 26 Feb 2008 12:09:11 -0600 Subject: DRAFT PROPOSAL: Implement BGGA Closures for Java In-Reply-To: <15e8b9d20802260729x7eab673dg7aea1b4194e686a@mail.gmail.com> References: <15e8b9d20802252258m2f6d73f9t1884004603420025@mail.gmail.com> <194f62550802260211i66cf5935w361fcde95095896a@mail.gmail.com> <15e8b9d20802260729x7eab673dg7aea1b4194e686a@mail.gmail.com> Message-ID: <47C455C7.2050502@sun.com> Neal Gafter wrote: > Yes, I will need to put it in plain-text format. > > This is not intended to bypass the JCP or to propose changes to the > language specification, but rather to provide a complete implementation > of one option. I can certainly imagine that other proposals might take > part in the challenge as well. This proposal augments BGGA with "method > references", which appears to be the main reason that some people prefer > another approach. Still, my reference to the poll is probably not > constructive; I certainly don't believe in language design by popular > vote. Realistically, closures may not make it into JDK7 due to schedule > pressures; JDK8 may be more realistic. We'll know more once Sun > provides some schedule guidance. I believe method references will go hand in hand with invokedynamic's likely support for lightweight method handles. Given one, the other seems natural. On the general BGGA proposal, perhaps there's also room for considering general type inference as an addition to OpenJDK? One problem I've had with BGGA is that it (necessarily for sanity) adds type-inferencing logic to reduce the complexity of declarations...but we end up leaving the rest of Java out in the cold without broader support. I for one would like to see such type inferencing added globally, both because it seems like a natural progression, it's compatible with all existing Java syntax, and it's obviously very useful for reducing the noise of generics, anon inner classes, and closures. Thoughts? From neal at gafter.com Tue Feb 26 10:35:06 2008 From: neal at gafter.com (Neal Gafter) Date: Tue, 26 Feb 2008 10:35:06 -0800 Subject: DRAFT PROPOSAL: Implement BGGA Closures for Java In-Reply-To: <47C455C7.2050502@sun.com> References: <15e8b9d20802252258m2f6d73f9t1884004603420025@mail.gmail.com> <194f62550802260211i66cf5935w361fcde95095896a@mail.gmail.com> <15e8b9d20802260729x7eab673dg7aea1b4194e686a@mail.gmail.com> <47C455C7.2050502@sun.com> Message-ID: <15e8b9d20802261035y371e13bembadc2d233d805458@mail.gmail.com> On Tue, Feb 26, 2008 at 10:09 AM, Charles Oliver Nutter < charles.nutter at sun.com> wrote: > Neal Gafter wrote: > > Yes, I will need to put it in plain-text format. > > > > This is not intended to bypass the JCP or to propose changes to the > > language specification, but rather to provide a complete implementation > > of one option. I can certainly imagine that other proposals might take > > part in the challenge as well. This proposal augments BGGA with "method > > references", which appears to be the main reason that some people prefer > > another approach. Still, my reference to the poll is probably not > > constructive; I certainly don't believe in language design by popular > > vote. Realistically, closures may not make it into JDK7 due to schedule > > pressures; JDK8 may be more realistic. We'll know more once Sun > > provides some schedule guidance. > > I believe method references will go hand in hand with invokedynamic's > likely support for lightweight method handles. Given one, the other > seems natural. I think invokedynamic is not required (or even particularly helpful) for implementing this. On the general BGGA proposal, perhaps there's also room for considering > general type inference as an addition to OpenJDK? One problem I've had > with BGGA is that it (necessarily for sanity) adds type-inferencing > logic to reduce the complexity of declarations...but we end up leaving > the rest of Java out in the cold without broader support. I for one > would like to see such type inferencing added globally, both because it > seems like a natural progression, it's compatible with all existing Java > syntax, and it's obviously very useful for reducing the noise of > generics, anon inner classes, and closures. > > Thoughts? > Actually, I'm working on that separately. Some of that may be more likely to make it into JDK7 than closures. But I wanted to keep the scope of this proposal focused and well-defined. Regards, Neal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/challenge-discuss/attachments/20080226/24fb2c2b/attachment.html From dsheppard2k at yahoo.com Tue Feb 26 21:18:39 2008 From: dsheppard2k at yahoo.com (David S) Date: Tue, 26 Feb 2008 21:18:39 -0800 (PST) Subject: DRAFT PROPOSAL - Pattern Oriented Framework Message-ID: <479915.43268.qm@web45712.mail.sp1.yahoo.com> DRAFT PROPOSAL Pattern Oriented Framework for the rapid implementation of Java applications 1. Summary ---------- This proposal describes a Pattern oriented Framework for the rapid implementation of Java applications. This integrated framework is based on a messaging architecture which provides strong encapsulation and loose coupling; framework components can be easily and interchangeably plugged into complex framework applications using a ?lego" approach. This framework is envisioned to provide capabilities for the implementation of applications based on design patterns. The framework itself is conceived, from the ground up, based on design patterns. The main goal of this project is to provide a complete reference implementation of the proposed framework. 2. Goals -------- The framework should address the following goals: A) The pattern oriented framework should implement and/or facilitate the implementation of well-known design patterns like GoF design patterns and J2EE Design patterns. The framework itself should be conceived and implemented based on design patterns (from the ground up). The framework should also facilitate and accelerate the implementation of applications based on design patterns. B) The framework architecture should be based on a messaging design pattern: framework objects should be able to interchange information and perform computations by sending, receiving and processing messages. A messaging API provides strong encapsulation and loose coupling; framework components can be easily and interchangeably plugged into complex framework applications using a ?lego/messaging? architecture. The framework should take full advantage of the power and simplicity of the messaging design pattern. C) The framework lego/messaging architecture should provide transparent access to remote components: remote framework objects should be treated as local objects. Design patterns implemented by the framework (adapters, remote proxies and facades) should make this possible by hiding the complexities associated with remote APIs. D) The framework should provide transparent integration with other technologies via framework adapters, proxies and the implementation of related design patterns. These technologies include BPM, DAO implementations, MVC implementations, EJBs, JMS, XML and Web Services. E) The framework should be designed to be lightweight and fast in terms of performance (very low overhead). F) The framework messaging/lego architecture should improve and simplify design/development efforts. There should be a tight correspondence between UML design diagrams and the framework messaging based applications and components needed for the implementation. Ideally, the framework should provide wizards and automated capabilities for generating framework applications. Framework components should be easily added to BPM process diagrams. In future versions of the framework, it should be possible for applications to be generated directly from the UML design diagrams. G) The framework messaging architecture should facilitate testing and debugging efforts. The framework should provide capabilities for testing components independently (each component as a unit) by sending messages and verifying the reply (output) messages. H) In order to provide additional productivity, the framework should be integrated with open source IDEs. 3. Previous work ---------------- Most of these requirements are met by the current version of the reference implementation of the framework. This reference implementation needs to be completed. A fair amount of work needs to be done in terms of automated framework Wizards and BPM integration. A JSR is being worked on. The JSR and the progress achived so far has been documented via the project web site. 4. Approach ----------- The project will be delivered using the Agile methodology. 3 or 4 iterations are envisioned. Each iteration should produce working software: a new revision of the reference implementation. The specific list of features for each iteration will depend on several factors including project membership. 5. Deliverables --------------- The projects delivables are as follows: 1) Complete source code for the reference implementation of the framework (feature complete). 2) Complete documentation. This includes javadoc documentation. 6. Sun Involvement/Participation -------------------------------- No Sun involvement/participation is required. 7. Team Membership ------------------- TBD ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools..search.yahoo.com/newsearch/category.php?category=shopping -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/challenge-discuss/attachments/20080226/21e6f5eb/attachment.html From gnu_andrew at member.fsf.org Wed Feb 27 02:07:42 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 27 Feb 2008 10:07:42 +0000 Subject: DRAFT PROPOSAL: Virtual Machine Interface Message-ID: <17c6771e0802270207l30940515g7b0e1a2fdab12508@mail.gmail.com> SUMMARY ========= The Virtual Machine (VM) interface within the OpenJDK [1] source code forms the boundary between the class library and the virtual machine, and allows the two to interact. Within OpenJDK, the VM interface has always been a means for HotSpot to access the J2SE classes and vice versa. As a result of this sole relationship between one VM and the class libraries, the current interface, although abstracted somewhat from the codebase, is undocumented and largely built around the needs of HotSpot rather than being explicitly designed as a VM interface. In contrast, within the Free Java space, the GNU Classpath [2] class library has had to deal with multiple VMs from a range of areas, including an Ahead-Of-Time (AOT) compiler (GCJ) [3],Java-in-Java VM (JikesRVM) [4] and a Java-on-.NET VM (IKVM.net) [5]. This has resulted in an explicit interface being constructed that, while there is room for improvement, fulfills the role of abstracting the class library from the virtual machines that use it. One notable point relating to its maintenance is that the VM interface has been explicitly kept 1.4-friendly while the rest of the codebase has shifted to the use of 1.5 language features such as generics. In general, native methods are housed in the VM layer rather than in the class library so that a native implementation is optional. For example, native methods appear in java.lang.Class in the OpenJDK whereas these methods are contained in the package-private java.lang.VMClass in GNU Classpath. This allows VMs to decide whether to simply provide a native implementation of the methods in the reference version of VMClass or provide their own VMClass more suited to their needs. This project proposes to try and find a happy medium between these two worlds. While GNU Classpath provides a more flexible VM interface, the class library of OpenJDK is more stable, mature and is, of course, the reference implementation for the Java platform. As such, many VMs, such as CACAO [6] and IKVM.net, that use GNU Classpath have already begun to switch to OpenJDK. However, for each VM to undertake this effort alone results in a significant duplication of effort. It also means that the VM interface of OpenJDK remains in its current undocumented and possibly volatile state. We propose to provide a documented VM interface for OpenJDK, which will significantly lower the barrier for entry for both existing Classpath VMs and any other VMs who may wish to use OpenJDK in the future. BENEFITS ========= As outlined in the summary, the main benefit will be the existence of a well-documented VM interface that can be used by a virtual machine implementor to access the OpenJDK class libraries. The immediate benefit of this is that it will reduce the effort required for GNU Classpath VMs to move to OpenJDK (or, even better, support both). In the future, it will allow a new VM to more easily utilise the OpenJDK as its class library. For users, it will mean increased choice. While they may choose to remain with the reference HotSpot VM, they may then have the option of using an alternative implementation such as GCJ for AOT compilation or JikesRVM for research on Java-based virtual machines. DELIVERABLES ============== The ultimate goal of this project is to have a well-defined and documented VM interface that is provided by the OpenJDK class library and implemented by its virtual machine, HotSpot. Ideally, it would also be beneficial to have another virtual machine which currently does not use the OpenJDK class library using this new interface to access the OpenJDK library by the end of the project. At the very minimum, a VM interface should be produced that can allow a VM to start up, even if some features are still missing. PLAN ===== 1. Become familiar with the VM interface by attempting to use it from a non-implementing VM 2. Move towards a situation where the VM can be started using the OpenJDK class library. 3. Fill in the gaps so as to provide a complete interface. 4. Implement this interface in HotSpot. The initial stages of the project will be concerned with obtaining a more detailed understanding of the current virtual machine interface. The best approach to this is to take an existing GNU Classpath VM and attempt to use it with the OpenJDK class library. This will be used as a way to find points of failure where the VM is not aware of the current OpenJDK interface and to fix these to suit within either the OpenJDK class library or the VM itself. It is expected that some part of this will involve moving the OpenJDK towards a GNU Classpath-esque interface, but there will also be parts where the current GNU Classpath VM interface is unsuitable or inadequate (e.g. some features are still missing from GNU Classpath that are implemented in OpenJDK). Documentation will be an ongoing part of this process, as will continued interaction with the community. This project will take place completely in the open and will develop as a result of discussion within the Free Java community. SUN PROVISION ============== As the source code bases for the OpenJDK class library and HotSpot are already available, Sun's most significant contribution to this effort has already been provided. Ideally, we would ask that the project be given space on the OpenJDK website and the means to host patches in order to maintain the open nature of its development. However, this can be provided elsewhere if necessary. We also expect some interaction with the existing OpenJDK community, but the last year has shown this to not be too problematic either. CHALLENGES ============ The main challenge of this project is that, although moves from Classpath to OpenJDK have been completed, the success of finding a happy medium between the two is as yet unknown. As a result, this project is partly experimental in its aims and, while we expect it to be fully feasible at this point, it may not completely reach fruition. In undertaking it, we expect that the eventual goal may change as things progress and situations change which are beyond our control. QUALIFICATION ============= As a GNU Classpath developer for the last four years, during which time I have maintained our experimental 1.5 branch and managed two releases, I already have significant understanding of its VM interface and of the needs of the VMs that use it. I have also worked with the JamVM, GCJ and JikesRVM codebases in the past (the last two as a participant in Google's Summer of Code [7]) and as a result have some knowledge of how these operate and the ways they interact with the class library. Regarding the OpenJDK, I have been working with the source code since it was released in May last year (and the compiler before that in November 2006). While I don't profess to know everything about such a large code base in such a short space of time, I am aware of how the IcedTea project has worked with this codebase so far and how CACAO has been integrated with it in order to allow its use as a virtual machine for that class library. [1] http://openjdk.java.net [2] http://www.gnu.org/software/classpath [3] http://gcc.gnu.org/java [4] http://jikesrvm.org [5] http://ikvm.net [6] http://cacaovm.org [7] http://code.google.com/soc -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net From Richard.Sands at Sun.COM Wed Feb 27 06:02:00 2008 From: Richard.Sands at Sun.COM (Rich Sands) Date: Wed, 27 Feb 2008 09:02:00 -0500 Subject: New countries eligible! Message-ID: <47C56D58.8070603@sun.com> The following countries are now eligible to enter the OpenJDK Community Innovator's Challenge: Austria Cambodia Croatia New Zealand Philippines Romania Singapore Venezuela We'll update the official rules shortly. Don't forget - the deadline to enter your proposals in the Challenge is fast approaching: the initial phase of the contest will close on March 2 at 11:59pm, PST. Still plenty of time! -- rms -- Rich Sands Phone: +1 781 881 4067 / x81524 Community Marketing Manager Email: richard.sands at sun.com Java SE Marketing SMS: 6172830027 at vtext.com Sun Microsystems, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From anto.cuni at gmail.com Wed Feb 27 09:17:02 2008 From: anto.cuni at gmail.com (Antonio Cuni) Date: Wed, 27 Feb 2008 18:17:02 +0100 Subject: DRAFT PROPOSAL - Porting the PyPy JIT to JVM and MLVM Message-ID: <47C59B0E.2000003@gmail.com> (a prettier HTML version of this proposal is available here: http://codespeak.net/pypy/extradoc/proposal/openjdk-challenge.html ) Porting the PyPy JIT to JVM and MLVM ==================================== PyPy and its JIT generator -------------------------- PyPy_ is an open source research project that aims to produce a flexible and fast implementation of the Python language. PyPy is divided into two main parts: the Python interpreter, which implements the Python language and is written in RPython_, and the Translation Toolchain (TT), written in Python, which transforms and translates programs written in RPython into the final executables. RPython is a subset of Python specifically designed to allow the TT to analyze RPython programs and translate them into lower level, very efficient executables. Currently, the TT of PyPy provides three complete backends that generate C code, bytecode for CLI/.NET and bytecode for the JVM. By using these backends, we can get Python implementations that run on a standard C/Posix environment, on the CLI or on the JVM. It is important to underline that the job of the TT is not limited to translation into an efficient executable, but it actively transforms the source interpreter by adding new features and translation aspects, such as garbage collection, microthreading (like `Stackless Python`_), etc. The most exciting feature of the TT is the ability to automatically turn the interpreter into a JIT compiler that exploits partial evaluation techniques to dynamically generate efficient code. The novel idea behind PyPy JIT is to delay the compilation until we know all the informations useful for emitting optimized code, thus being potentially much more efficient than all the current other alternatives (see the "Related Work" section). Currently, the PyPy JIT works only in conjunction with the C backend; early results are very good, the resulting Python interpreter can run numeric intensive computations at roughly the same speed of C, as shown by the `technical report`_ on the JIT. Moreover, there is an experimental JIT backend that emits code for the CLI; it is still work in progress and very incomplete, but it shows that the it is possible to adapt the PyPy JIT to emit code for object oriented virtual machines. Porting the JIT to the JVM -------------------------- The goal of this proposal is to extend the PyPy JIT to work in conjunction with the JVM backend. After the work has been completed, it will be possible to translate the interpreter into a Python implementation that runs on top of the JVM and contains a JIT; the JIT will dynamically translate part of Python programs into JVM bytecode, which will then be executed by the underlying virtual machine. Porting the JIT to the MLVM --------------------------- As stated above, PyPy JIT for JVM would work by dynamically emitting and loading JVM bytecode at runtime. Even if this approach has been tried in a couple of projects (see the "Related Work" section), it has to been said that the JVM was not originally designed for such applications; for example, the process of loading a single method is very expensive, since it involves the creation and loading of a surrounding class. The new Da Vinci Machine contains a lot of interesting features that could be effectively exploited by the PyPy JIT to produce an even more efficient implementation of the Python language, as `John Rose said`_ after the talk with PyPy people. Features of the MLVM that could be exploited by PyPy JIT include but are not limited to: dynamic invocation, lightweight bytecode loading, tail calls, etc. Implementation wise, the JIT backends for the plain JVM and for the MLVM could share most of the code, with the latter making use of the special features when needed. Moreover, the experience of this project will help the MLVM team to understand which features are really useful to implement dynamic languages on top of the JVM and which one we still lack. Deliverables ------------ Due to the its strict dependency on PyPy, it will not possible to release the result of the work as a separate and independent project. In particular, to reach the goals of the proposal it will be necessary to extensively modify parts of PyPy that are already there, as well as write completely new code. If the project goes to completion, the code developed will be integrated into the PyPy codebase; if Sun requires us to release the code under the SCA (thus sharing the copyright between the original author and Sun itself), we will send to Sun a document in unified diff format that extensively shows all and sole lines of code on which Sun will have the copyright. PyPy is already licensed under the extremely permissive MIT license, so there are no legal copyright barriers preventing us from sharing code in such a way. Project completion ------------------ PyPy JIT is still under heavy development; potentially, the resulting JIT compiler will be able to optimize a large number of Python programs, but at the moment it gives the best results only with computational intensive functions that use only operations between integers. We expect to get a pypy-jvm executable that can execute a function with those characteristics at roughly the same speed as its equivalent written in Java, excluding the costs of the JIT compilation itself, which have not been optimized yet. For an example of a function with is highly optimized by the PyPy JIT, look at the `function f1`_: when executed by a pypy-c compiled with JIT support, it runs roughly at the same speed as its C equivalent compiled with `gcc -O0`. Making the Python interpreter to exploit the full potential of the JIT is a separate task and it is out of the scope of this proposal; it is important to underline that once the JVM backend for the JIT is complete, the resulting pypy-jvm will automatically take advantage of all the optimizations written for the others backend. We also expect to find benchmarks in which the JIT that targets the MLVM will perform better than the JIT that targets the plain JVM, though it is hard to specify a precise commitment here without knowing which features of the MLVM will be possible to use. Relevance to the community -------------------------- Recently the community has shown a lot of interest in dynamic languages which run on top of the JVM. Even if currently Jython_ is the only usable implementation of Python for the JVM, PyPy has the potential to become the reference implementation in the future. To have a working JIT for the JVM is an important step towards making PyPy the fastest Python for the JVM, ever. Moreover, due to the innovative ideas implemented by PyPy, it is likely that Python could become the fastest dynamic language that runs on the top of the JVM. Finally, PyPy is not limited to Python: it is entirely possible to write interpreters for languages other than Python and translate them with the TT; as a proof of concept, PyPy already contains implementations of Prolog, Smalltalk, JavaScript and Scheme, with various degrees of completeness. Since the JIT generator is independent of the Python languages, it will be possible to automatically add a JIT compiler to every language written using the PyPy TT; thus, PyPy could become a very attractive platform to develop dynamic languages for the JVM. Dependencies on Sun ------------------- There are no dependencies on Sun regarding the implementation of a JIT compiler that targets the plain JVM. However, in order to implement a JIT compiler that targets the new MLVM, we need the new features we want to exploit to be implemented. Related work ------------ Dynamic generation of bytecode for object oriented virtual machine is a hot topic: - `this paper`_ shows how this technique is exploited to write an efficient implementation of EcmaScript which runs on top of the JVM; - Jython compiles Python source code to JVM bytecode; however, unlike most compilers, the compilation phase occurs when the JVM has already been started, by generating and loading bytecode on the fly; despite emitting code at runtime, this kind of compiler really works ahead of time (AOT), because the code is fully emitted before the program starts, and it doesn't exploit additional informations that would be available only at runtime (e.g., informations about the types that each variable can assume); - JRuby supports interpretation, AOT compilation and JIT compilation; when the JIT compilation is enabled, JRuby interprets methods until a call threshold is reached, then it compiles the method body to JVM bytecode to be executed from that point on; however, even if the compilation is truly just in time, JRuby doesn't exploit type informations that are known only at runtime to produce specialized, efficient versions of the function; - in the .NET world, IronPython works more or less as Jython; additionally, it exploits dynamic code generation to implement `Polymorphic Inline Caches`_. PyPy JIT is different of all of these, because runtime and compile time are continuously intermixed; by waiting until the very last possible moment to emit code, the JIT compiler is able to exploit all the runtime informations that wouldn't be available before, e.g. the exact type of all the variables involved; thus, it can generate many specialized, fast versions of each function, which in theory could run at the same speed of manually written Java code. Moreover, the JIT compiler is automatically generated by the TT: we believe, based on previous experiences as Psyco_, that manually writing a JIT compiler of that kind is hard and error prone, especially when the source language is as complex as Python; by writing a JIT compiler generator, we get JIT compilers that are correct by design for all languages implemented through the TT for free. Developer --------- Antonio Cuni is one of the core developers of PyPy; he is the main author of the CLI backend, and the coauthor of the JVM backend; recently, it began working on the experimental CLI backend for the JIT. Currently, he is a PhD student at Univerist? degli Studi di Genova, doing research in the area of implementation of dynamic languages on top of object oriented virtual machines. .. _PyPy: http://codespeak.net/pypy .. _RPython: http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html#rpython .. _`Stackless Python`: http://www.stackless.com/ .. _`technical report`: http://codespeak.net/pypy/extradoc/eu-report/D08.2_JIT_Compiler_Architecture-2007-05-01.pdf .. _`John Rose said`: http://blogs.sun.com/jrose/entry/a_day_with_pypy .. _Jython: http://www.jython.org .. _`function f1`: http://codespeak.net/svn/pypy/dist/demo/jit/f1.py .. _`this paper`: http://www.ics.uci.edu/~franz/Site/pubs-pdf/ICS-TR-07-10.pdf .. _`Polymorphic Inline Caches`: http://www.cs.ucsb.edu/~urs/oocsb/papers/ecoop91.pdf .. _Psyco: http://psyco.sourceforge.net/ From charles.nutter at sun.com Wed Feb 27 09:39:49 2008 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Wed, 27 Feb 2008 11:39:49 -0600 Subject: DRAFT PROPOSAL - Porting the PyPy JIT to JVM and MLVM In-Reply-To: <47C59B0E.2000003@gmail.com> References: <47C59B0E.2000003@gmail.com> Message-ID: <47C5A065.5010302@sun.com> A very interesting proposal. The work detailed here is a natural extension of what I've been doing with JRuby and what all languages targeting JVM will want to do. And by narrowing scope to MLVM/DVM this could escape some of the hindrances that have caused implementations like JRuby and Jython much heartache. I'm also interested in this sort of approach for JRuby, but given limitations of code generation, classloading, and method handles under JDK6- I've held off on continuing such work. In an ideal world, it would be trivial and lightweight to iteratively generate call sites, method handles, JITted method bodies, and more to create an increasingly more adapted call pipeline. As it stands, JRuby only can do code generation for method handles at startup and for JITted methods once at runtime, already paying a fairly high permgen and class maintenance cost. The features of the MLVM are expected to lessen this pain. Antonio: Do you have a feel for how much of this work would likely end up producing idiomatic JVM bytecode and how much might require modification to the JVM itself, or put differently how likely it would be that the PyPy JIT would need to target JVM components other than its bytecode interpreter and JIT? I'm growing more interested in the possibility of expanding the capabilities of OpenJDK by making it available in ways other than "good old Java bytecode". The proposal earlier today by Mr. Hughes may also play in this direction...I admit I have not read it yet. - Charlie Antonio Cuni wrote: > (a prettier HTML version of this proposal is available here: > http://codespeak.net/pypy/extradoc/proposal/openjdk-challenge.html ) > > > Porting the PyPy JIT to JVM and MLVM > ==================================== > > PyPy and its JIT generator > -------------------------- > > PyPy_ is an open source research project that aims to produce a > flexible and fast implementation of the Python language. > > PyPy is divided into two main parts: the Python interpreter, which > implements the Python language and is written in RPython_, and the > Translation Toolchain (TT), written in Python, which transforms and > translates programs written in RPython into the final executables. > RPython is a subset of Python specifically designed to allow the TT to > analyze RPython programs and translate them into lower level, very > efficient executables. > > Currently, the TT of PyPy provides three complete backends that > generate C code, bytecode for CLI/.NET and bytecode for the JVM. By > using these backends, we can get Python implementations that run on a > standard C/Posix environment, on the CLI or on the JVM. > > It is important to underline that the job of the TT is not limited to > translation into an efficient executable, but it actively transforms > the source interpreter by adding new features and translation aspects, > such as garbage collection, microthreading (like `Stackless Python`_), > etc. > > The most exciting feature of the TT is the ability to automatically > turn the interpreter into a JIT compiler that exploits partial > evaluation techniques to dynamically generate efficient code. The > novel idea behind PyPy JIT is to delay the compilation until we know > all the informations useful for emitting optimized code, thus > being potentially much more efficient than all the current other > alternatives (see the "Related Work" section). > > Currently, the PyPy JIT works only in conjunction with the C backend; > early results are very good, the resulting Python interpreter > can run numeric intensive computations at roughly the same speed of C, > as shown by the `technical report`_ on the JIT. > > Moreover, there is an experimental JIT backend that emits code for the > CLI; it is still work in progress and very incomplete, but it shows > that the it is possible to adapt the PyPy JIT to emit code for object > oriented virtual machines. > > > Porting the JIT to the JVM > -------------------------- > > The goal of this proposal is to extend the PyPy JIT to work in > conjunction with the JVM backend. After the work has been completed, > it will be possible to translate the interpreter into a Python > implementation that runs on top of the JVM and contains a JIT; the JIT > will dynamically translate part of Python programs into JVM bytecode, > which will then be executed by the underlying virtual machine. > > > Porting the JIT to the MLVM > --------------------------- > > As stated above, PyPy JIT for JVM would work by dynamically emitting > and loading JVM bytecode at runtime. Even if this approach has been > tried in a couple of projects (see the "Related Work" section), it has > to been said that the JVM was not originally designed for such > applications; for example, the process of loading a single method is > very expensive, since it involves the creation and loading of a > surrounding class. > > The new Da Vinci Machine contains a lot of interesting features that > could be effectively exploited by the PyPy JIT to produce an even more > efficient implementation of the Python language, as `John Rose said`_ > after the talk with PyPy people. > > Features of the MLVM that could be exploited by PyPy JIT include but > are not limited to: dynamic invocation, lightweight bytecode loading, > tail calls, etc. > > Implementation wise, the JIT backends for the plain JVM and for the > MLVM could share most of the code, with the latter making use of the > special features when needed. > > Moreover, the experience of this project will help the MLVM team to > understand which features are really useful to implement dynamic > languages on top of the JVM and which one we still lack. > > > Deliverables > ------------ > > Due to the its strict dependency on PyPy, it will not possible to > release the result of the work as a separate and independent project. > In particular, to reach the goals of the proposal it will be necessary > to extensively modify parts of PyPy that are already there, as well as > write completely new code. > > If the project goes to completion, the code developed will be > integrated into the PyPy codebase; if Sun requires us to release the code > under the SCA (thus sharing the copyright between the original author > and Sun itself), we will send to Sun a document in unified diff format > that extensively shows all and sole lines of code on which Sun will > have the copyright. > > PyPy is already licensed under the extremely permissive MIT license, > so there are no legal copyright barriers preventing us from sharing > code in such a way. > > > Project completion > ------------------ > > PyPy JIT is still under heavy development; potentially, the resulting > JIT compiler will be able to optimize a large number of Python > programs, but at the moment it gives the best results only with > computational intensive functions that use only operations between > integers. > > We expect to get a pypy-jvm executable that can execute a function > with those characteristics at roughly the same speed as its equivalent > written in Java, excluding the costs of the JIT compilation itself, > which have not been optimized yet. > > For an example of a function with is highly optimized by the PyPy JIT, > look at the `function f1`_: when executed by a pypy-c compiled with > JIT support, it runs roughly at the same speed as its C equivalent > compiled with `gcc -O0`. > > Making the Python interpreter to exploit the full potential of the JIT > is a separate task and it is out of the scope of this proposal; it is > important to underline that once the JVM backend for the JIT is > complete, the resulting pypy-jvm will automatically take advantage of > all the optimizations written for the others backend. > > We also expect to find benchmarks in which the JIT that targets the > MLVM will perform better than the JIT that targets the plain JVM, > though it is hard to specify a precise commitment here without knowing > which features of the MLVM will be possible to use. > > > Relevance to the community > -------------------------- > > Recently the community has shown a lot of interest in dynamic > languages which run on top of the JVM. Even if currently Jython_ is > the only usable implementation of Python for the JVM, PyPy has the > potential to become the reference implementation in the future. > > To have a working JIT for the JVM is an important step towards making PyPy > the fastest Python for the JVM, ever. Moreover, due to the innovative > ideas implemented by PyPy, it is likely that Python could become > the fastest dynamic language that runs on the top of the JVM. > > Finally, PyPy is not limited to Python: it is entirely possible to > write interpreters for languages other than Python and translate them > with the TT; as a proof of concept, PyPy already contains > implementations of Prolog, Smalltalk, JavaScript and Scheme, with > various degrees of completeness. > > Since the JIT generator is independent of the Python languages, it > will be possible to automatically add a JIT compiler to every language > written using the PyPy TT; thus, PyPy could become a very attractive > platform to develop dynamic languages for the JVM. > > > Dependencies on Sun > ------------------- > > There are no dependencies on Sun regarding the implementation of a JIT > compiler that targets the plain JVM. However, in order to implement a > JIT compiler that targets the new MLVM, we need the new features we > want to exploit to be implemented. > > Related work > ------------ > > Dynamic generation of bytecode for object oriented virtual machine is > a hot topic: > > - `this paper`_ shows how this technique is exploited to write an > efficient implementation of EcmaScript which runs on top of the JVM; > > - Jython compiles Python source code to JVM bytecode; however, > unlike most compilers, the compilation phase occurs when the JVM > has already been started, by generating and loading bytecode on > the fly; despite emitting code at runtime, this kind of compiler > really works ahead of time (AOT), because the code is fully > emitted before the program starts, and it doesn't exploit > additional informations that would be available only at runtime > (e.g., informations about the types that each variable can > assume); > > - JRuby supports interpretation, AOT compilation and JIT > compilation; when the JIT compilation is enabled, JRuby interprets > methods until a call threshold is reached, then it compiles the > method body to JVM bytecode to be executed from that point on; > however, even if the compilation is truly just in time, JRuby > doesn't exploit type informations that are known only at runtime to > produce specialized, efficient versions of the function; > > - in the .NET world, IronPython works more or less as Jython; > additionally, it exploits dynamic code generation to implement > `Polymorphic Inline Caches`_. > > PyPy JIT is different of all of these, because runtime and compile > time are continuously intermixed; by waiting until the very last > possible moment to emit code, the JIT compiler is able to exploit all > the runtime informations that wouldn't be available before, e.g. the > exact type of all the variables involved; thus, it can generate many > specialized, fast versions of each function, which in theory could run > at the same speed of manually written Java code. > > Moreover, the JIT compiler is automatically generated by the TT: we > believe, based on previous experiences as Psyco_, that manually > writing a JIT compiler of that kind is hard and error prone, > especially when the source language is as complex as Python; by > writing a JIT compiler generator, we get JIT compilers that are > correct by design for all languages implemented through the TT for > free. > > > Developer > --------- > > Antonio Cuni is one of the core developers of PyPy; he is the main > author of the CLI backend, and the coauthor of the JVM backend; > recently, it began working on the experimental CLI backend for the > JIT. > > Currently, he is a PhD student at Univerist? degli Studi di Genova, > doing research in the area of implementation of dynamic languages on > top of object oriented virtual machines. > > > .. _PyPy: http://codespeak.net/pypy > .. _RPython: > http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html#rpython > .. _`Stackless Python`: http://www.stackless.com/ > .. _`technical report`: > http://codespeak.net/pypy/extradoc/eu-report/D08.2_JIT_Compiler_Architecture-2007-05-01.pdf > > .. _`John Rose said`: http://blogs.sun.com/jrose/entry/a_day_with_pypy > .. _Jython: http://www.jython.org > .. _`function f1`: http://codespeak.net/svn/pypy/dist/demo/jit/f1.py > .. _`this paper`: > http://www.ics.uci.edu/~franz/Site/pubs-pdf/ICS-TR-07-10.pdf > .. _`Polymorphic Inline Caches`: > http://www.cs.ucsb.edu/~urs/oocsb/papers/ecoop91.pdf > .. _Psyco: http://psyco.sourceforge.net/ > From linuxhippy at gmail.com Wed Feb 27 15:06:01 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Thu, 28 Feb 2008 00:06:01 +0100 Subject: DRAFT PROPOSAL: Virtual Machine Interface In-Reply-To: <17c6771e0802270207l30940515g7b0e1a2fdab12508@mail.gmail.com> References: <17c6771e0802270207l30940515g7b0e1a2fdab12508@mail.gmail.com> Message-ID: <194f62550802271506r1c81bedbi207202ab78c3dc80@mail.gmail.com> Hi Andrew, Really cool proposal, and I think a lot projects in the open java world could benefit from this change. E.g. OpenJDK-support by GCJ could help Java in areas on Linux desktop where runtime based programs have to fight hard for acceptance. > 1. Become familiar with the VM interface by attempting to use it from > a non-implementing VM Do you have any idea which JVM this would be? Any chance that you maybe will choose GCJ/GIJ? lg Clemens From dsheppard2k at yahoo.com Wed Feb 27 19:19:29 2008 From: dsheppard2k at yahoo.com (David S) Date: Wed, 27 Feb 2008 19:19:29 -0800 (PST) Subject: Sun Contributor Agreement Message-ID: <429493.89292.qm@web45715.mail.sp1.yahoo.com> Hi Folks, I wonder where the Sun Contributor Agreement should be sent (email address). Also I wonder if I should wait until the proposals are selected before signing the agreement. Thanks in advance, David ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/challenge-discuss/attachments/20080227/c0d52cd4/attachment.html From Tim.Bell at Sun.COM Wed Feb 27 19:56:35 2008 From: Tim.Bell at Sun.COM (Tim Bell) Date: Wed, 27 Feb 2008 19:56:35 -0800 Subject: Sun Contributor Agreement In-Reply-To: <429493.89292.qm@web45715.mail.sp1.yahoo.com> References: <429493.89292.qm@web45715.mail.sp1.yahoo.com> Message-ID: <47C630F3.5080305@sun.com> Hi David: > I wonder where the Sun Contributor Agreement should be sent (email > address). You could fax it to +1-408-715-2540, or scan it and e-mail the result to sun_ca(at)sun.com. > Also I wonder if I should wait until the proposals are selected before signing the agreement. I can't answer that one - sorry. If you feel comfortable with the agreement you may sign at any time. HTH - Tim From gnu_andrew at member.fsf.org Thu Feb 28 00:42:09 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 28 Feb 2008 08:42:09 +0000 Subject: DRAFT PROPOSAL: Virtual Machine Interface In-Reply-To: <194f62550802271506r1c81bedbi207202ab78c3dc80@mail.gmail.com> References: <17c6771e0802270207l30940515g7b0e1a2fdab12508@mail.gmail.com> <194f62550802271506r1c81bedbi207202ab78c3dc80@mail.gmail.com> Message-ID: <17c6771e0802280042i4eb82d3av9c3742b511151953@mail.gmail.com> On 27/02/2008, Clemens Eisserer wrote: > Hi Andrew, > > Really cool proposal, and I think a lot projects in the open java > world could benefit from this change. E.g. OpenJDK-support by GCJ > could help Java in areas on Linux desktop where runtime based programs > have to fight hard for acceptance. > > > > 1. Become familiar with the VM interface by attempting to use it from > > a non-implementing VM > > Do you have any idea which JVM this would be? Any chance that you > maybe will choose GCJ/GIJ? > > lg Clemens > Thanks for the positive feedback. While I'd also like to see GCJ/GIJ work with OpenJDK in the future, it's not an appropriate initial target. The criteria for such an initial target rests more on the VM being quick and easy to modify for testing (GCJ can take an hour to build) and on its existing interface use being relatively clean (GCJ is still not fully integrated with GNU Classpath and maintains its own local versions of some classes). So while GCJ is a target for the future, JamVM and/or JikesRVM seem like more obvious initial targets for me. -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net From anto.cuni at gmail.com Thu Feb 28 02:10:01 2008 From: anto.cuni at gmail.com (Antonio Cuni) Date: Thu, 28 Feb 2008 11:10:01 +0100 Subject: DRAFT PROPOSAL - Porting the PyPy JIT to JVM and MLVM In-Reply-To: <47C5A065.5010302@sun.com> References: <47C59B0E.2000003@gmail.com> <47C5A065.5010302@sun.com> Message-ID: <47C68879.9010200@gmail.com> Charles Oliver Nutter wrote: > I'm also interested in this sort of approach for JRuby, but given > limitations of code generation, classloading, and method handles under > JDK6- I've held off on continuing such work. In an ideal world, it would > be trivial and lightweight to iteratively generate call sites, method > handles, JITted method bodies, and more to create an increasingly more > adapted call pipeline. As it stands, JRuby only can do code generation > for method handles at startup and for JITted methods once at runtime, > already paying a fairly high permgen and class maintenance cost. The > features of the MLVM are expected to lessen this pain. I suspect that the plain JVM version of PyPy JIT will suffer of the same problems; I've not yet made benchmarks, but from what I heard it seems that the process of loading methods is costly on the current JVMs. That's why the short term goal of the PyPy JIT is to generate fast code, not to generate code fast :-). For JRuby, maybe the are ways to reuse the PyPy machinery to automatically produce a JIT from it (e.g. by writing a Java frontend to the translation toolchain), but of course this would be a veeeery long term goal :-). > Antonio: Do you have a feel for how much of this work would likely end > up producing idiomatic JVM bytecode and how much might require > modification to the JVM itself, or put differently how likely it would > be that the PyPy JIT would need to target JVM components other than its > bytecode interpreter and JIT? I'm growing more interested in the > possibility of expanding the capabilities of OpenJDK by making it > available in ways other than "good old Java bytecode". The proposal > earlier today by Mr. Hughes may also play in this direction...I admit I > have not read it yet. I honestly have no clue about it yet. In an ideal world, it should be enough to produce "good old java bytecode" and let the JIT of the VM to do all the needed optimizations, but we cannot know in advance and I suspect it won't be enough, i.e. the code produced won't be optimal. About the idomatic JVM bytecode; I think the code generated will be more or less idiomatic apart from promotion_: by design, PyPy JIT generates a lot of small chunks of code that need to be chained together; in particular, to implement promotion we need a "growable switch" in which we can add new cases at runtime: since I don't think it is possible to dynamically modify the bytecode of an existing method, we need to think an alternative way to implement it. Having a more direct interface to the underlying VM would probably help greatly, but I have to admit that I don't know much of what you could do with it. E.g., could it give you the possibility to change the bytecode of an existing method? .. _promotion: http://codespeak.net/pypy/dist/pypy/doc/jit.html#promotion ciao Anto From charles.nutter at sun.com Thu Feb 28 03:06:17 2008 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Thu, 28 Feb 2008 05:06:17 -0600 Subject: DRAFT PROPOSAL - Porting the PyPy JIT to JVM and MLVM In-Reply-To: <47C68879.9010200@gmail.com> References: <47C59B0E.2000003@gmail.com> <47C5A065.5010302@sun.com> <47C68879.9010200@gmail.com> Message-ID: <47C695A9.1060407@sun.com> Antonio Cuni wrote: > I suspect that the plain JVM version of PyPy JIT will suffer of the same > problems; I've not yet made benchmarks, but from what I heard it seems > that the process of loading methods is costly on the current JVMs. > That's why the short term goal of the PyPy JIT is to generate fast code, > not to generate code fast :-). *Very* costly. When run in 100% AOT mode, JRuby takes 50-200% longer to start up most Rails apps. At least we don't have it as bad as the CLR folks...since their generated code has to also immediately JIT to native code, IronPython takes several *minutes* to start up for some apps. But I believe we can do a lot more to improve this on JVM. This is largely why we interpret at first (the other major reason being that I knew I couldn't write the whole compiler at once, so we released a partial compiler in JIT mode for 1.0). > For JRuby, maybe the are ways to reuse the PyPy machinery to > automatically produce a JIT from it (e.g. by writing a Java frontend to > the translation toolchain), but of course this would be a veeeery long > term goal :-). Hopefully not too long term...at least if we can find ways to feed in the same structures to your TT. We discussed what might be required when John Rose and I met with the other PyPy folks a few months ago. > I honestly have no clue about it yet. In an ideal world, it should be > enough to produce "good old java bytecode" and let the JIT of the VM to > do all the needed optimizations, but we cannot know in advance and I > suspect it won't be enough, i.e. the code produced won't be optimal. This may be the case...but I think we can do a lot for Python on JVM with even a naive first attempt at this, especially since the naive first attempt with PyPy will probably be pretty good. > About the idomatic JVM bytecode; I think the code generated will be more > or less idiomatic apart from promotion_: by design, PyPy JIT generates a > lot of small chunks of code that need to be chained together; in > particular, to implement promotion we need a "growable switch" in which > we can add new cases at runtime: since I don't think it is possible to > dynamically modify the bytecode of an existing method, we need to think > an alternative way to implement it. The switch would need to be generated into its own method+class, and we'd throw it away as needed to generate new ones. Again, permgen hell, but it can be managed. > Having a more direct interface to the underlying VM would probably help > greatly, but I have to admit that I don't know much of what you could do > with it. E.g., could it give you the possibility to change the bytecode > of an existing method? I believe this is possible already through some of the debugging interfaces, and potentially could be made generally applicable with a bit of tweaking. - Charlie From roman.kennke at aicas.com Thu Feb 28 06:38:23 2008 From: roman.kennke at aicas.com (Roman Kennke) Date: Thu, 28 Feb 2008 15:38:23 +0100 Subject: DRAFT PROPOSAL: Portable GUI backends Message-ID: <1204209504.22429.45.camel@mercury> Hello, We (that is aicas, especially Mario Torre and me) would like to propose a project that aims to improve the AWT and Java2D interfaces to enable the implementation of external backends to AWT/Java2D. Feedback and suggestions are very welcome. Cheers, Roman Draft proposal -------------- Portable GUI Backends Roman Kennke and Mario Torre aicas GmbH 0. Summary ---------- In order to support the spread of Java for graphical applications, particularly in embedded systems, aicas proposes to improve the AWT and Java2D in OpenJDK to enable easier porting of AWT to new platforms. 1. Introduction --------------- The AWT is designed as an abstract toolkit (hence the name: abstract windowing toolkit). There is a public Java API, which is the same across all platforms, and platform specific implementation code for each supported platform. These two parts are isolated from each other through the AWT peer interface. This basically comprises the classes java.awt.Toolkit, java.awt.GraphicsEnvironment, the interfaces in java.awt.peer (which are not part of the spec), and a couple of related classes. By implementing these interfaces, it should be possible to create new backend implementations for AWT and (by extension) Java2D. Unfortunately, the current implementations do not abide by this interface. In various places in Swing and AWT, this interface is circumvented and OpenJDK specific implementation classes (e.g. SunToolkit, SunGraphics2D) are called directly. This defeats the whole purpose of having such an interface in the first place and makes porting AWT to new platforms unnecessarily hard or impossible without modifying Swing and AWT themselves. Not only does the code simply assume that the current implementation is the OpenJDK implementation, but the interface itself is often incomplete. To make things even worse, there is not an interface for font implementations. Instead, there is only one font implementation tied into various places in OpenJDK. Using this implementation in a new AWT backend implementation should, in theory a least, be possible; but again, the font implementation is so tied to internal implementation classes (e.g. SunGraphicsEnvironment) that this would not work either. Having a cleanly separated interface for the font implementation would enable reusing the existing implementation in a new AWT backend, or even for replacing the font implementation, e.g., with a platform-specific one. At a lower level in the Java2D stack, there are various interfaces and extension points which enable easy porting of the graphics stack. The OpenJDK Java 2D implementation has a rendering pipeline with various generic pipes and render loops, which make porting the graphics stack as easy as providing a render loop for setting and getting single pixels from the render surface, but still can be optimized by providing more powerful primatives. Usually graphics primitives such as lines, rectangles, and circles are needed for good performance, but one can also include more sophisticated operations such as blits, compositing, and transparency. This is generally a very well thought out design, but is also not without its problems. Because nobody seems to have ever created a AWT/Java2D port to another platform, the architecture does not allow for flexible extension at some points, e.g., volatile images[1]. 2. Goals and Deliverables ------------------------- The project will have two parts. The first one focuses on the extending the external interface. The second on documenting and cleaning up the internal Java2D interface. In the end, it should be much easier to port to a new platform. This will be demonstrated with a concrete example. 2.1 Extenal AWT/Java2D Peer Interface ------------------------------------- As described above, it is currently not possible to provide an external implementations for the AWT and Java2D peer interfaces. The first goal of this project is to clean up the interface and the Swing and AWT implementation, so that it is possible to create an AWT backend without changing any details in Swing or elsewhere. It is important to note that there already are a couple of such implementations. For example, the FBToolkit project [2] and the Escher and GTK based peers in GNU Classpath [3], all of which require hacks and patches to OpenJDK code to actually work with OpenJDK. This subproject would cover the following tasks. - Improve Swing and AWT, so that they do not rely on specific implementation details. - Add functionality to the AWT peer interface where necessary. - Propose a new interface for font implementations. This should at least enable the reuse of existing font implemenation in new AWT stacks. Ideally one could even use an external implementation for fonts. - Document all the necessary interfaces which are required to port AWT backends. - Create a proof-of-concept AWT/Java2D peer implementation that makes use of these public interfaces (and not the internal implementation classes). - Provide test cases for changed and new code. 2.2 Internal Java2D Interfaces ------------------------------ Implementing a whole complete and compatible Java2D stack is a huge task, and not feasible for small to midsized projects. Considering that there are already all the necessary pieces in OpenJDK, it would be nice to make it possible to reuse these in new ports of AWT/Java2D backends. As described above, the general architecture does seem to enablle that, but has small problems in various places. Also, there is practically no documentation on how to implement an external rendering pipeline. This part of the project should improve this through the following tasks. - Extend the Java2D architecture to be reusable in new AWT/Java2D ports. - Document the architecture and interfaces to be used, including an architectural overview, API documentation, and a tutorial. - Create a proof-of-concept implementation that makes use of OpenJDKs rendering pipeline. - Provide test cases for changed and new code. 3. Previous work ---------------- Mr. Kennke is the author of the Escher based toolkit in GNU Classpath, and has helped with the GTK based toolkit in GNU Classpath. Both of these implement the public interfaces only and work with Classpath's Swing. The authors have created (very) prototypical ports of these to OpenJDK [4] and create a very early prototype for a Java2D port based on the internal Java2D interfaces [5]. This work should demonstrate that the proposed project is feasible, and it will serve as a basis for further development. References: ----------- [1] http://mail.openjdk.java.net/pipermail/2d-dev/2008-February/000142.html [2] https://fbtoolkit.dev.java.net/ [3] http://www.gnu.org/software/classpath/ [4] http://kennke.org/blog/2007/06/21/gtk-peers-on-openjdk/ [5] http://kennke.org/blog/2008/02/25/escher-on-openjdk-graphics/ -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org 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-0 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Gesch?ftsf?hrer: Dr. James J. Hunt From Richard.Sands at Sun.COM Thu Feb 28 10:41:31 2008 From: Richard.Sands at Sun.COM (Rich Sands) Date: Thu, 28 Feb 2008 13:41:31 -0500 Subject: Question about the SCA In-Reply-To: <47C329FD.2070606@gmail.com> References: <47C329FD.2070606@gmail.com> Message-ID: <47C7005B.5060708@sun.com> Hi Antonio and all, Sorry it took so long to answer this. Answers below. -- rms Antonio Cuni wrote: > Hi all, > > I am one of the core developer of PyPy_. > > We are considering writing and sending a proposal about a backend for > `PyPy's JIT generator`_ targeting the JVM (and/or maybe the new Da > Vinci Machine). > > I won't discuss the details of the proposal here because it is not > ready yet, but I would like a clarification about the Sun Contributor > Agreement, which you need to sign to enter the challenge, according to > the rules. > > After having read it, I seem to understand that the Sun Contributor > Agreement applies only to the code that goes into a project directly > managed or owned by Sun; what it's not clear to me is how this > interacts with the projects that would eventually be sponsored by Sun > but are not directly managed by it, as in the case of our proposal, > for which the code developed would go into PyPy's codebase, which is > clearly not owned nor managed to Sun. > > Our questions are: > > 1. Is it possible to enter the challenge even if the code being > developed would be part of an existing project/codebase not directly > related to Sun? Yes. In addition, there must be a clear way for people visiting the OpenJDK community site to find all the Challenge projects and the open work being done on them. While it is ok for work to happen hosted someplace other than on the OpenJDK project pages, that doesn't remove the requirement to do all development in the open, nor to publish the source code, and to make it easy to find all of this from the OpenJDK site. See 4.C. of the Official Rules at http://openjdk.java.net/challenge/rules/ for details. We think the easiest way for most projects to comply with this would be to host the projects on the OpenJDK site but we understand that isn't always possible. > > 2. Does the Sun Contribution Agreement still apply also to that code? Yes. Whether the work is done on the OpenJDK site or not, it still must be contributed under the terms of the SCA. > > 3. (In case the answer to (2) is "yes") Which parts of the codebase > will Sun have rights on? Only the new code developed under the terms > of the challenge, even if that code it's not usable without the > existing code? I hope that the Challenge does not require to give > to Sun the rights over all the whole codebase, because it wouldn't be > practical to find all the 70 existing developers of PyPy that currently > hold the copyright of the various pieces of code. Only the code developed as part of the Challenge. Sun does not expect independent projects to contribute the whole thing to OpenJDK under the SCA as a condition of entry! > > > Thanks, > Antonio > > .. _PyPy: http://codespeak.net/pypy/ > .. _`PyPy's JIT generator`: > http://codespeak.net/pypy/dist/pypy/doc/jit.html -- Rich Sands Phone: +1 781 881 4067 / x81524 Community Marketing Manager Email: richard.sands at sun.com Java SE Marketing SMS: 6172830027 at vtext.com Sun Microsystems, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From neal at gafter.com Thu Feb 28 23:24:09 2008 From: neal at gafter.com (Neal Gafter) Date: Thu, 28 Feb 2008 23:24:09 -0800 Subject: FINAL PROPOSAL: Closures for Java Message-ID: <15e8b9d20802282324q18c3120q37799e4bcc4feea5@mail.gmail.com> FINAL PROPOSAL: Implement Closures for Java ===================================== Neal Michael Gafter neal at gafter.com Implement Lambda Expressions, Function Types, and Control Abstraction I propose to produce a feature-complete prototype of the Java bytecode compler (javac) features for the Closures specification appearing at http://www.javac.info/closures-v05.html suitable for integration into the openjdk javac compiler as part of the reference implementation of a future platform specification. The specification includes the following major features o closure literals (sometimes called lambda expressions) o function types o control invocation statements This includes support for the following component features o restricted and unrestricted forms o the closure conversion o exception type parameters o union types o definite assignment o the type Unreachable (to be renamed Nothing) o loop abstractions o access to non-final variables within a closure The prototype shall be complete in providing support for all features of the specification, including those described above, as well as supporting "nonlocal" return, break, and continue in unrestricted contexts. The Clear Need ============== A discussion of the needs satisfied by this proposal appears in a draft JSR proposal at http://www.javac.info/consensus-closures-jsr.html. In summary, the draft specification supports the development and use of APIs that significantly improve the use of concurrency for multicore systems, and enables the development of APIs that significantly reduce boilerplate for some common programming patterns. Development Guidelines ====================== Devlopment of the prototype shall take place as an openjdk project to be created within the openjdk compiler group, in accordance with the prevailing community governance procedures for such development. The prototype shall be contributed under the Sun Contributor Agreement. Dependence on Sun and other resources ===================================== While the development of the specification is outside the scope of this project, it is likely that the specification will evolve in response to community feedback. For example (as discussed in the draft JSR specification) I expect to add support for constructing a closure by reference to an existing Java method ("method reference"). Any such changes in the specification shall be followed by inclusion of those changes in the scope of the project. Development of the prototype shall take place independently of Sun Microsystems. I expect involvement of Sun Microsystems employees - particularly Alexander Buckley, the editor of the Java Language Specification, and Maurizio Cimadamore, a specialist in type systems, in refining the specification and providing feedback about specification changes that will be necessary to integrate the work into the Java Language Specification and to integrate it with other language changes that might be under consideration. Such specification refinements shall be reflected in the prototype. In addition, I expect continued collaboration with other authors on the draft specification, including specifically Gilad Bracha, James Gosling, and Peter von der Ahe. Additional work may be desireable in the virtual machine or core libraries in support of this work. For example, it would be useful for the virtual machine to provide support for proper tail recursion and to generate function type interfaces on demand. It would be helpful to extend the reflection libraries to support the new features. Such additional specification and implementation work is outside the scope of this project. Project Plan and Milestones =========================== Development shall proceed as follows: 2008-04-30 An initial prototype shall be published as an openjdk patch, providing support for most of the features of the specification with unit tests and regression tests. 2008-05-30 An extension of the com.sun.source, javax.lang.model, and javadoc APIs shall be included in a revision of the prototype. 2008-06-30 An update to the prototype shall be published that provides support for nonlocal return, break, and continue, and any other remaining features from the initial specification. 2008-07-18 Any specification changes preceding 2008-06-01 shall be reflected in a revision of the prototype. 2008-08-03 Final, feature-complete submission of the Closures prototype shall be delivered at this time. In addition to these milestones, I expect to provide regular prototype updates in response to bug reports from users. While not formally part of the project, I expect to recommend JVM, library, and other platform changes that are likely to improve performance, usability, or integration with the platform or other language changes likely to be included at the same time as closures. Copyright ========= This proposal, in its entirety, is hereby contributed under the terms of the Sun Contributor Agreement. From linuxhippy at gmail.com Fri Feb 29 09:42:46 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Fri, 29 Feb 2008 18:42:46 +0100 Subject: DRAFT PROPOSAL: Implement XRender pipeline for Java2D Message-ID: <194f62550802290942t50069cbblb5f888a53f784271@mail.gmail.com> Hi again, This is my final draft proposal, it would be great if somebody could check wether it meets the official "specification" - and is a valid proposal. Sorry for the additional traffic... Thanks for all the suggestions and ideas to improve it :) ---------------------------------------------------------------------------------------------------- 1.) Introduction The more advanced features of Java2D are used in a lot new key technologies like JavaFX, Nimbus, SVG, Arith and even native Swing themes like the GtkLookAndFeel and without any doubt their use will grow further. Since its introduction, Java2D supports very advanced rendering operations, although only very basic operations were accelerated by hardware, because the underlying APIs were very poor. However software-rendering leads to low performance and bad user experience in this case. Modern 3D graphic APIs, like OpenGL or Direct3D, allow to map most of Java2D's functionality without the need for expensive read-backs and/or software rendering. To make that functionality available to the Java platform two new ?pipelines" where created: The OpenGL pipeline for non Windows platforms, and the Direct3D pipeline for the Microsoft Windows operating systems only. However OpenGL on Unix in general has some disadvantages compared to X11 for typical desktop applications, because of poor drivers its often not possible to use that new functionality and Java falls back to the default X11 rendering pipeline. An Xrender backend for Java2D would provide almost the same features as the existing OpenGL pipeline, however would run on a much larger set of hardware and would integrate better into existing X11 based desktops. With the Xrender backend developers and users could rely on almost the same set of functionality accelerated by default on all platforms supported currently by OpenJDK, e.g. JavaFX animations could run at almost the same speed everywhere. 2.) Status Quo The existing X11 pipeline used on Unix systems is only capable of accelerating basic operations and falls back to software rendering even for often used operations like antialiasing (even for text!) or translucent images often causing expensive VRAM readbacks. Because of X11's very limited rendering capabilities Xrender was introduced back in 2001, and after a long delay first drivers are available which accelerate large areas of Xrender. XRender allows to accelerate most of Java2D's functionality, and it is considered to be the de-facto standard for advanced 2D graphics, already used by a large set of libraries and toolkits like Cairo, GTK+, QT4 and KDE4. Because of the broad and extensive use of Xrender there is currently major work ongoing to modify drivers for better Xrender performance. There is already an OpenGL backend for Java2D which is about as powerful as its Direct3D counterpart on Windows. Unlike on Windows where Microsoft starting with Windows Vista more or less deprecated all interfaces except Direct3D, and therefor forces GPU/driver manufacturers to create drivers well suited also for 2D rendering, on Unix good OpenGL drivers are still rare and only proprietary drivers are till now able to run the OpenGL pipeline. However those proprietary drivers are often optimized for heavy-weight 3D applications like games and are not really suited for rendering light-weight simple 2D applications. A small overview about the advantages/disadvantages Xrender has compared to OpenGL: + Lower per-primitive overhead: Because Xrender is compared to OpenGL a lot simpler, there is less work for the accelerating driver to do for each primitive rendering operation. This is especially important for complex shapes which are transformed to many rectangles which then are passed to the underlying graphic API. To make it short: Because Xrender focuses on only a small set of ?simple" operations, driver implementers can focus on making those few operations as fast as possible. + Support for higher-level primitives: Xrender has support for client-side font rendering, which means glyphs which are cached in vram can be shared across different applications. For OpenGL each application has to upload its glyphs into a private texture wasting large amounts of Vram. Because it was designed with 2D graphics in mind many features can be directly mapped to Xrender without the need of complex shaders. + Reliable AntiAliasing: Because Xrender specifies exactly how antialiasing has to be done, Java2D can rely on Xrender's antialiasing capabilities. The Direct3D and OpenGL pipelines render a alpha-mask in software, upload it to vram and only let the GPU only do the final composition step. Because of this, the amount of data transferred between the Xserver and the Java application would be reduced a lot, making antialising even usable over slow remote connections. + Better driver support: On Linux only proprietary OpenGL implementations provide enough functionality to let the OpenGL pipeline run. However even those proprietary drivers were/are buggy in the code-paths exercised by the OpenGL pipeline - sometimes new drivers even broke the OpenGL pipeline. For Xrender there are already many optimized drivers, both open-source (Intel, ATI, ...) and proprietary (Nvidia). Because of the high adaption rate of Xrender lately (KDE4, Cairo, GTK+, ...) it can be expected that soon more and more drivers will support Xrender acceleration. + Better desktop integration: Xrender applications are ?native" X11 applications, and therefor work well with composition managers. They also get visuals optimized for 2D, and do not waste Vram with additional buffers they get, although they are not used. + Better network transparency: Although OpenGL can also be made network-transparent via GLX, the OpenGL API was not designed to perform especially well in a network environment. X11/XRender relies on the Client-Server approach and therefor is optimized for exactly this case. - Not programmable: A disadvantage of Xrender is that its not as flexible as OpenGL. OpenGL allows to use shaders to implement features not provided by fixed functionality, the only solution for a Xrender based backend is to fall back to software rendering. 3.) Goals The goal of this proposal is to make use of Xrender for accelerating even advanced Java2D functionality. This would allow multimedia applications/content like JavaFX to take advantage of modern hardware, and would bring JDK6Update10 graphic features also to X11/Unix based platforms. Some of the most important enhancements compared to the X11 pipeline include: * Accelerated text rendering for normal, antialiased and subpixel antialiased text. * Support for translucent images * Composition (colors with alpha values, ...) * Antialiasing A long-term goal would be to make the existing X11 pipeline obsolete once the XRender backend has prooven to be stable, removing the burden of maintaining two, in their dedication similar, backends. 4.) Approach XRender has a lot in common with OpenGL/Direct3D and is a very low-level API which supports only a limited number of drawing primitives but it is very flexible in the way of operations it operates with those operations. Therefor the approach would be to create a brand new backend based on the shared code developed for the OpenGL/Direct3D pipelines in JDK6-u10. The advantage of this approach would be a ?clean start", as well as a lot shared code between OpenGL/Direct3D/XRender backends. The downside is that some highly optimized primitives which are supported by X11's core drawing (Arcs, Elipses, ..) maybe perform a little bit less well. Furthermore new code needs a lot of testing. 5.) Milestones 5.1) Create a skeleton which is able to use the shared OpenGL/Direct3D code 5.2) Implement only enough to functionality to make software-rendering-loops work. 5.3) Extend the created skeleton, accelerate basic operations -> Make typical Swing/Ocean applications work well. 5.4) Accelerate more advanced functionality like gradients, composition and antialising -> Accalerate most of Java2Demo, make the Nimbus LnF work well. 5.5) Extensive profiling and compatibility testing, using self written, Sun's jtreg and real- world tests, reporting performance and implementation problems back to driver programmers. Make sure large graphical applications work well. 6.) Developer Clemens Eisserer is Student at the Technical University of Vienna (Information Technology) and: * Has submitted patches and regression tests to jdk-collaboration (plugin, webstart) and OpenJDK (Java2D, Corelibs) * Implemented JLayeredPane for SwingWT: http://swingwt.sourceforge.net/ * Ported Kaffe's XAWT to GCJ: http://sf.net/projects/xawt * Is working on an open-source remote-swing project: http://juibrowser.sourceforge.net/ * Compiled and packaged a free JVM for the Nokia770 internet tablet. * Is working on enhancing GTK's theme API and later on adapting GtkLookAndFeel to take advantage of those enhancements: http://bugzilla.gnome.org/show_bug.cgi?id=515600 * Finished some commercial projects written in Java with focus on client-server architectures 7.) Links, References, ... http://keithp.com/~keithp/render/ http://www.nabble.com/Best-way-organizing-XRender-additions-for-the-X11-pipeline--td14152122.html http://www.phoronix.com/scan.php?page=article&item=934&num=1 http://bugs.sun.com/view_bug.do?bug_id=5086814 (RFE: Java 2D: consider Xrender for anti-aliased text on remote X11) http://bugs.sun.com/view_bug.do?bug_id=6307603 ([X11] Use RENDER extension for complex operations done in software) From anders.bjorklund at sajtopia.se Fri Feb 29 02:26:25 2008 From: anders.bjorklund at sajtopia.se (=?ISO-8859-1?Q?Anders_Bj=F6rklund?=) Date: Fri, 29 Feb 2008 11:26:25 +0100 Subject: FINAL PROPOSAL: Meta-compiler for non-java code to run on the java virtual machine Message-ID: <47C7DDD1.6040808@sajtopia.se> FINAL PROPOSAL: Meta-compiler for non-java code to run on the java virtual machine Stig Anders Bj?rklund anders.bjorklund at sajtopia.se ----------------------------------------------------------------------- I propose to implement A meta-compiler for non-java code to run on the java virtual machine. In addition, standard classes and interfaces needed to promote building reusable library classes will be provided. The project has two main goals: 1. To simplify the creation and manipulation of binary files - in particular the java class format. Instrumentation for this purpose is used by the meta-compiler. Parts of the instrumentation can also be used outside of this project. Related projects exist[1,2], but not under the SCA license as far as I am aware. 2. To simplify and shorten the time it takes to initially port a new language to the JVM. By using the meta-compiler and by implementing language specific constructs as java classes, the time to port a language to the JVM should be significantly shortened. Since certain features exist in a number of different languages, a growing body of library classes can make porting regular languages faster, given that the library classes all implement the same interfaces. If all library classes implement the same interfaces, a meta- compiler can translate a syntax tree into an instance graph created from the different library classes using a language lookup table. These classes may also enforce language rules such as no changing final variables or security checks for example. Different computer languages may use different libraries or they can share parts. Given the potential scope of this project, I intend to focus on a small subset in the form of a limited language similar to BASIC, with a limited library. Project plan: 15:th of may - library classes of a limited BASIC like language implemented. Library supports a least one loop format and at least addition and subtraction. Additional functionality such as reading from the keyboard and writing to the console are also implemented. 1:st of june - parsing of limited BASIC like source code and transforming to invokable object graph completed. (Serializing the object graph in this step would be very similar in principle to final compilation.) 15:th of june - all instrumentation completed for class files. 15:th of july - meta-compiler creates fully functional .class files with main method, from limited BASIC like source files. The created classes can be started by typing java . Demo program should accept input from keyboard, perform computation based on input, and output the result of the computation to the user. --------------------------------------------------------------- This would constitute a complete implementation of the proposal. --------------------------------------------------------------- (Remaining time in reserve.) If project is selected, all source code and binaries will be available for download during and after development for the OpenJDK community and others. Code and binaries will be hosted at http://www.hilexed.org (will be activated after selection) Dependence on Sun: This project does not depend on Sun. Experience: I currently work part time as java instructor and part time as developer. Some projects: PassTicket Generator for z/OS - encrypted authentication. Creation and bitlevel manipulation of authentication tokens. Commercial project. Parser and statistics tool for System z utilization data. Commercial project. HiLexed project at sourceforge.net - lexer and several parsers: xml, ldif and limited java code parsed. Open source. Monaco project at sourceforge.net - remote code execution. Client code is unaware of execution context through proxy class. Open source. Impact The project could further promote the idea of the JVM as a multi language platform. Copyright This proposal in its entirety including any source code and binaries resulting from it is hereby contributed under the terms of the Sun Contributor Agreement References 1. Apache Foundation - Byte Code Engineering Library http://jakarta.apache.org/bcel/ 2. Jasmin - Assembler for the JVM http://jasmin.sourceforge.net/