From cadenza at paradise.net.nz Sat Mar 1 00:38:29 2008 From: cadenza at paradise.net.nz (Bruce Chapman & Barbara Carey) Date: Sat, 01 Mar 2008 21:38:29 +1300 Subject: Rules Message-ID: <47C91605.8010104@paradise.net.nz> Do we have to wait for the Offical rules to be updated before submitting draft or final proposals from countries which are rumoured as having been added to the list, and if so when might that update occur? Bruce From linuxhippy at gmail.com Sat Mar 1 03:05:16 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Sat, 1 Mar 2008 12:05:16 +0100 Subject: [OpenJDK 2D-Dev] DRAFT PROPOSAL: Implement XRender pipeline for Java2D In-Reply-To: <47C89CA3.9060603@Sun.COM> References: <194f62550802290947o600adab5x66e2fd0c1026eac@mail.gmail.com> <47C89CA3.9060603@Sun.COM> Message-ID: <194f62550803010305q196ff8d8g3525f57ca6130312@mail.gmail.com> Hi Dmitri, > this looks like a good project. > We currently have no solution for the remote X > case, XRender pipeline may be a good answer. XRender would also have many advantages when used on a local X-Server... Scaling, transformations, antialiasing, composition ... :) > The requirements are simple: be at least as fast, stable > and produce very similar rendering as the X11 pipeline =) > It also should work on at least the same platforms > as openjdk - meaning Solaris and Linux. Of course, these are also my goals. In general it should be faster than the X11 pipeline, and also faster than the OpenGL pipeline for simple primitives. > Some notes - if this project is to be integrated into > the openjdk at some point as the default pipeline on unix > (with the current X11 pipeline as backup) it will have to meet > very stringent requirements in terms of performance, > stability and rendering quality. I don't think that I can reach integration-quality within the few months the challenge is running, at least I would not have the heart to do so in such a short timeframe (it should have been extensive tested and benchmarked before integration). But of course my goal is to produce something working very well, which can be used out-of-the box by almost everybody with a modern X-Server. However as you know I am very interested to get this integrated in the long-term, so I won't stand still after the challenge. > I can be your contact point for the project, I'll > point you to other people if needed. But unfortunately > we're all super-busy now, so don't expect immediate > responses.. That would be really great, thanks a lot :) Thanks a lot for beeing that patient, lg Clemens 2008/3/1, Dmitri Trembovetski : > > Hi Clemens, > > We currently have no solution for the remote X > case, XRender pipeline may be a good answer. > > Some notes - if this project is to be integrated into > the openjdk at some point as the default pipeline on unix > (with the current X11 pipeline as backup) it will have to meet > very stringent requirements in terms of performance, > stability and rendering quality. > > The requirements are simple: be at least as fast, stable > and produce very similar rendering as the X11 pipeline =) > > It also should work on at least the same platforms > as openjdk - meaning Solaris and Linux. > > I can be your contact point for the project, I'll > point you to other people if needed. But unfortunately > we're all super-busy now, so don't expect immediate > responses.. > > Thanks, > > Dmitri > > > Clemens Eisserer wrote: > > Hi, > > > > Also sorry for cross-posting, I thought it wouldn't be a bad idea to > > let you guys on the 2d-dev list know about my proposal. Sorry for the > > traffic. > > > > I would be very happy about suggestions and ideas howto enhance the > > proposal as well as maybe some patronage at > > challenge-discuss at openjdk.java.net. > > I have to admit the best that I could imagine is something like a > > supporter directly from Sun, like what "Charles Oliver Nutter" did > > for the Better-native-Interface-Proposal ;) > > > > Thanks for reading, lg Clemens > > > > --------------------------------------------------------------------------------------- > > 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 Richard.Sands at Sun.COM Sat Mar 1 05:20:31 2008 From: Richard.Sands at Sun.COM (Rich Sands) Date: Sat, 01 Mar 2008 08:20:31 -0500 Subject: Rules In-Reply-To: <47C91605.8010104@paradise.net.nz> References: <47C91605.8010104@paradise.net.nz> Message-ID: <47C9581F.1020602@sun.com> No need to wait - send away! Consider the rules to have been updated. We're just a little behind on all the stuff going on, but those countries are definitely added. Just to remind folks, the added countries are: Austria Cambodia Croatia New Zealand Philippines Romania Singapore Venezuela Thanks! -- rms Bruce Chapman & Barbara Carey wrote: > Do we have to wait for the Offical rules to be updated before submitting > draft or final proposals from countries which are rumoured as having > been added to the list, and if so when might that update occur? > > Bruce -- 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 Sat Mar 1 05:36:41 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Sat, 1 Mar 2008 14:36:41 +0100 Subject: Rules In-Reply-To: <47C9581F.1020602@sun.com> References: <47C91605.8010104@paradise.net.nz> <47C9581F.1020602@sun.com> Message-ID: <194f62550803010536hd8caefaj9dcbfc1a4499adb0@mail.gmail.com> Great to see Austria in the list, thanks a lot for your engagement :) Thanks, Clemens 2008/3/1, Rich Sands : > No need to wait - send away! Consider the rules to have been updated. We're just aen > little behind on all the stuff going on, but those countries are definitely added. > Just to remind folks, the added countries are: > > Austria > Cambodia > Croatia > New Zealand > Philippines > Romania > Singapore > Venezuela > > Thanks! > > -- rms > > > Bruce Chapman & Barbara Carey wrote: > > Do we have to wait for the Offical rules to be updated before submitting > > draft or final proposals from countries which are rumoured as having > > been added to the list, and if so when might that update occur? > > > > Bruce > > > -- > 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 Sat Mar 1 09:17:22 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Sat, 1 Mar 2008 18:17:22 +0100 Subject: FINAL PROPOSAL: Implement XRender pipeline for Java2D Message-ID: <194f62550803010917u60b209e0s532e43a9d25f755d@mail.gmail.com> Hello again, This is my final proposal submission, if something is still wrong please notify me so I can corrent it. Thanks, lg Clemens Eisserer Final Proposal: 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 e ceisserer _at_ gmail.com (preferred for private communication) linuxhippy at gmail.com (mailing list account) 8.) 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)ven 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 and transfer the result to screen. 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. The goal of this milestone is to reach a state where the pipeline is useable and works well with most system configurations and applications. A long time goal (which is not included in the proposal) is to get the XRender pipeline integrated into JDK7, maybe replacing the somewhat dated X11 as default pipeline. 6.) Dependence on Sun There are no special dependencies on Sun except maybe a contact point for general questions about the design of existing Java2D pipelines. Dmitri Trembovetski from the Java2D development team has offered to be a contact point for this. 7.) 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 * Has worked on a free vocabulary trainer: http://sourceforge.net/projects/jvtrain * Finished some commercial projects written in Java with focus on client-server architectures Adresse: Clemens Eisserer A-4483 Hargelsberg Schmiedberg 25 Email: ceisserer _at_ gmail.com (preferred for private communication) linuxhippy at gmail.com (mailing list account) 8.) 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 linuxhippy at gmail.com Sat Mar 1 09:35:04 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Sat, 1 Mar 2008 18:35:04 +0100 Subject: FINAL PROPOSAL: "Implement XRender pipeline for Java2D" (2nd submission) Message-ID: <194f62550803010935j166bd4e1o1b95dc3cb7e1ec40@mail.gmail.com> Hello again, Sorry, something went wrong with copy&paste for my first submission - this one (2nd) obsolets the first one. If something is wrong, please let me know. Thanks, Clemens Eisserer FINAL PROPOSAL: "Implement XRender pipeline for Java2D" 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 accaleration 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 and transfer the result to screen. 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. The goal of this milestone is to reach a state where the pipeline is useable and works well with most system configurations and applications. 6.) Dependence on Sun There are no special dependencies on Sun except maybe a contact point for general questions about the design of existing Java2D pipelines. Dmitri Trembovetski from the Java2D development team has offered to be a contact point for this. 7.) 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 * Has worked on a free vocabulary trainer: http://sourceforge.net/projects/jvtrain * Finished some commercial projects written in Java with focus on client-server architectures Adresse: Clemens Eisserer A-4483 Hargelsberg Schmiedberg 25 Email: ceisserer _at_ gmail.com (preferred for private communication) linuxhippy at gmail.com (mailing list account) 8.) 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 anto.cuni at gmail.com Sat Mar 1 10:17:41 2008 From: anto.cuni at gmail.com (Antonio Cuni) Date: Sat, 01 Mar 2008 19:17:41 +0100 Subject: FINAL PROPOSAL: Porting the PyPy JIT to JVM and MLVM Message-ID: <47C99DC5.3020005@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 or 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 apply partial evaluation techniques to automatically turn the interpreter into a JIT compiler which generates efficient code dynamically. The key idea behind the PyPy JIT is to systematically delay compilation until we know all the information useful for emitting optimized code, thus being potentially much more efficient than all the current other alternatives (see the "Related Work" section). This is done using a mechanism which can be seen as a generalized version of polymorphic inline caches. Currently, the PyPy JIT works only in conjunction with the C backend. Early results are very good. The resulting Python interpreter can run numerically 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 a work in progress and very incomplete, but it shows that 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 ------------------ The 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`. Supporting and thus speeding up more parts of the Python language is a separate task and since it requires changes to the interpreter, it is out of the scope of this proposal. It is important to underline that this work is independent from the backend being used, so once the PyPy interpreter is fully optimized for the JIT, PyPy for the JVM will automatically take advantage of these improvements without needing to change the JIT backend for the JVM. 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 -------------------------- To have a working JIT for the JVM is an important step towards making PyPy the fastest Python for the JVM. Moreover, due to the innovative ideas implemented by PyPy, it is likely that Python could become the fastest dynamic language of its class 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 environment 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 (Python) program starts, and it doesn't exploit additional informations that would be available only at runtime (most importantly 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 information that is 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`_. The PyPy JIT is different from 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 information, including that which is only available late in the process, 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 with 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. Developers ---------- Antonio Cuni (anto.cuni at gmail.com) 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, he began working on an 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. Carl Friedrich Bolz (cfbolz at gmx.de) also is a core developer of PyPy. He worked on various areas including the garbage collectors, optimizations and the Python interpreter. He is currently doing a Master's thesis at the Heinrich-Heine-Universit?t D?sseldorf about improving PyPy's JIT compiler generator. .. _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 anto.cuni at gmail.com Sat Mar 1 10:32:19 2008 From: anto.cuni at gmail.com (Antonio Cuni) Date: Sat, 01 Mar 2008 19:32:19 +0100 Subject: FINAL PROPOSAL: Porting the PyPy JIT to JVM and MLVM (2nd submission) Message-ID: <47C9A133.9070609@gmail.com> Sorry for the resubmission, I forgot to copy and paste the last paragraph of the proposal by mistake. This proposal substitutes the previous one. (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 or 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 apply partial evaluation techniques to automatically turn the interpreter into a JIT compiler which generates efficient code dynamically. The key idea behind the PyPy JIT is to systematically delay compilation until we know all the information useful for emitting optimized code, thus being potentially much more efficient than all the current other alternatives (see the "Related Work" section). This is done using a mechanism which can be seen as a generalized version of polymorphic inline caches. Currently, the PyPy JIT works only in conjunction with the C backend. Early results are very good. The resulting Python interpreter can run numerically 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 a work in progress and very incomplete, but it shows that 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 ------------------ The 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`. Supporting and thus speeding up more parts of the Python language is a separate task and since it requires changes to the interpreter, it is out of the scope of this proposal. It is important to underline that this work is independent from the backend being used, so once the PyPy interpreter is fully optimized for the JIT, PyPy for the JVM will automatically take advantage of these improvements without needing to change the JIT backend for the JVM. 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 -------------------------- To have a working JIT for the JVM is an important step towards making PyPy the fastest Python for the JVM. Moreover, due to the innovative ideas implemented by PyPy, it is likely that Python could become the fastest dynamic language of its class 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 environment 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 (Python) program starts, and it doesn't exploit additional informations that would be available only at runtime (most importantly 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 information that is 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`_. The PyPy JIT is different from 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 information, including that which is only available late in the process, 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 with 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. Developers ---------- Antonio Cuni (anto.cuni at gmail.com) 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, he began working on an 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. Carl Friedrich Bolz (cfbolz at gmx.de) also is a core developer of PyPy. He worked on various areas including the garbage collectors, optimizations and the Python interpreter. He is currently doing a Master's thesis at the Heinrich-Heine-Universit?t D?sseldorf about improving PyPy's JIT compiler generator. Nicholas Matsakis (nicholas.matsakis at inf.ethz.ch) is also a core developer of PyPy. He was the primary developer of the current JVM backend for PyPy, and has participated in several PyPy sprints on various topics. He is currently doing his PhD at ETH Zurich under the tutelage of Professor Thomas Gross. .. _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 srivastava.robin at gmail.com Sat Mar 1 10:35:57 2008 From: srivastava.robin at gmail.com (Robin Srivastava) Date: Sun, 2 Mar 2008 00:05:57 +0530 Subject: DRAFT PROPOSAL: Developing APIs for Stream Connection between mobile device/application and desktop via bluetooth Message-ID: <007401c87bcb$19d9c9a0$6802a8c0@HOME> 1.0 Propasal's Idea ???????????????????????????? This propasal puts forward the idea of allowing stream connection between a mobile device/applications (J2ME) and desktop applications (J2SE) using Bluetooth Technology. A number of data sharing methodologies are available for communicating between two or more desktop application or between two or more mobile devices/application. This idea, when materialized, will allow the users to send/receive data from mobile device to PCs in the form of streams of data and vice-versa via bluetooth. 2.0 Background & Abstraction of Idea from it ????????????????????????????????????????????????????????????????? With reference to JSR-82, communication support for the following layers have been already provided by the aforementioned JSR :- >> Service Discovery Protocol >> RFCOMM (type 1 device support) >> Logical Link Control and Adaptation Protocol (L2CAP) >> OBEX Support However the implementation provided by JSR - 82 provide the communication facilities from one mobile device to yet another mobile device. On the similar pattern when we talk about two or more PCs - they can communicate among themselves through various methodologies :- >> Socket programming >> RMI Various types of traffic can be considered while communication which implements a number of different protocols, example - TCP/IP, UDP etc. We will be developing an API which would facilitate stream connection between a mobile device/application and a desktop application. A socket would be created at the desktop application side and similarly a connector would open at the side of mobile device/application. A reference of InputStream and OutputStream on both the sides would be then obtained to send and receive data as streams. 3.0 Implementaion ??????????????????????????? For implementing the idea outlined in this proposal we need to work keeping in mind three different aspacts :- >> making and opening a connector at the mobile side >> making and opening a connector at desktop side >> allowing the communication of data between them. It would follow either its own protocol for communication or some existing standard protocol. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/challenge-discuss/attachments/20080302/81fb2c7e/attachment.html From srivastava.robin at gmail.com Sat Mar 1 10:42:37 2008 From: srivastava.robin at gmail.com (Robin Srivastava) Date: Sun, 2 Mar 2008 00:12:37 +0530 Subject: DRAFT PROPOSAL: Developing APIs for Stream Connection between mobile device/application and desktop via bluetooth Message-ID: <007b01c87bcc$084c1d90$6802a8c0@HOME> 1.0 Propasal's Idea ???????????????????????????? This propasal puts forward the idea of allowing stream connection between a mobile device/applications (J2ME) and desktop applications (J2SE) using Bluetooth Technology. A number of data sharing methodologies are available for communicating between two or more desktop application or between two or more mobile devices/application. This idea, when materialized, will allow the users to send/receive data from mobile device to PCs in the form of streams of data and vice-versa via bluetooth. 2.0 Background & Abstraction of Idea from it ????????????????????????????????????????????????????????????????? With reference to JSR-82, communication support for the following layers have been already provided by the aforementioned JSR :- >> Service Discovery Protocol >> RFCOMM (type 1 device support) >> Logical Link Control and Adaptation Protocol (L2CAP) >> OBEX Support However the implementation provided by JSR - 82 provide the communication facilities from one mobile device to yet another mobile device. On the similar pattern when we talk about two or more PCs - they can communicate among themselves through various methodologies :- >> Socket programming >> RMI Various types of traffic can be considered while communication which implements a number of different protocols, example - TCP/IP, UDP etc. We will be developing an API which would facilitate stream connection between a mobile device/application and a desktop application. A socket would be created at the desktop application side and similarly a connector would open at the side of mobile device/application. A reference of InputStream and OutputStream on both the sides would be then obtained to send and receive data as streams. 3.0 Implementaion ??????????????????????????? For implementing the idea outlined in this proposal we need to work keeping in mind three different aspacts :- >> making and opening a connector at the mobile side >> making and opening a connector at desktop side >> allowing the communication of data between them. It would follow either its own protocol for communication or some existing standard protocol. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/challenge-discuss/attachments/20080302/e62dfa98/attachment.html From ted at tedneward.com Sat Mar 1 10:53:38 2008 From: ted at tedneward.com (Ted Neward) Date: Sat, 1 Mar 2008 10:53:38 -0800 Subject: DRAFT PROPOSAL: OpenJDK on Windows Message-ID: <013d01c87bcd$93425850$b9c708f0$@com> FINAL PROPOSAL: OpenJDK on Windows ===================================== Ted Neward ted at tedneward dot com Revamp the OpenJDK build process on Windows I propose to rewrite/port the OpenJDK build processes for the Windows platform to take advantage of the new freely-available compilers and toolchain (Visual C++ 2008 Express) and more Windows-friendly tools (MinGW), so as to enable a more Windows-friendly environment in which OpenJDK developers can more easily participate. This proposal includes the following ideas o adjust the Hotspot build processes to Visual C++ 9.0 o adjust the Hotspot build processes to make use of MSBuild o adjust the overall build environment to use MinGW instead of Cygwin The result of the proposal will be an environment by which developers working on the Windows platform can simply download MinGW and the freely-available Visual C++ Express, run the appropriate batch file to establish an environment in which to build, and type ?make?. The Clear Need ============== Building the JDK on Windows has always been an arcane art. A quick glance at the build-dev mailing list archives reveals the disparity in ease between building the OpenJDK on a *nix-based platform and doing the same on Windows. The fact that Sun?s own expertise is clearly focused on the *nix platform does not help matters; developers trying to build the OpenJDK on Windows end up facing numerous challenges and find close to zero resources "in the field" to help navigate some of the more treacherous paths, despite the fact that the Windows platform, for all its flaws, clearly remains one of the most important development platforms of the day. If the OpenJDK project is going to be open to developers working on the Windows platform, significant steps must be made to ease this process. The transition to the free Microsoft toolchains will also have a huge financial impact on the OpenJDK community--and Sun Microsystems in particular, in that now the Professional versions (which charge a license fee for each seat using it) are required in order to build the OpenJDK sources, at several thousand dollars a head. Porting this over to Visual C++ Express and/or MinGW?s gcc could reduce that cost to zero. Development Guidelines ====================== Development of this project will take place in accordance with the openjdk development guidelines, on a branch of the official Mercurial repositories. No structural source changes are anticipated, however major changes to the build processes (makefiles and shell scripts) are obviously a key part of the project. Dependence on Sun and other resources ===================================== Development of this project should not require significant amounts of Sun resources: some level of coordination with the build team, most notably Kelly O?Hair and possibly any other Sun developers involved with the Windows build process, will obviously be required, and some degree of coordination with the development teams writing platform- specific parts of the OpenJDK sources (AWT, JavaSound, etc) may be required in order to ensure a smooth transition when compiling native code, but this is not anticipated to be large--ideally, a simple request to test the candidate build structure periodically and report errors. Project Plan and Milestones =========================== It is difficult to provide milestones and a concrete plan at this time, as much of this project is research-based: does the Visual C++ Express product have all the necessary library and include file support to build the OpenJDK, does the MinGW toolchain provide the necessary tools to build the OpenJDK, and so on. It is believed that the project would not exceed several months of work, however this is merely a guess at this point in time. Some of the project goals are also potentially unclear: for example, Microsoft?s clear ?path forward? with respect to build tools is to use MSBuild instead of Makefiles, however, MinGW could continue to use GNU make (or something similar) if the supporters of this proposal felt that a change to MSBuild would create a "competency gap" that the OpenJDK community would have a hard time closing. These recommendations could heighten or reduce project work accordingly. Copyright ========= This proposal, in its entirety, is hereby contributed under the terms of the Sun Contributor Agreement. Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing HYPERLINK "http://www.tedneward.com"http://www.tedneward.com No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.21.2/1305 - Release Date: 2/29/2008 6:32 PM -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/challenge-discuss/attachments/20080301/1f8784cb/attachment.html From shubhanshu.pathak at gmail.com Sat Mar 1 11:18:07 2008 From: shubhanshu.pathak at gmail.com (shubhanshu pathak) Date: Sun, 2 Mar 2008 00:48:07 +0530 Subject: DRAFT PROPOSAL: Robotics package in JDK Message-ID: *Robotic package in JDK* * * *Need for this API:* As robots are becoming increasingly popular, research at a very large scale is going on in the field of robotics. New robots are being developed everyday serving daily human work to scientific applications in laboratory. This increases the need to develop software for robots. In this context Microsoft had developed Microsoft robotic studio which provide environment to develop softwares which are written in visual studio languages. Also they had provided the tool which can burn these programs onto the robots memory. *Innovation:* Idea is to firstly develop a complete package which can provide a framework to develop robotic application in java. Secondly adding a Robotic Emulator in Net Beans to provide platform to test and run these applications virtually, and generate the assembly code. Then this code can be actually burnt on to the memory of the robot and made to run the robot physically. The package will provide a generic model for a robot with generic classes and interfaces. Like MidLets are the bases to develop mobile application. Similarly few classes will be provided to develop a model of robot. *Work Flow:* As we know that basis of the working of the robots is the micro-controller so in our first step we will provide all the possible configurations of the same and the possible customization for it. Since the hardware limitations are there so we will be providing output in terms of the best possible interface. Now once the robot engineer gets the prior look of the actual functioning of his/her robot he/she can go for the emulation device of the net-beans. Since the robots learn from the environment while performing there task so sense ability of them can also be embedded by having a parallel thread of the possible hurdles which let it to judge the best possible activity. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/challenge-discuss/attachments/20080302/a8c9f790/attachment.html From Edgar.Galvis at fsw.com Sat Mar 1 12:34:12 2008 From: Edgar.Galvis at fsw.com (Edgar Galvis) Date: Sat, 1 Mar 2008 15:34:12 -0500 Subject: FINAL PROPOSAL: Pattern Oriented Framework for the rapid implementation of Java/JDK applications Message-ID: <004c01c87bdb$9cb5bef0$6ec1124c@marinaouz26nla> FINAL PROPOSAL Pattern Oriented Framework for the rapid implementation of Java applications Edgar Galvis 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 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 Gang Of Four design patterns (GoF) 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 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/API. 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, Data Access Object implementations (DAO), Model View Controller implementations (MVC), EJBs, AJAX, JMS, XML and Web Services. E) The framework should be designed to be lightweight and fast (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. 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 application modules 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 as independent units by sending messages to the component and verifying the expected reply messages. H) In order to provide additional productivity, the framework should be integrated with open source IDEs. 3. Previous work ---------------- Many of the goals above 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 Java Specification Request (JSR) is being submitted. The project JSR and the progress achieved so far have been documented via the project web site: http://jt.dev.java.net/ Early versions of the pattern oriented framework have been successfully utilized in several mission critical applications. Reuse, implementation costs and quality have been improved significantly as a result. 4. Benefits to the community ---------------------------- The main goal of the pattern oriented framework is the rapid implementation of applications based on the Java architecture/JDK. There are many benefits associated with using design pattern technologies in terms of speed of development, quality and cost reduction. This type of integrated framework based on design patterns and a Lego/messaging architecture is able to accelerate development efforts while reducing cost significantly. The framework architecture provides strong encapsulation and loose coupling. Framework components can be easily plugged into complex framework applications. The framework also improves the implementation process of applications based on design patterns. The framework implements and/or facilitates the implementation of well-known design patterns like GoF design patterns and J2EE Design patterns. The user is able to reuse these implemented components out of the box. This brings improvements in terms of quality and cost reductions. The messaging architecture is able to provide transparent access to remote components. Design patterns implemented by the framework (adapters, remote proxies and facades) make it possible by hiding the complexities associated with remote APIs. The framework improves design and development efforts. There is a tight correspondence between several UML diagrams and the framework messaging architecture. Framework components can be easily added to BPM process diagrams. Testing and debugging efforts are also improved by the messaging architecture. It is envisioned that the framework will provide wizards and capabilities for automated generation of application modules. Notice that many UML diagrams are based on a messaging model. Therefore it is only natural that its implementation be based on a messaging architecture. This isn't usually the case. The framework is very lightweight and fast (low overhead). It is also suitable for all Java platforms, not only the Java Standard and Enterprise Editions. Although there are some capabilities based on design patterns and some commercial pattern oriented frameworks; there is currently no integrated open source framework to meet the goals and needs listed above. 5. Deliverables --------------- The projects deliverables are as follows: 1) Complete source code for the reference implementation of the framework (feature complete). 2) Complete Agile documentation. This includes design documentation, user manuals, installation notes, API documentation (javadoc), etc. 3) Source code for sample framework applications and framework scripts for automated and regression testing. 4) Updated project web site. Standard software practices are being followed for the implementation of this project. The project will be delivered using the Agile methodology in accordance with the established community governance rules and procedures. Four iterations are envisioned. Each iteration should produce a complete revision of the reference implementation. A QA/testing phase will be part of each iteration. Each iteration will also involve planning, requirements and design activities. 6. Sun Involvement/Participation -------------------------------- No Sun involvement/participation is required. 7. Team Membership ------------------- This project has support from both private entities and the open source community. Some of the project members are listed at http://jt.dev.java.net/ New sponsors and teams members are welcome. Edgar Galvis has had several roles over a period of many years in the computer industry. Roles include Computer Science Professor, Computer Scientist at research facilities and roles as a technical consultant and architect for several major corporations. His work with Java and the Java Architecture spans over 10 years. 8. Sun Microsystems Contributor Agreement & Copyrights ------------------------------------------------------ This proposal is contributed under the terms of the Sun Microsystems Contributor agreement. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/challenge-discuss/attachments/20080301/a36bfdb3/attachment.html From scolebourne at joda.org Sat Mar 1 13:21:55 2008 From: scolebourne at joda.org (Stephen Colebourne) Date: Sat, 01 Mar 2008 21:21:55 +0000 Subject: FINAL PROPOSAL: Provide date and time library from JSR-310 Message-ID: <47C9C8F3.5030409@joda.org> FINAL PROPOSAL Provision of the JSR-310, Date and Time API, Reference Implementation suitable for inclusion in OpenJDK. Stephen Colebourne (team lead) & Michael Nascimento Santos scolebourne(at)joda.org misterm(at)gmail.com 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. The formatting and parsing code is also not thread-safe. Developers using the JDK have a 'clear need' for a better date and time API. To tackle the issue, JSR-310 [1] was launched to provide a new Date and Time API. The target for the JSR is inclusion in Java 7, which naturally means inclusion in Open JDK. All work of the JSR is performed in public forums. JSR-310 is an original development. It is inspired by previous work, notably Joda-Time [2], however the final result will be a completely new API, capable of being descibed as an 'original work'. Code is not being ported or reused from Joda-Time. This project is a team submission. Stephen Colebourne is the lead for the rules of the Open JDK Challenge. 2. Goals and deliverables ------------------------- The goal of this project is to provide a complete working Reference Implementation (RI) of JSR-310 as agreed by the JSR-310 working group. 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. As a rough estimate, the current codebase contains about 50% of the likely eventual classes. Of the existing classes, about 50% are code complete, whilst the other 50% are stubs or incomplete. Tests exist for about 10% of the existing codebase. The Reference Implementation is BSD licensed. It is not proposed to change that as it is compatible with the GPL license. If this proposal is selected, and proceeds to completion, the entire RI codebase will be made available under the SCA (both the parts already coded, and the additions made since). 4. Milestones ------------- Development milestones shall ultimately be determined by the JSR-310 working group. However the outline plan is: 1) Complete the development of the RI using stub methods 2) Integration with the existing Java classes, such as Date and Calendar 3) Provision of tests and appropriate bug fixes 5. 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. The JSR-310 specification document does not form part of the deliverables of this proposal. 6. Dependencies on Sun ---------------------- There are no known dependencies on Sun over and above those Sun has already agreed to by joining the JSR-310 working group. 7. Developers ------------- 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 [2], 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. Michael Nascimento Santos has worked with Java for more than 8 years, from J2ME to J2EE. He has contributed to 5 other JSRs besides JSR-310 and is a leading figure in Brazialian open source and leads the Genesis framework project [4]. He works for Summa Technologies do Brasil Ltda. [1] http://jsr-310.dev.java.net [2] http://joda-time.sourceforge.net [3] http://kijaro.dev.java.net [4] http://genesis.dev.java.net/ From cadenza at paradise.net.nz Sat Mar 1 14:41:17 2008 From: cadenza at paradise.net.nz (Bruce Chapman & Barbara Carey) Date: Sun, 02 Mar 2008 11:41:17 +1300 Subject: DRAFT PROPOSAL - Pot Pourri - Augmented Stack Traces, ServiceProvider annotation and processor, Enhanced For Loop utility class Message-ID: <47C9DB8D.2040303@paradise.net.nz> DRAFT PROPOSAL pot Pourri #1 Bruce Colin Chapman cadenza at paradise.net.nz I propose three independant additions to the JDK APIs. o Augmented Stack traces o ServiceProvider Annotation and Processor o Enhanced For loop Utility Class Augmented Stack Trace ===================== Exceptions allows contextual information to be added at the point they are thrown (actually the point they are created but its generally the same location) via Throwable's message mechanism. Additional context may be added further up the stack if the exception is caught and wrapped in another exception containing the origibal as a cause and a new message with the aditional context information. Contextual information is useful and often critical to resolving faults. I propose a mechanism to add contextual information (a short String) to an Exception's stack trace at the StackTraceElement corresponding to where the mechanism is invoked from. This will be particularly useful when traversing composite pattern data structures as each Node can catch any exceptions, augment them with its identity in some form, and rethrow the exception. Also in Java Server Faces, exceptions thrown from managed beans invoked from EL expressions in a page can be hard to track down because neither the component containing the EL expression or the expression text itself is shown in the stack trace. This mechanism provides a relatively easy way for key contextual information to be added to an exception's stacktrace the exception passes through a method. StackTraceElement will be extended so that a StackTraceElement will have a private String field to contain the augmented context. This will default to null. Throwable.printStackTrace() will be modified to print the augmented context String field (but only the first (say) 60 characters if it is longer) when it is a available. The context information will be printed on a line below the ret of the StackTraceElement. StackTraceElement will have a static method which will take a Throwable, and a String. The string will be added to the Throwable's StackTraceElement which corresponds to the caller of the static method. Assistance From Sun ------------------- Obtaining the current stack trace depth can be done by getting a current stack trace and looking at its length. However experiments show this to be ineffient from a performance persepctive. Although the proposal can be implemented with existing JVM code, a method similar to Throwable.fillinStackTrace() which merely returned the length that the stack trace would if it were to be filled in would improve performance. Such a method is not part of this proposal but would aid performance of it. Service Provider Annotation and Processor ========================================= Java 6 introduced java.util.ServiceLoader class to perform service loading as previously specified in the jar spec (IIRC) but whose implementation was in a sun.* package. One of the difficulties of using this mechanism is correctly generating the /META-INF/services/ file. Although not difficult there is no verification that the file is correctly placed and named. Errors in the file's path cause the feature to appear to silently fail. Managing the content of the file can be tedious. I propose a new Annotation with a corresponding AnnotationProcessor which will create and maintain the META-INF/services files for any classes that declare themselves as being service providers. There are two approaches to be investigated. Approach 1. The annotation will have a single value member to specify the class of the Service, it is for this service that the file will be managed. Approach 2. The Service provider annotation will be a marker annotation. Another marker annotation will be used to identify abstract classes and interfaces which are services (designed to have providers loaded by ServiceLoader). In this approach a service provider's corresponding service will be discovered by looking for a supertype annotated as a service. The Annotation processor will manage the META-INF/services/* files. It will behave correctly in the face of incremental compiles. Specifically Given two classes A and B each annotated as service providers of C then o IF A and B are compiled together META-INF/services/C will contain A and B. o After a clean, if only A is compiled, META-INF/services/C will contain A o IF B is then compiled, META-INF/services/C will contain both A and B o If the annotation is removed from A, and A is recompiled, META-INF/services/C will contain B. IF A and B are compiled together META-INF/services/C will contain A and B. Assistance from Sun -------------------- None. Enhanced For loop Utility Class =============================== I propose a new utility class in java.util with static methods for creating Iterables from various types that are not Iterables so that they may be looped over using JDK5's enhanced for loop. The class will be called "In". It will contain (at least) the following methods to loop over an Enumeration static Iterable each(Enumeration enumeration) To loop (with a single loop) over a number of separate Iterables in sequence static Iterable sequence(Iterable... subsequences) to Loop (with a single loop) over two Iterables at the same time static Iterable> tandem(Iterable left, Iterable right) (This would also involve creating java.util.Pair to model a 2 tuple) I propose to look for other cases where such a helper method would be valuable, and implement those. Some ideas are SQL RowSets, parts of DOM with indexed access and possibly looping over the lines in a BufferedReader. Inter package dependencies need to be managed correctly for these, and also it needs to be done in such a way as to manage checked exceptions that may be thrown in the process of implementing next(). The Iterables returned may possibly also be the implementations of Iterator (for lightweightness) in which the Iterables will only be able to have their iterator() method called once, otherwise an IllegalStateException will be thrown. When used only in enhanced for loops this restriction will have no effect. For further investigation. From anders.bjorklund at sajtopia.se Sat Mar 1 17:11:41 2008 From: anders.bjorklund at sajtopia.se (=?ISO-8859-1?Q?Anders_Bj=F6rklund?=) Date: Sun, 02 Mar 2008 02:11:41 +0100 Subject: FINAL PROPOSAL: Meta-compiler for non-java code to run on the java virtual machine Message-ID: <47C9FECD.5020705@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/ From cadenza at paradise.net.nz Sat Mar 1 20:36:19 2008 From: cadenza at paradise.net.nz (Bruce Chapman & Barbara Carey) Date: Sun, 02 Mar 2008 17:36:19 +1300 Subject: DRAFT PROPOSAL Pot Pourri - Augmented Stack Traces, ServiceProvider annotation and processor, Enhanced For Loop utility class Message-ID: <47CA2EC3.3030602@paradise.net.nz> DRAFT PROPOSAL Pot Pourri - Augmented Stack Traces, ServiceProvider annotation and processor, Enhanced For Loop utility class Bruce Colin Chapman cadenza at paradise.net.nz I propose three independant additions to the JDK APIs. o Augmented Stack traces o ServiceProvider Annotation and Processor o Enhanced For loop Utility Class Augmented Stack Trace ===================== Exceptions allow contextual information to be added at the point they are thrown (actually the point they are created but its generally the same location) via Throwable's message mechanism. Additional context may be added further up the stack if the exception is caught and wrapped in another exception containing the original as a cause and a new message with the additional context information. Contextual information is useful and often critical to resolving faults. I propose a mechanism to add contextual information (a short String) to an Exception's stack trace at the StackTraceElement corresponding to where the mechanism is invoked from. This will be particularly useful when traversing composite pattern data structures as each Node can catch any exceptions, augment them with its identity in some form, and rethrow the exception. Any stack trace will then include the path to the node that was being processed when the exception was thrown. Also in Java Server Faces, exceptions thrown from managed beans invoked from EL expressions in a page can be hard to track down because neither the component containing the EL expression or the expression text itself is shown in the stack trace. Using the proposed mechanism, both the ID of the component being processed, and the EL expression itself could be included in any stack traces for exceptions thrown while processing the EL expression. This mechanism provides a relatively easy way for key contextual information to be added to an exception's stacktrace as the exception passes through a method. As an example usage String expr = ...; // an expression that will be interpreted try { eval(expr); } catch (KnownException k1) { StackTraceElement.augment(k1,expr); throw k1; } catch (RuntimeException re) { StackTraceElement.augment(re,expr); throw re; } StackTraceElement will be extended so that a StackTraceElement will have a private String field to contain the augmented context. This will default to null. Throwable.printStackTrace() will be modified to print the augmented context String field (but only the first (say) 60 characters if it is longer) when it is a available. The context information will be printed on a line below the rest of the StackTraceElement. StackTraceElement will have a static method which will take a Throwable, and a String. The string will be added to the Throwable's StackTraceElement which corresponds to the caller of the static method. Assistance From Sun ------------------- None required. Obtaining the current stack trace depth can be done by getting a current stack trace and looking at its length. However experiments show this to be inefficient from a performance perspective. Although the proposal can be implemented with existing JVM code, a method similar to Throwable.fillinStackTrace() which merely returns the length that the stack trace would be if it were to be filled in would improve performance. Such a method is not part of this proposal but would aid performance of it. A Complete Implementation ------------------------- A Complete implementation includes working implementation which can be invoked in a way similar to the example above and which when an exception is processed, its stackTrace will print with the augmented data visually associated to the correct StackTraceElement. A complete implementation will include tests for normal use cases, and corner cases that become apparent during development. A complete implementation will include javadocs of at least a comparable standard to the JDK javadocs. Service Provider Annotation and Processor ========================================= Java 6 introduced java.util.ServiceLoader class to perform service loading as previously specified in the jar spec (IIRC) but whose implementation was in a sun.* package. One of the difficulties of using this mechanism is correctly generating the /META-INF/services/ file. Although not difficult there is no verification that the file is correctly placed and named. Errors in the file's path cause the feature to appear to silently fail because the required file doesn't exist the Service Provider is not found. Managing the content of the file is not difficult but can be tedious. I propose a new Annotation with a corresponding AnnotationProcessor which will create and maintain the META-INF/services files for any classes that declare themselves as being service providers. There are two approaches to be investigated. One will be implemented. Approach 1. The annotation will have a single value member to specify the class of the Service, it is for this service that the file will be managed. Approach 2. The Service provider annotation will be a marker annotation. Another marker annotation will be used to identify abstract classes and interfaces which are services (designed to have providers loaded by ServiceLoader). In this approach a service provider's corresponding service will be discovered by looking for a supertype annotated as a service. This approach would involve identify all existing Services and annotating them. A hybrid approach is also possible, prefer 2 but 1 can be used when the Service is not annotated. The Annotation processor will manage the META-INF/services/* files. It will behave correctly in the face of incremental compiles. Specifically Given two classes A and B each annotated as service providers of C then o IF A and B are compiled together META-INF/services/C will contain A and B. o After a clean, if only A is compiled, META-INF/services/C will contain A o IF B is then compiled, META-INF/services/C will contain both A and B o If the annotation is then removed from A, and A is recompiled, META-INF/services/C will contain B (A will be removed from META-INF/services/C). Assistance from Sun -------------------- None. A Complete Implementation ------------------------- A Complete implementation includes a working implementation. A complete implementation will include tests for normal use cases, and corner cases that become apparent during development. A complete implementation will include javadocs of at least a comparable standard to the JDK javadocs. Enhanced For loop Utility Class =============================== I propose a new utility class in java.util with static methods for creating Iterables from various types that are not Iterables so that they may be looped over using JDK5's enhanced for loop. The class will be called "In". It will contain (at least) the following methods to loop over an Enumeration static Iterable each(Enumeration enumeration) To loop (with a single loop) over a number of separate Iterables in sequence static Iterable sequence(Iterable... subsequences) to Loop (with a single loop) over two Iterables at the same time static Iterable> tandem(Iterable left, Iterable right) (This would also involve creating java.util.Pair to model a 2 tuple) I propose to look for other cases where such a helper method would be valuable, and implement those. Some ideas are SQL RowSets, parts of DOM with indexed access and possibly looping over the lines in a BufferedReader. Inter package dependencies need to be managed correctly for these so may not be desirable. Also they needs to be done in such a way as to avoid checked exceptions that may be thrown in the process of implementing next(). The Iterables returned may possibly also be the implementations of Iterator (for lightweightness) in which case the Iterables will only be able to have their iterator() method called once, otherwise an IllegalStateException will be thrown. When used only in enhanced for loops this restriction will have no effect. This is for further investigation. Assistance from Sun -------------------- None. A Complete Implementation ------------------------- A Complete implementation includes a working implementation of java.util.Pair and java.util.In with at least the functionality of the three static methods described above. A complete implementation will include tests for normal use cases, and corner cases that become apparent during development. A complete implementation will include javadocs of at least a comparable standard to the JDK javadocs. Original Work ============= Relevance To Community ====================== Each of these API additions adds to ease of development. Augmented Stack Trace provides a means for API developers to provide additional information for diagnosing the cause of unexpected exceptions where appropriate. This assists users of those APIs. The leveraged benefit when a commonly used framework adds this information can be enormous. ServiceProvider Annotation and Processor automates the process of creating and managing META-INF /services files and as a by product the annotations provide autmatic documentation of Service Providers. Enhanced For loop Utility Class extends the applicability of the enhanced for loop to a large number of cases where currently it cannot be used. While ServiceProvider Annotation and Processor has a somewhat specialist audience, the other two will provide benefits to almost any java developer. Project Management ================== The project will be run as one (or maybe three) projects within the OpenJDK Core Libraries Group. An open repository will be used for source management, and a mailing list will be used to keep interested parties up to date, and to inform design decisions. Project Plan ============ 18 March 2008: Inception 8 Apr: Project setup complete. openJDK orientation complete. 22 Apr: Design and Strawman and API Docs Draft completed for review (all 3 parts) 6 May: Design and API docs review complete 20 May: Design and API Docs Completed 4 July: Test Suite and Implementation complete Project complete 4 Aug: Project stage complete Sole Work ========= The idea for java.util.In.each(Enumeration) has been published under a different class name in the Java Specialist newsletter. The rest of this proposal is my sole work. Developer's Experience ====================== The developer is Bruce Chapman. Bruce served on the JSR 269 (Annotation Processing) expert group. Bruce has around 10 years experience developing with Java. Copyright ========= This proposal is hereby contributed under the terms of the Sun Contributor Agreement. The implementation will be contributed under the terms of the Sun Contributor Agreement. From srivastava.robin at gmail.com Sat Mar 1 06:05:36 2008 From: srivastava.robin at gmail.com (Robin Srivastava) Date: Sat, 1 Mar 2008 19:35:36 +0530 Subject: DRAFT Proposal: Bluetooth API for establishing stream connection between a mobile device/application and PC Message-ID: <961acd030803010605x7f442891ya578d43b9f68fa4c@mail.gmail.com> 1.0 Propasal's Idea ???????????????????????????? This propasal puts forward the idea of allowing stream connection between a mobile device/applications (J2ME) and desktop applications (J2SE) using Bluetooth Technology. A number of data sharing methodologies are available for communicating between two or more desktop application or between two or more mobile devices/application. This idea, when materialized, will allow the users to send/receive data from mobile device to PCs in the form of streams of data and vice-versa via bluetooth. 2.0 Background & Abstraction of Idea from it ????????????????????????????????????????????????????????????????? With reference to JSR-82, communication support for the following layers have been already provided by the aforementioned JSR :- >> Service Discovery Protocol >> RFCOMM (type 1 device support) >> Logical Link Control and Adaptation Protocol (L2CAP) >> OBEX Support However the implementation provided by JSR - 82 provide the communication facilities from one mobile device to yet another mobile device. On the similar pattern when we talk about two or more PCs - they can communicate among themselves through various methodologies :- >> Socket programming >> RMI Various types of traffic can be considered while communication which implements a number of different protocols, example - TCP/IP, UDP etc. We will be developing an API which would facilitate stream connection between a mobile device/application and a desktop application. A socket would be created at the desktop application side and similarly a connector would open at the side of mobile device/application. A reference of InputStream and OutputStream on both the sides would be then obtained to send and receive data as streams. 3.0 Implementaion ??????????????????????????? For implementing the idea outlined in this proposal we need to work keeping in mind three different aspacts :- >> making and opening a connector at the mobile side >> making and opening a connector at desktop side >> allowing the communication of data between them. It would follow either its own protocol for communication or some existing standard protocol. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/challenge-discuss/attachments/20080301/622dd42e/attachment.html From remaker at devtaste.com Sat Mar 1 12:10:02 2008 From: remaker at devtaste.com (Haitao Sun) Date: Sun, 2 Mar 2008 04:10:02 +0800 Subject: DRAFT PROPOSAL: Implementing Modified CICE and Block-Attached Calling Message-ID: DRAFT PROPOSAL Implementing Modified CICE and Block-Attached Calling SUN Haitao I propose implementing a Java compiler with the following features: * A new form of instance creating expression base on CICE[2] (with some modification). * A general control abstraction mechanism called "Block-Attached Calling" (like "blocks"[1] in Ruby). * An annotation to indicate the "major" method of concrete classes. (So they can be treat like single-abstract-method types) 1. Design Goals =============== The major goal of this proposal is to try to add an expressive control abstraction mechanism to Java in an easy-to-grasp way. The minor goal of this proposal is to try to find out an attractive solution for those who don't want closures in Java 7. A mechanism which is not expressive enough often is bundled with the following problems: 1) It can't express some useful abstractions. That takes programs both hard to write and hard to read. 2) It's not cool enough. Then no one want trying it in early stage. Without hundreds of thousands explorers, it's pretty hard to know the feature's potentials, limitations, and proper usage. 3) Similar mechanism will be introduced again and again to express more. That hurts orthogonality and brings complexity. A mechanism which is not easy-to-grasp enough often have the following short-comings: 1) It's hard to learn. It's certainly that developers smart enough can handle this, but focusing their wisdom on real problems will create a much better world. 2) It's hard to implement and optimize. The absence of optimized implementation will prolong adoption cycle, and being adopted fast is a key to success in market. 2. Introductions ================ All three features proposed are inspired by original CICE proposal. 1.1 The modified CICE I propose the following modification to CICE: 1) For concrete classes, the name of method to be override can be used to solve ambiguity. 2) When using as arguments, the type part is optional. 1.2 the BAC mechanism I propose a mechanism called Block-Attached Calling. It works like Ruby blocks. So we can test whether mechanisms to define control constructs are worth adding. The main idea of BAC is that if the last argument is an CICE, its body can be placed after the right parenthesis of the method calling. If there is a formal parameter list, quotes it with "|" and use it as the last argument. If we adopt this proposal, we can write the following code slices: // Loop Abstraction // ``repeat`` is an user-defined method repeat(3, |int i|) { //do something } // Resource Management // ``with`` is an user-defined method with(resource) { //do something } There is no public draft specification of BAC yet. 1.3 The "major" Annotation I propose an annotation called "major" to indicate the "major" method of concrete classes. Concrete classes with one method annotated as "major" can be treat like single-abstract-method types. The "major" method be treat as the single abstract method. 3. Deliverables =============== The planned deliverables are: 1) The specification of the Block-Attached Calling mechanism and the modified CICE. 2) The source code of the prototype compiler and related test suite. 3) The implementation and javadoc of the "major" annotation. 4. Existing Works ================= The compiler will based on an SVN version of the compiler in OpenJDK. Some ideas may be inspired by BGGA[3] proposal and FCM[4] proposal. 5. Dependencies on Sun ====================== There are no known dependencies on Sun with following exceptions: * The compiler is based on the compiler in OpenJDK. * "SUN" happens to be my surname. 6. Related Works ================ [1] Programming Ruby http://ruby-doc.org/docs/ProgrammingRuby/html/tut_containers.html [2] Concise Instance Creation Expressions: Closures without Complexity http://docs.google.com/View?docid=k73_1ggr36h [3] Closures for the Java Programming Language http://javac.info/ [4] First-Class Methods http://docs.google.com/View?docid=ddhp95vd_0f7mcns From Richard.Sands at Sun.COM Sat Mar 1 20:43:47 2008 From: Richard.Sands at Sun.COM (Rich Sands) Date: Sat, 01 Mar 2008 23:43:47 -0500 Subject: Reminder: final proposals must have "FINAL PROPOSAL" in the subject line Message-ID: <47CA3083.90507@sun.com> ... or it gets very hard to know what is a final proposal and what is not! So please be sure to send your final proposal with that label in the subject so there is no confusion, and so that you are sure your entry will be considered. Keep the great ideas coming, everyone! Thanks, -- 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 mr at sun.com Sat Mar 1 20:48:12 2008 From: mr at sun.com (Mark Reinhold) Date: Sat, 01 Mar 2008 20:48:12 -0800 Subject: Reminder: final proposals must have "FINAL PROPOSAL" in the subject line In-Reply-To: richard.sands@sun.com; Sat, 01 Mar 2008 23:43:47 EST; <47CA3083.90507@sun.com> Message-ID: <20080302044812.84EF57B68@callebaut.niobe.net> > Date: Sat, 01 Mar 2008 23:43:47 -0500 > From: richard.sands at sun.com > ... or it gets very hard to know what is a final proposal and what is not! So please > be sure to send your final proposal with that label in the subject so there is no > confusion, and so that you are sure your entry will be considered. Note also that if you're not a subscriber to the challenge-discuss list then your message will be held for moderation, since we don't allow posts by non-subscribers. Please subscribe to challenge-discuss before sending your proposal. > Keep the great ideas coming, everyone! Yes! - Mark From neal at gafter.com Sat Mar 1 21:00:45 2008 From: neal at gafter.com (Neal Gafter) Date: Sat, 1 Mar 2008 21:00:45 -0800 Subject: DRAFT PROPOSAL: Implementing Modified CICE and Block-Attached Calling In-Reply-To: References: Message-ID: <15e8b9d20803012100n890c536h1fa01af54cbaa811@mail.gmail.com> Using an annotation as proposed to change the semantics of the core (non-annotation) language elements is in direct contradiction to the design principles of the annotation language feature. For "when used as arguments, the type part is optional", it is unclear how this is intended to work with overloading. How can the block be semantically analyzed if you don't know what the parent class is, and therefore you don't know what names are inherited? Isn't that semantic analysis necessary to find the applicable overloadings? For the invocation syntax "shorthand", it is unclear what the scoping is within the "block". For example, what does a return statement return from? What does "this" mean? Generally speaking, I think any proposal to implement a language extension should have a more precise specification of the language change before being submitted as an implementation project. Regards, Neal On Sat, Mar 1, 2008 at 12:10 PM, Haitao Sun wrote: > DRAFT PROPOSAL > > Implementing Modified CICE and Block-Attached Calling > > SUN Haitao > > I propose implementing a Java compiler with the following features: > > * A new form of instance creating expression base on CICE[2] (with > some modification). > > * A general control abstraction mechanism called "Block-Attached > Calling" (like "blocks"[1] in Ruby). > > * An annotation to indicate the "major" method of concrete classes. > (So they can be treat like single-abstract-method types) > > 1. Design Goals > =============== > > The major goal of this proposal is to try to add an expressive > control abstraction mechanism to Java in an easy-to-grasp way. > > The minor goal of this proposal is to try to find out an attractive > solution for those who don't want closures in Java 7. > > A mechanism which is not expressive enough often is bundled with the > following problems: > > 1) It can't express some useful abstractions. That takes programs > both hard to write and hard to read. > > 2) It's not cool enough. Then no one want trying it in early stage. > Without hundreds of thousands explorers, it's pretty hard to know > the feature's potentials, limitations, and proper usage. > > 3) Similar mechanism will be introduced again and again to express > more. That hurts orthogonality and brings complexity. > > A mechanism which is not easy-to-grasp enough often have the > following short-comings: > > 1) It's hard to learn. It's certainly that developers smart enough > can handle this, but focusing their wisdom on real problems will > create a much better world. > > 2) It's hard to implement and optimize. The absence of optimized > implementation will prolong adoption cycle, and being adopted fast is > a key to success in market. > > 2. Introductions > ================ > > All three features proposed are inspired by original CICE proposal. > > 1.1 The modified CICE > > I propose the following modification to CICE: > > 1) For concrete classes, the name of method to be override can be used > to solve ambiguity. > > 2) When using as arguments, the type part is optional. > > 1.2 the BAC mechanism > > I propose a mechanism called Block-Attached Calling. It works like > Ruby blocks. So we can test whether mechanisms to define control > constructs are worth adding. > > The main idea of BAC is that if the last argument is an CICE, its body > can be placed after the right parenthesis of the method calling. If > there is a formal parameter list, quotes it with "|" and use it as the > last argument. > > If we adopt this proposal, we can write the following code slices: > > // Loop Abstraction > // ``repeat`` is an user-defined method > repeat(3, |int i|) { > //do something > } > > // Resource Management > // ``with`` is an user-defined method > with(resource) { > //do something > } > > There is no public draft specification of BAC yet. > > 1.3 The "major" Annotation > > I propose an annotation called "major" to indicate the "major" method > of concrete classes. > > Concrete classes with one method annotated as "major" can be treat > like single-abstract-method types. The "major" method be treat as the > single abstract method. > > 3. Deliverables > =============== > > The planned deliverables are: > > 1) The specification of the Block-Attached Calling mechanism and the > modified CICE. > > 2) The source code of the prototype compiler and related test suite. > > 3) The implementation and javadoc of the "major" annotation. > > 4. Existing Works > ================= > > The compiler will based on an SVN version of the compiler in OpenJDK. > > Some ideas may be inspired by BGGA[3] proposal and FCM[4] proposal. > > 5. Dependencies on Sun > ====================== > > There are no known dependencies on Sun with following exceptions: > > * The compiler is based on the compiler in OpenJDK. > > * "SUN" happens to be my surname. > > 6. Related Works > ================ > > [1] Programming Ruby > http://ruby-doc.org/docs/ProgrammingRuby/html/tut_containers.html > [2] Concise Instance Creation Expressions: Closures without Complexity > http://docs.google.com/View?docid=k73_1ggr36h > [3] Closures for the Java Programming Language > http://javac.info/ > [4] First-Class Methods > http://docs.google.com/View?docid=ddhp95vd_0f7mcns > From charles.nutter at sun.com Sat Mar 1 21:17:41 2008 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Sat, 01 Mar 2008 23:17:41 -0600 Subject: DRAFT PROPOSAL Pot Pourri - Augmented Stack Traces, ServiceProvider annotation and processor, Enhanced For Loop utility class In-Reply-To: <47CA2EC3.3030602@paradise.net.nz> References: <47CA2EC3.3030602@paradise.net.nz> Message-ID: <47CA3875.7020607@sun.com> Bruce Chapman & Barbara Carey wrote: > DRAFT PROPOSAL Pot Pourri - Augmented Stack Traces, ServiceProvider > annotation and > > processor, Enhanced For Loop utility class > > Bruce Colin Chapman > cadenza at paradise.net.nz > > I propose three independant additions to the JDK APIs. > > o Augmented Stack traces > o ServiceProvider Annotation and Processor > o Enhanced For loop Utility Class > > Augmented Stack Trace > ===================== > I propose a mechanism to add contextual information (a short String) to > an Exception's > > stack trace at the StackTraceElement corresponding to where the > mechanism is invoked from. > > This will be particularly useful when traversing composite pattern data > structures as each > > Node can catch any exceptions, augment them with its identity in some > form, and rethrow the > > exception. Any stack trace will then include the path to the node that > was being processed > > when the exception was thrown. I wonder if a general mechanism for decorating the stack could be part of this? My understanding of exception handling performance is such that handling the exception is actually the more expensive part; so I would expect that handling and re-handling to augment the exception at various levels would add more overhead. One thing I've often wanted is a way to decorate the stack with additional information *ahead of time* so that when/if an exception is raised that information can automatically be attached. In my case, it's for JRuby, where we have a "virtual" Ruby stack trace alongside the Java stack trace. It's not useful for us to dump out the entire Java stack trace, since it includes information about Java frames unrelated to the user's code. And we can't just filter the Ruby frames, because JRuby is mixed-mode and some of those frames will be interpreted calls (and therefore be identical to one another). A way to attach information to the current frame (Thread.current.augmentFrame(Object)) and register a backtrace handler (Thread.current.attachBacktraceCallback(...)) would provide a way to attach useful arbitrary data to the call frame for many uses. Thoughts? - Charlie From cadenza at paradise.net.nz Sat Mar 1 21:59:33 2008 From: cadenza at paradise.net.nz (Bruce Chapman & Barbara Carey) Date: Sun, 02 Mar 2008 18:59:33 +1300 Subject: FINAL PROPOSAL Pot Pourri - Augmented Stack Traces, ServiceProvider annotation and processor, Enhanced For Loop utility class Message-ID: <47CA4245.9030600@paradise.net.nz> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pot pourri final.txt Url: http://mail.openjdk.java.net/pipermail/challenge-discuss/attachments/20080302/ded11e17/attachment.txt From wmeissner at gmail.com Sat Mar 1 22:06:18 2008 From: wmeissner at gmail.com (Wayne Meissner) Date: Sun, 2 Mar 2008 19:06:18 +1300 Subject: FINAL PROPOSAL - Java Foreign Function Interface Message-ID: <4ccee320803012206k64e65a07v59582d7babac34db@mail.gmail.com> 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 and Community Benefit 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. There are two main focuses of this project - performance, and to provide sufficient functionality upon which higher-level functionality can be built. 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. 4.2 Supported Function Parameter Types The project will support primitive java types (byte, short, int, long, float, double), primitive arrays, and NIO Buffers as function arguments. All other java types can be converted to one of these types before being passed to the native call. 4.3 Native API defined in Java Instead of using an IDL or XML to define the interface, the project will adopt the JNA convention of defining the C API in a Java inteface. e.g. public interface libm { double pow(double x, double y); double log(double x); } libm libm = Native.load("libm", libm.class); double d = libm.pow(2.0, 3.0); 4.4 Expose argument marshalling to code generators One of the performance drawbacks of existing implementations, is that they funnel all calls through a reflection proxy - this erases the type of each parameter, which then has to be inferred again, before the argument can be correctly marshalled. It would be nice to allow the type information to be passed directly to the marshaller, where that type information is already known. e.g. Function f = NativeLibrary.getInstance("m").getFunction("pow"); double result = JNICall.create(f).addDouble(0.1234d).invokeDouble(); This could benefit both static code generators (e.g. a modified version of gluegen), or the JRuby/Jython JIT. 5.0 Milestones 5.1 Basic invocation of C functions with primitive java type parameters 5.2 Basic Array and NIO Buffer support. 5.3 ByReference primitive java type parameters - i.e. the equivalent of passing the address of a variable to a C function. 5.4 Critical (pinned) array and heap Buffer support. Allow programmers to mark array and Buffer arguments to terminal functions (i.e. those that won't call the JVM) to allow the JVM to avoid copying the heap data to/from native memory. 5.5 Out-only and In-only heap buffer/array optimizations. This is an optimization for heap buffers or arrays which cannot be pinned, but only need to copy the data one way - either in to native memory, or out to java memory. 5.6 Support for String, StringBuffer, StringBuilder parameters. 5.7 Closure support - callbacks from native code to java code. 6.0 Dependence on Sun There is no dependence on Sun for this project. 7.0 Developer Wayne Meissner has been a contributor on the JNA[1] project, creating the libffi backend, porting JNA to 64bit and big endian architectures, and implementing some higher-level features such as custom type mapping. He has also created java language bindings[2] for gstreamer using JNA. 8.0 References [1] JNA http://jna.dev.java.net [2] gstreamer-java http://code.google.com/p/gstreamer-java From kalli at midverk.is Sat Mar 1 22:07:40 2008 From: kalli at midverk.is (Karl Helgason) Date: Sun, 2 Mar 2008 06:07:40 +0000 Subject: DRAFT PROPOSAL: Free Software synthesizer implementation for the OpenJDK project Message-ID: <36EC82E93EB0AD40A4301DAD654323868CA2BA97C5@mail.midverk.is> DRAFT PROPOSAL Free Software synthesizer implementation for the OpenJDK project Karl Helgason Summary ======= The current software synthesizer is part of encumbered code which can not be released as open source. It is mostly written in native code which makes supporting and enhancing difficult. Also current software synthesizer only support proprietary soundbank file format. Thus we need a new synthesizer engine which can be released open source and that supports open and widely used soundbank formats. And also we need that the new synthesizer works in similar manner like the current one so we won't break compatibility with older applications. By writing the new synthesizer engine in Java it will be easer to support and make enhancement to engine in the future. This will also mean safer and more portable code. Goals ===== The goals are to create open source software midi syntheizer which can be integrated into the openJDK project. And also to create high quality synthesizer with supports for universal and open soundbank formats like SoundFont (http://www.soundblaster.com/soundfont/) and DLS (Downloadable Sounds, http://www.midi.org). The Audio Engine Project gave these requirements for solution: * Pure-Java implementation. * Uses JavaSound mixers/lines for sound output. * Supports DLS and/or SoundFont soundbank files. And this engine will also support: * General Midi Level 2 * Downloadable Sounds Level 2.2 * Midi Tuning Standard * SoundFont 2.04 These requests for enhancement will also be resolved with this proposal: Bug ID: 4705306 RFE: Adding Microtonal support to Java Sound API Bug ID: 4666912 RFE: Add support for soundbanks contained in SoundFont and DLS files Development =========== Developments takes place at the Audio Synthesis Engine Project: http://openjdk.java.net/projects/audio-engine/ All communications regarding this object are done at the audio-engine-dev mailing list. Access to source code is at: https://gervill.dev.java.net/ Dependencies on Sun =================== The creation on software engine as it self doesn't have any dependencies on Sun to finish it. However the work on integrating it into the OpenJDK 6 and OpenJDK 7 is handled by Sun. But this software engine will also work stand alone without any assistance from Sun. Developer ========= Karl Helgason is the developer for this project and has previously create SoundFont engine for the RasmusDSP project: http://sourceforge.net/projects/rasmusdsp, And also he is a member of the Frinika project http://sourceforge.net/projects/frinika which is a complete music workstation written in Java. From cadenza at paradise.net.nz Sat Mar 1 22:10:18 2008 From: cadenza at paradise.net.nz (Bruce Chapman & Barbara Carey) Date: Sun, 02 Mar 2008 19:10:18 +1300 Subject: FINAL PROPOSAL Pot Pourri - Augmented Stack Traces, ServiceProvider annotation and processor, Enhanced For Loop utility class Message-ID: <47CA44CA.9080004@paradise.net.nz> Woops, forgot to change DRAFT to FINAL in the document. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pot pourri final.txt Url: http://mail.openjdk.java.net/pipermail/challenge-discuss/attachments/20080302/eb426736/attachment.txt From cadenza at paradise.net.nz Sat Mar 1 22:28:47 2008 From: cadenza at paradise.net.nz (Bruce Chapman & Barbara Carey) Date: Sun, 02 Mar 2008 19:28:47 +1300 Subject: DRAFT PROPOSAL Pot Pourri - Augmented Stack Traces, ServiceProvider annotation and processor, Enhanced For Loop utility class In-Reply-To: <47CA3875.7020607@sun.com> References: <47CA2EC3.3030602@paradise.net.nz> <47CA3875.7020607@sun.com> Message-ID: <47CA491F.600@paradise.net.nz> Charles Oliver Nutter wrote: > > I wonder if a general mechanism for decorating the stack could be part > of this? My understanding of exception handling performance is such > that handling the exception is actually the more expensive part; so I > would expect that handling and re-handling to augment the exception at > various levels would add more overhead. One thing I've often wanted is > a way to decorate the stack with additional information *ahead of > time* so that when/if an exception is raised that information can > automatically be attached. In my case, it's for JRuby, where we have a > "virtual" Ruby stack trace alongside the Java stack trace. It's not > useful for us to dump out the entire Java stack trace, since it > includes information about Java frames unrelated to the user's code. > And we can't just filter the Ruby frames, because JRuby is mixed-mode > and some of those frames will be interpreted calls (and therefore be > identical to one another). A way to attach information to the current > frame (Thread.current.augmentFrame(Object)) and register a backtrace > handler (Thread.current.attachBacktraceCallback(...)) would provide a > way to attach useful arbitrary data to the call frame for many uses. > > Thoughts? > > - Charlie > Thanks for the comments. I had initially though of a similar mechanism to that. See http://weblogs.java.net/blog/brucechapman/archive/2007/08/index.html However that requires quite deep changes in the JVM and the JVM spec and probably the language. My proposal can do similar with a little more effort from developers (over-use is probably to be discouraged so some effort is a good thing IMHO), with just a library change (albeit changes to Throwable and StackTraceElement which are pretty core), feasibility of actually doing it trumps performance :) If my proposal made it into a future JDK release (it can't be done as an add on library) and was well accepted but performance was shown to be a problem, then a declarative approach to the augmenting data could be added to the JVM. later (maybe) Performance wise some inital tests showed that avoiding filling in a new (reusable actually) stack trace in order to get the depth at which the augmentation should occur roughly doubled the performance, so that second stack trace chewed up quite a few horsepower. Regards your ruby project, I think you should be able to grab the stack trace for an exception, and replace it with a manufactured stack trace, with manufactured stack trace elements. I have been successful in using this technique to augment stack traces (albeit I was suffixing the context info after the method name with inverted parenthesis around it to make it look like it was another item in the stack trace element.) Bruce From cadenza at paradise.net.nz Sat Mar 1 23:36:37 2008 From: cadenza at paradise.net.nz (Bruce Chapman & Barbara Carey) Date: Sun, 02 Mar 2008 20:36:37 +1300 Subject: FINAL PROPOSAL Pot Pourri - Augmented Stack Traces, ServiceProvider annotation and processor, Enhanced For Loop utility class Message-ID: <47CA5905.7090007@paradise.net.nz> Added More developer details. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pot pourri final.txt Url: http://mail.openjdk.java.net/pipermail/challenge-discuss/attachments/20080302/d3fd91fc/attachment.txt From charles.nutter at sun.com Sat Mar 1 23:42:03 2008 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Sun, 02 Mar 2008 01:42:03 -0600 Subject: DRAFT PROPOSAL Pot Pourri - Augmented Stack Traces, ServiceProvider annotation and processor, Enhanced For Loop utility class In-Reply-To: <47CA491F.600@paradise.net.nz> References: <47CA2EC3.3030602@paradise.net.nz> <47CA3875.7020607@sun.com> <47CA491F.600@paradise.net.nz> Message-ID: <47CA5A4B.2080605@sun.com> Bruce Chapman & Barbara Carey wrote: > Thanks for the comments. > > I had initially though of a similar mechanism to that. See > http://weblogs.java.net/blog/brucechapman/archive/2007/08/index.html > > However that requires quite deep changes in the JVM and the JVM spec and > probably the language. Aim high! :) > Regards your ruby project, I think you should be able to grab the stack > trace for an exception, and replace it with a manufactured stack trace, > with manufactured stack trace elements. I have been successful in using > this technique to augment stack traces (albeit I was suffixing the > context info after the method name with inverted parenthesis around it > to make it look like it was another item in the stack trace element.) I can certainly do this in cases where I can determine the appropriate Ruby stack information, such as by mangling the class and method name I generate to represent the actual Ruby method name. However it's much more difficult for interpreted Ruby frames, which all essentially look identical. I end up having to fall back on the current artificial frame stack because those interpreted frames need backtrace information to go *somewhere* and I can't augment the existing stack trace to include it. - Charlie From cadenza at paradise.net.nz Sat Mar 1 23:47:14 2008 From: cadenza at paradise.net.nz (Bruce Chapman & Barbara Carey) Date: Sun, 02 Mar 2008 20:47:14 +1300 Subject: FINAL PROPOSAL: OpenJDK on Windows Message-ID: <47CA5B82.8040902@paradise.net.nz> In the interests of an open community, and because I think his proposal has some merit, and because he's probably not going to resubmit this in the next 15 minutes, I'm forwarding this email from TED NEWARD with the required subject line corrected. I do so without prejudice to Ted or Myself. -------------- next part -------------- An embedded message was scrubbed... From: Ted Neward Subject: DRAFT PROPOSAL: OpenJDK on Windows Date: Sat, 01 Mar 2008 10:53:38 -0800 Size: 20101 Url: http://mail.openjdk.java.net/pipermail/challenge-discuss/attachments/20080302/f6a928fc/attachment.eml From fabrizio.giudici at tidalwave.it Sun Mar 2 02:48:52 2008 From: fabrizio.giudici at tidalwave.it (Fabrizio Giudici) Date: Sun, 2 Mar 2008 11:48:52 +0100 Subject: DRAFT PROPOSAL: jrawio - ImageIO codecs for "camera raw" formats Message-ID: <6663A651-7868-4A64-B466-BC9FA9B1A0D2@tidalwave.it> DRAFT PROPOSAL Provision of jrawio, a set of ImageI/O codecs for "camera raw" formats, suitable for inclusion in OpenJDK Fabrizio Giudici fabrizio.giudici(at)tidalwave.it 1. Summary ---------- The Java Image I/O API (javax.imageio) is a part of the JDK focused on image input/output. It basically provides a plugin-based set of classes for reading images from and writing to a stream (both raster and metadata operations are supported). In the standard Java runtime a number of plugins for the most common formats are available (e.g. JPEG, PNG, BMP), others are in the optional package JAI-ImageIO (e.g. TIFF), other formats are available in third-parties' plugins. With the advent of professional digital camera bodies, manufacturers such as Nikon, Canon, Minolta Pentax and others have introduced a number of proprietary formats, commonly named "camera raw" formats (NEF, CRW, CR2, MRW, etc...) [1]. In this scenario, also Adobe developed its own format, Adobe Digital Negative (DNG). "Camera raw" formats share the peculiarity of not containing an image ready-to-be- shown, rather a "dump" of the raw data from the digital sensor with a set of annotations about the camera settings at the moment of the shoot. This makes them a sort of "digital negative", as photographers can manipulate ("develop") them in post-production with a much wider gamma of possibilities than JPEG or TIFF would offer; it also makes it easier "non-destructive processing" (the capability of undoing a developing settings without compromising the original bits). While most of these formats are a variant of TIFF, they can't be properly handled by the TIFF ImageI/O plugin, because 1) it can't understand the extensions and 2) ImageI/O plugins expect that the raster data doesn't need any post-processing (other than decompression). Also, many "camera raw" formats use non-standard compression schemata. jrawio [2,3] is an open source implementation of a set of read plugins for supporting these formats. It is currently composed of two parts: a) jrawio itself, the javax.imageio plugin. It only delivers metadata, thumbnails and "raw" bits out of the stream. b) reajent - it's a post-processor that "develops" the raw bits into a viewable picture. This is an optional component, as applications could decide to provide their own implementation of this part (providing special "recipes" for developing "camera raw" formats is typical of this context). jrawio is an original development. At the moment of writing there are no other known ImageI/O-compliant plugins for "camera raw" formats. jrawio only uses original code (with the exception of the required compliance with the ImageI/O API), partially inspired by dcraw.c by Dave Coffin [4] as most of the "camera raw" formats are undocumented (DNG being a notable exception) and dcraw.c is the only available "documentation" for the community. An older dismissed project by the same author, NEFio [9], was just the initial version of jrawio with a different name as it only focused on the NEF format. This project is a single-developer submission. Fabrizio Giudici is in charge for the rules of the Open JDK Challenge. 2. Goals and deliverables ------------------------- The goal of this project is to provide a working ImageI/O plugin that can be used by professional imaging applications. 3. Previous work ---------------- Work on jrawio and reajent has already started [2,3] delivering a 1.0.RC5 which is stable and suitable for experimental use. Since 2007 the focus has been on the design of the new APIs and the setup of a public test sets, and there have been only a few unofficial releases. This project represents the continuation of that development. At the moment, the metadata and raster I/O parts of jrawio support the following formats: CR2, CRW, DNG, MRW, NEF, PEF, SRF, but only for a subset of the existing camera models (each camera model is likely to use a variant of the main format). It is estimated that the current codebase contains about 80% of the needed classes for those formats, that should be complete at 80%. Support for other formats (such as Kodak DCR) should be added, but it's difficult to estimate the effort for them prior knowing their structure. Unit tests exist for about 10% of the codebase, while there are integration tests over a set of around 1,000 image files verifying that jrawio correctly reads rasters, thumbnails and metadata. A problem exist about the test set since it's mainly composed of images available on the Web, but most of them cannot be redistributed. The "Imaging Test Set Repository" initiative [5] should give a solution to this problem. The above estimates does not include the reajent component, as it does not form part of this proposal. The jrawio and reajent implementations are licensed under the Apache Software License 2.0. We are open to change it as needed for compliance with the OpenJDK license. If this proposal is selected, and proceeds to completion, the entir codebase will be made available under the SCA (both the parts already coded, and the additions made since). 4. Milestones ------------- Development milestones shall ultimately be determined by the working group. However the outline plan is: 1) Provide test and appropriate bug fixes to verify the full compliance with the javax.imageio APIs 2) Add support for all the camera models using the currently supported formats 3) Provide a small extension mechanism (based on META-INF/services) so support for new camera models, including a variant of the file format, can be just dropped in, eventually at application level, as a classpath extension. This will be needed since new camera models using "camera raw" formats are released much more frequently than JDK updates. 4) Add support for new "camera raw" formats 5. Deliverables --------------- The deliverables are: 1) The source code of jrawio (both the jrawio component itself and the reajent component) 2) Tests with 90%+ coverage. 3) Source code documentation in the form of javadoc suitable for inclusion in the JDK. Any API extension for dropping in reajent replacement does not form part of the deliverables of this proposal (we wish to point out that it is our intention to make reajent part of the OpenJDK too, but it won't be possible to complete it by the end of the OpenJDK Innovation Grant programme). 6. Dependencies on Sun ---------------------- There are no known dependencies on Sun - the project just supports javax.imageio and will be kept up to date with the evolution of those APIs. 7. Developers ------------- Fabrizio Giudici has worked with Java since 1996, from J2ME to J2EE. Has has developed in Open Source since 2003. He is a Member of the NetBeans Dream Team and developer of blueMarine [6] and Mistral [7]. He currently works for his own company, Tidalwave s.a.s., as a Senior Architect, Mentor and Technical Instructor. [1] http://en.wikipedia.org/wiki/Raw_image_format [2] http://jrawio.dev.java.net [3] http://jrawio.tidalwave.it [4] http://cybercom.net/~dcoffin/dcraw/ [5] https://imaging.dev.java.net/TestSetRepository.html [6] http://bluemarine.tidalwave.it [7] http://mistral.tidalwave.it [8] http://www.tidalwave.it [9] http://sourceforge.net/projects/nefio From neugens.limasoftware at gmail.com Sun Mar 2 04:35:56 2008 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Sun, 2 Mar 2008 13:35:56 +0100 Subject: FINAL PROPOSAL: Portable GUI backends Message-ID: <609cc3360803020435n271bcdd2vc4b82abb789af14e@mail.gmail.com> Hello, This is our final proposal submission for a project to improve the AWT and Java2D interfaces to enable the implementation of external backends to AWT/Java2D. Cheers, Mario Final 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 at 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 primitives. 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 enable 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/ -- pgp key: http://subkeys.pgp.net/ Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/ From Fabrizio.Giudici at tidalwave.it Sun Mar 2 08:21:38 2008 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Sun, 2 Mar 2008 17:21:38 +0100 Subject: Feedback for SCA sending Message-ID: <99624C9C-A0AD-436A-B587-C7652A2237F0@tidalwave.it> As requested, a few hours ago I faxed a SCA (hopefully) properly filled. Will I receive a feedback about it (I mean: it has been received, it's properly filled, etc...)? 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/20080302/4d0d9a23/attachment.html From gnu_andrew at member.fsf.org Sun Mar 2 08:31:43 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Sun, 2 Mar 2008 16:31:43 +0000 Subject: FINAL PROPOSAL: Virtual Machine Interface Message-ID: <17c6771e0803020831m14679fafp19e422d27e14bc24@mail.gmail.com> This constitutes my final proposal for the OpenJDK challenge. 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 also 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. Concerning other virtual machines, while it would be good 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 heavily 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 (due to its small size) and/or JikesRVM (its implementation in Java being a proof of concept) seem like more obvious initial targets. 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 (see above for possible VMs) 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 :-) Document Freedom Day - March 26th http://documentfreedom.org Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net From fabrizio.giudici at tidalwave.it Sun Mar 2 08:52:46 2008 From: fabrizio.giudici at tidalwave.it (Fabrizio Giudici) Date: Sun, 2 Mar 2008 17:52:46 +0100 Subject: FINAL PROPOSAL: jrawio - Image I/O codecs for "camera raw" formats Message-ID: FINAL PROPOSAL Provision of jrawio, a set of Image I/O codecs for "camera raw" formats, suitable for inclusion in OpenJDK Fabrizio Giudici fabrizio.giudici(at)tidalwave.it 1. Summary ---------- The Java Image I/O API (javax.imageio) is a specific API of the JDK focused on image input/output. It basically provides a plugin-based set of classes for reading and writing images from/to a stream (both raster and metadata operations are supported). In the standard Java runtime a number of plugins for the most common file formats are available (e.g. JPEG, PNG, BMP), others are in the optional package JAI-Image I/O provided by Sun (e.g. TIFF), others are available as third-parties' plugins. With the advent of professional digital camera bodies, manufacturers such as Nikon, Canon, Minolta Pentax and others have introduced a number of proprietary formats, commonly named "camera raw" formats (NEF, CRW, CR2, MRW, etc...) [1]. In this scenario, also Adobe developed its own format, Adobe Digital Negative (DNG), which has got an open specification. All "Camera raw" formats share the peculiarity of not containing an image ready-to-be-shown, but just a "dump" of the raw data from the digital sensor with a set of annotations about the camera settings at the moment of the shoot. This makes them a sort of "digital negative", as photographers can manipulate ("develop") them in post-production with a much wider gamma of possibilities than JPEG or TIFF would offer; it also makes it easier to implement "non-destructive processing" (the capability of undoing a developing step without compromising the original bits). jrawio [2,3] is an open source implementation of a set of read-only plugins for supporting these formats. jrawio is an original development. At the moment of writing there are no other known Image I/O-compliant plugins for "camera raw" formats. jrawio only uses original code (of course integrated with the Image I/ O API, which implies that jrawio implements some of the interfaces defined by Image I/O). jrawio is partially inspired by dcraw.c by Dave Coffin [4] as most of the "camera raw" formats are undocumented (DNG being a notable exception) and dcraw.c is the only available "documentation" for the community. An older dismissed project by Fabrizio Giudici, NEFio [9], was just the initial version of jrawio with a different name as it only focused on the NEF format. The goal of this proposal is to complete the work required for making jrawio a part of the OpenJDK. This project is a single-developer submission. Fabrizio Giudici is in charge for the rules of the Open JDK Challenge. 2. Need for jrawio ------------------ While most of ?camera raw? formats are a variant of TIFF, they can't be properly handled by the existing TIFF Image I/O plugin, because: 1) it can't understand the proprietary extensions, both in metadata and raster layout, also because often non-standard compression schemata are used 2) as all the other Image I/O plugins, it doesn't perform any post- processing on the raster data The typical post-processing required by ?camera raw? formats is composed by: 1) demosaicing 2) noise reduction 3) boosting of R-G-B channels 4) applying a color profile 5) sharpening 3. Reasons for having jrawio in the OpenJDK ------------------------------------------- We believe that support for ?camera raw? formats should be present in the OpenJDK, and not as a separate extension, since these formats are more and more used by advanced amateurs and professional photographers in place of JPEG and the ubiquitous availability of media codecs out-of-the-box is important for Java to be able to compete with other technologies for the desktop such Adobe Air. Also, a small but specific part of the post-processing (the demosaicing step) could benefit from a small native accelerator, whose presence in the Java runtime would make easier the life for Applet and JavaFX developers. Last but not least, many communities of photographers (see e.g. OpenRAW [10]) have publicly stressed the importance of having open source implementations of software for managing "camera raw" formats; the presence of out-of-the-box codecs would make Java more friendly and appealing for developers targeting the imaging segment. 4. Structure of jrawio ---------------------- jrawio is composed by two parts: a) the javax.imageio plugin which only delivers the capability of reading metadata, thumbnails and "raw" bits out of the stream; b) reajent, the post-processor that "develops" the raw bits into a viewable picture, implementing the typical operations described in the above section. This is an optional component, as applications could decide to provide their own implementation of this part (providing special "recipes" for developing "camera raw" formats is typical of this context). 5. Previous work ---------------- Work on jrawio and reajent has already started [2,3] and a 1.0.RC5 has been delivered which is reasonably stable and suitable for experimental use, but not for production. Since 2007 the focus has been on the setup of a public test suite - some required work and technical problems about tests has slowed down the progress and therefore there have been only a few unofficial releases in the latest year. The submitted project represents the continuation of that development. At the moment, the metadata and raster I/O parts of jrawio support the following formats: CR2, CRW, DNG, MRW, NEF, PEF, SRF, but only for a subset of the existing camera models (each camera model is likely to use a variant of the main format). It is estimated that the current codebase contains about 80% of the needed classes for those formats, that should be complete at 70% (as per the number of camera models existing at the moment of writing). Support for other formats (such as Kodak DCR) should be added, but it's difficult to estimate the effort for them without prior knowledge of their structure. Unit tests exist for about 10% of the codebase, while there are integration tests over a set of around 1,000 image files verifying that jrawio correctly reads rasters, thumbnails and metadata. Beyond the already mentioned technical problems specific of the test code, a licensing problem exists about the test set since it's mainly composed of images available on the Web, with no permission about redistribution. The "Imaging Test Set Repository" initiative [5] should give a solution to this problem. The jrawio and reajent implementations are licensed under the Apache Software License 2.0. We are open to change it as needed for compliance with the OpenJDK licensing. If this proposal is selected, and proceeds to completion, the entire project will be made available under the SCA (both the parts already coded, and the additions made since). 6. Milestones ------------- Development milestones shall ultimately be determined by the working group. However the outline plan is: 1) Provide tests and appropriate bug fixes to verify the full compliance with the javax.imageio APIs 2) Add support for all the camera models using the currently supported formats 3) Provide a small extension mechanism (probably based on META-INF/ services) so support for new camera models requiring specific code can be just dropped in as a classpath extension. This is needed since new camera models using "camera raw" formats are released much more frequently than JDK updates and application developers typically want to stay up to date with the shortest latence. 4) Add support for new "camera raw" formats (e.g. Kodak's DCR) as long as their structure is understood. 7. Deliverables --------------- The deliverables are: 1) The source code of jrawio (both the jrawio plugin and the reajent component) 2) Tests with 90%+ coverage. 3) Source code documentation in the form of javadoc suitable for inclusion in the JDK. Any API extension for dropping in custom-specific reajent replacements does not form part of the deliverables of this proposal, since it won't be possible to complete this task by the August deadline of the OpenJDK Innovation Grant Challenge (considering that it would require a prior submission to JSR etc...). By that time programmers will be able to just disable reajent (by means of the existing javax.imageio API) and will manually post-process the raster at application level. 8. Dependencies on Sun ---------------------- There are no known dependencies on Sun - the project just supports javax.imageio and will be kept up to date with the evolution of those APIs. While jrawio contains some TIFF-related parts, it is completely independent of the JAI-Image I/O TIFF plugin, both at compilation and at runtime stages. 9. Developers ------------- Fabrizio Giudici has been working with Java since 1996, from J2ME to J2EE. Fabrizio has been the designer and the project leader in a number of industrial projects including banking services, support systems for telecommunications and a real-time distribution middleware for telemetry data in Formula One racings. He currently works for his own company, Tidalwave s.a.s. [8], as a Senior Architect, Mentor and Technical Instructor. Has has developed in Open Source since 2003 as the author of jrawio, Mistral [7] and blueMarine [6]. He is a Member of the NetBeans Dream Team since 2007. [1] http://en.wikipedia.org/wiki/Raw_image_format [2] http://jrawio.dev.java.net [3] http://jrawio.tidalwave.it [4] http://cybercom.net/~dcoffin/dcraw/ [5] https://imaging.dev.java.net/TestSetRepository.html [6] http://bluemarine.tidalwave.it [7] http://mistral.tidalwave.it [8] http://www.tidalwave.it [9] http://sourceforge.net/projects/nefio [10] http://www.openraw.org -- 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 srivastava.robin at gmail.com Sun Mar 2 10:45:56 2008 From: srivastava.robin at gmail.com (Robin Srivastava) Date: Mon, 3 Mar 2008 00:15:56 +0530 Subject: FINAL PROPOSAL: Developing APIs for Stream connection between mobile device/application and desktop via bluetooth Message-ID: <002401c87c95$a97dbba0$6802a8c0@HOME> 1.0 Propasal's Idea ???????????????????????????? This propasal puts forward the idea of allowing stream connection between a mobile device/applications (J2ME) and desktop applications (J2SE) using Bluetooth Technology. A number of data sharing methodologies are available for communicating between two or more desktop application or between two or more mobile devices/application. This idea, when materialized, will allow the users to send/receive data from mobile device to PCs in the form of streams of data and vice-versa via bluetooth. 2.0 Background & Abstraction of Idea from it ????????????????????????????????????????????????????????????????? With reference to JSR-82, communication support for the following layers have been already provided by the aforementioned JSR :- >> Service Discovery Protocol >> RFCOMM (type 1 device support) >> Logical Link Control and Adaptation Protocol (L2CAP) >> OBEX Support However the implementation provided by JSR - 82 provide the communication facilities from one mobile device to yet another mobile device. On the similar pattern when we talk about two or more PCs - they can communicate among themselves through various methodologies :- >> Socket programming >> RMI Various types of traffic can be considered while communication which implements a number of different protocols, example - TCP/IP, UDP etc. We will be developing an API which would facilitate stream connection between a mobile device/application and a desktop application. A socket would be created at the desktop application side and similarly a connector would open at the side of mobile device/application. A reference of InputStream and OutputStream on both the sides would be then obtained to send and receive data as streams. 3.0 Implementaion ??????????????????????????? For implementing the idea outlined in this proposal we need to work keeping in mind three different aspacts :- >> making and opening a connector at the mobile side >> making and opening a connector at desktop side >> allowing the communication of data between them. It would follow either its own protocol for communication or some existing standard protocol. 4.0 Dependence From Sun ??????????????????????????????????????? For successful implementation of this idea, Sun Microsystems need not do any changes in its existing API set. 5.0 References ?????????????????????? [1] JSR - 82 [2] http://www.wikipedia.com [3] http://www.java.sun.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/challenge-discuss/attachments/20080303/56be72f7/attachment.html From bryan at varnernet.com Sun Mar 2 14:20:44 2008 From: bryan at varnernet.com (Bryan Varner) Date: Sun, 02 Mar 2008 17:20:44 -0500 Subject: DRAFT PROPOSAL: Porting the HotSpot VM to Haiku x86 Message-ID: <47CB283C.8030901@varnernet.com> 1.) Introduction The OpenJDK porters group is sponsoring a project to port OpenJDK to the Haiku Operating System. Obviously, to achieve our projects goals, we must port the HotSpot VM to our platform. As this is a sizeable amount of work for any team, we are proposing this project to help provide additional incentive to our team members, and bolster the fervor of development. The goals of this project are to port the HotSpot Client and Server Virtual Machines to Haiku for the x86 processor architecture. This project proposal meets the following criterion for project types as outlined by Offical Rules of the OpenJDK Community Innovators' Challenge in section 3.F. 1.) Develops and implements ... that extend the applicability or use of the JavaSE platform into new markets... 3.) Ports the OpenJDK code base to a new and interesting OS and/or hardware architecture. 2.) Deliverables This project will be considered complete with delivery of a) A working build system that others outside of the porting effort can easily duplicate. Artifacts may be generated from directly within Haiku OS using a native tool-chain, or cross-compiled from a host OS. b) All source modifications published to the OpenJDK Haiku Port project. c) Resulting artifacts including both client and server versions of the HotSpot VM. JIT will be enabled, and execution of the 'java -version' command will result in expected (no exceptions, no errors) behavior. 3.) Milestones To acheive these goals, the following basic porting tasks will need to be accomplished. a) Creating a sane build environment suitable for compiling OpenJDK for Haiku x86. b) Builiding out the initial project structure. c) Creation of Haiku specific code. d) Native implementations for many core JavaSE classes. e) Initialization of the "Universe". 3.) Dependencies on Sun There are no dependencies on Sun regarding the porting of OpenJDK to the Haiku OS. 4.) Relevance to the Community Haiku is an emerging, moderm Operating System targeted specifically for desktop computing. It's unique approach to system design, which impacts application scalability, threading performance, and it's tight focus on desktop computing gives it a promising future in a world that is increasingly using SMP to acheive better performance. Having OpenJDK and more specifically the HotSpot VM ported to Haiku will provide an attractive alternative environment for Java developers to work in and target, as well as place OpenJDK one step closer to acheiving the goal of platform ubiquity. From linuxhippy at gmail.com Sun Mar 2 15:02:42 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Mon, 3 Mar 2008 00:02:42 +0100 Subject: DRAFT PROPOSAL: Porting the HotSpot VM to Haiku x86 In-Reply-To: <47CB283C.8030901@varnernet.com> References: <47CB283C.8030901@varnernet.com> Message-ID: <194f62550803021502w8fdbb8cg30fc5b42c801fdc7@mail.gmail.com> Hi Bryan, Although I think the Haiku port of OpenJDK would be a perfect fit for the challenge, I fear that the proposal stage is already over (March 2, 2008 at 11:59 P.M. (PST)). I've maybe understood something wrong (I had to search quite a bit arround to get the delta of UTC-1 and PST), maybe you have luck and its accepted - or I am completly wrong with timezone calculation ... lg Clemens 2008/3/2, Bryan Varner : > 1.) Introduction > The OpenJDK porters group is sponsoring a project to port OpenJDK to > the Haiku Operating System. Obviously, to achieve our projects goals, > we must port the HotSpot VM to our platform. As this is a sizeable > amount of work for any team, we are proposing this project to help > provide additional incentive to our team members, and bolster the > fervor of development. > > The goals of this project are to port the HotSpot Client and Server > Virtual Machines to Haiku for the x86 processor architecture. > > This project proposal meets the following criterion for project types > as outlined by Offical Rules of the OpenJDK Community Innovators' > Challenge in section 3.F. > 1.) Develops and implements ... that extend the applicability > or use of the JavaSE platform into new markets... > > 3.) Ports the OpenJDK code base to a new and interesting OS > and/or hardware architecture. > > 2.) Deliverables > This project will be considered complete with delivery of > a) A working build system that others outside of the porting > effort can easily duplicate. Artifacts may be generated > from directly within Haiku OS using a native tool-chain, or > cross-compiled from a host OS. > b) All source modifications published to the OpenJDK > Haiku Port project. > c) Resulting artifacts including both client and server > versions of the HotSpot VM. JIT will be enabled, and > execution of the 'java -version' command will result in > expected (no exceptions, no errors) behavior. > > 3.) Milestones > To acheive these goals, the following basic porting tasks will need to > be accomplished. > a) Creating a sane build environment suitable for compiling > OpenJDK for Haiku x86. > b) Builiding out the initial project structure. > c) Creation of Haiku specific code. > d) Native implementations for many core JavaSE classes. > e) Initialization of the "Universe". > > 3.) Dependencies on Sun > There are no dependencies on Sun regarding the porting of OpenJDK to > the Haiku OS. > > > 4.) Relevance to the Community > Haiku is an emerging, moderm Operating System targeted specifically > for desktop computing. It's unique approach to system design, which > impacts application scalability, threading performance, and it's tight > focus on desktop computing gives it a promising future in a world that > is increasingly using SMP to acheive better performance. > > Having OpenJDK and more specifically the HotSpot VM ported to Haiku > will provide an attractive alternative environment for Java developers > to work in and target, as well as place OpenJDK one step closer to > acheiving the goal of platform ubiquity. > From scolebourne at joda.org Sun Mar 2 15:17:39 2008 From: scolebourne at joda.org (Stephen Colebourne) Date: Sun, 02 Mar 2008 23:17:39 +0000 Subject: DRAFT PROPOSAL: Porting the HotSpot VM to Haiku x86 In-Reply-To: <194f62550803021502w8fdbb8cg30fc5b42c801fdc7@mail.gmail.com> References: <47CB283C.8030901@varnernet.com> <194f62550803021502w8fdbb8cg30fc5b42c801fdc7@mail.gmail.com> Message-ID: <47CB3593.8020809@joda.org> No, there is still 8 hours to go http://www.timeanddate.com/worldclock/city.html?n=224 Stephen Clemens Eisserer wrote: > Hi Bryan, > > Although I think the Haiku port of OpenJDK would be a perfect fit for > the challenge, I fear that the proposal stage is already over (March > 2, 2008 at 11:59 P.M. (PST)). > I've maybe understood something wrong (I had to search quite a bit > arround to get the delta of UTC-1 and PST), maybe you have luck and > its accepted - or I am completly wrong with timezone calculation ... > > lg Clemens > > 2008/3/2, Bryan Varner : >> 1.) Introduction >> The OpenJDK porters group is sponsoring a project to port OpenJDK to >> the Haiku Operating System. Obviously, to achieve our projects goals, >> we must port the HotSpot VM to our platform. As this is a sizeable >> amount of work for any team, we are proposing this project to help >> provide additional incentive to our team members, and bolster the >> fervor of development. >> >> The goals of this project are to port the HotSpot Client and Server >> Virtual Machines to Haiku for the x86 processor architecture. >> >> This project proposal meets the following criterion for project types >> as outlined by Offical Rules of the OpenJDK Community Innovators' >> Challenge in section 3.F. >> 1.) Develops and implements ... that extend the applicability >> or use of the JavaSE platform into new markets... >> >> 3.) Ports the OpenJDK code base to a new and interesting OS >> and/or hardware architecture. >> >> 2.) Deliverables >> This project will be considered complete with delivery of >> a) A working build system that others outside of the porting >> effort can easily duplicate. Artifacts may be generated >> from directly within Haiku OS using a native tool-chain, or >> cross-compiled from a host OS. >> b) All source modifications published to the OpenJDK >> Haiku Port project. >> c) Resulting artifacts including both client and server >> versions of the HotSpot VM. JIT will be enabled, and >> execution of the 'java -version' command will result in >> expected (no exceptions, no errors) behavior. >> >> 3.) Milestones >> To acheive these goals, the following basic porting tasks will need to >> be accomplished. >> a) Creating a sane build environment suitable for compiling >> OpenJDK for Haiku x86. >> b) Builiding out the initial project structure. >> c) Creation of Haiku specific code. >> d) Native implementations for many core JavaSE classes. >> e) Initialization of the "Universe". >> >> 3.) Dependencies on Sun >> There are no dependencies on Sun regarding the porting of OpenJDK to >> the Haiku OS. >> >> >> 4.) Relevance to the Community >> Haiku is an emerging, moderm Operating System targeted specifically >> for desktop computing. It's unique approach to system design, which >> impacts application scalability, threading performance, and it's tight >> focus on desktop computing gives it a promising future in a world that >> is increasingly using SMP to acheive better performance. >> >> Having OpenJDK and more specifically the HotSpot VM ported to Haiku >> will provide an attractive alternative environment for Java developers >> to work in and target, as well as place OpenJDK one step closer to >> acheiving the goal of platform ubiquity. >> > From fabrizio.giudici at tidalwave.it Sun Mar 2 15:19:57 2008 From: fabrizio.giudici at tidalwave.it (Fabrizio Giudici) Date: Mon, 3 Mar 2008 00:19:57 +0100 Subject: DRAFT PROPOSAL: Porting the HotSpot VM to Haiku x86 In-Reply-To: <194f62550803021502w8fdbb8cg30fc5b42c801fdc7@mail.gmail.com> References: <47CB283C.8030901@varnernet.com> <194f62550803021502w8fdbb8cg30fc5b42c801fdc7@mail.gmail.com> Message-ID: <989CA744-4015-49CC-B054-69C456FBA912@tidalwave.it> On 03/mar/08, at 00:02, Clemens Eisserer wrote: > Hi Bryan, > > Although I think the Haiku port of OpenJDK would be a perfect fit for > the challenge, I fear that the proposal stage is already over (March > 2, 2008 at 11:59 P.M. (PST)). > I've maybe understood something wrong (I had to search quite a bit > arround to get the delta of UTC-1 and PST), maybe you have luck and > its accepted - or I am completly wrong with timezone calculation ... Pacific Time has still about 8 hours to go... -- 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/20080303/98e0f98a/attachment.html From Tim.Bell at Sun.COM Sun Mar 2 15:24:44 2008 From: Tim.Bell at Sun.COM (Tim Bell) Date: Sun, 02 Mar 2008 15:24:44 -0800 Subject: DRAFT PROPOSAL: Porting the HotSpot VM to Haiku x86 In-Reply-To: <194f62550803021502w8fdbb8cg30fc5b42c801fdc7@mail.gmail.com> References: <47CB283C.8030901@varnernet.com> <194f62550803021502w8fdbb8cg30fc5b42c801fdc7@mail.gmail.com> Message-ID: <47CB373C.2020201@sun.com> Clemens Eisserer wrote: > fear that the proposal stage is already over (March > 2, 2008 at 11:59 P.M. (PST)). 11:59 PM is one minute before midnight. Compare that to 11:59 AM which is one minute before noon. I had this discussion recently with some Danish friends. Perhaps this terminology is more unique to the USA than we realize. It is currently 3:33PM out here in Silicon Valley, so by my reading of the rules the gates are open for final proposals until bedtime PST tonite, Sunday 2 March 2008. Feel free to check the local time here (for any timezone, although I set up the link for PST): http://www.time.gov/timezone.cgi?Pacific/d/-8 HTH - Tim From kalli at midverk.is Sun Mar 2 16:10:42 2008 From: kalli at midverk.is (Karl Helgason) Date: Mon, 3 Mar 2008 00:10:42 +0000 Subject: FINAL PROPOSAL: Free Software synthesizer implemention for the OpenJDK project In-Reply-To: <36EC82E93EB0AD40A4301DAD654323868CA2BA97CB@mail.midverk.is> References: <36EC82E93EB0AD40A4301DAD654323868CA2BA97CB@mail.midverk.is> Message-ID: <36EC82E93EB0AD40A4301DAD654323868CA2BA97CC@mail.midverk.is> FINAL PROPOSAL Free Software synthesizer implementation for the OpenJDK project Karl Helgason kalli(at)midverk.is Summary ======= The current software synthesizer for JDK (Beatnik) is part of encumbered code which can not be released open source. It is also mostly written in native code which makes support and enhancements difficult. Furthermore the current software synthesizer does only support its own proprietary soundbank file format. Thus we need a new synthesizer engine for JDK which can be released open source and which supports open and widely used soundbank formats (such as DLS and SoundFonts). We also need that the new synthesizer will work in a similar manner to the current one in JDK so compatibility with older applications will be maintained. Finally, by writing the new synthesizer engine in Java it will be easer to support and make enhancement to the engine in the future. This will also mean safer and more portable code. Goals ===== The goal is to create an open source software MIDI synthesizer which can be integrated into the openJDK project. We need a high quality synthesizer with support for universal and open soundbank formats like SoundFont (http://www.soundblaster.com/soundfont/) and DLS (Downloadable Sounds, http://www.midi.org). The Audio Engine Project gave these requirements for solution: * Pure-Java implementation. * Uses JavaSound mixers/lines for sound output. * Supports DLS and/or SoundFont soundbank files. In addition to the base requireaments the engine will have support for: * General Midi Level 2 * Downloadable Sounds Level 2.2 * Midi Tuning Standard * SoundFont 2.04 These requests for enhancement will also be resolved with this proposal: Bug ID: 4705306 RFE: Adding Microtonal support to Java Sound API Bug ID: 4666912 RFE: Add support for soundbanks contained in SoundFont and DLS files. Development =========== Development takes place at the Audio Synthesis Engine Project: http://openjdk.java.net/projects/audio-engine/ All communications regarding this project are done at the audio-engine-dev mailing list. Access to source code is at: https://gervill.dev.java.net/ Dependencies on Sun =================== Creating the software synthesizer engine itself will not require any assistance from Sun. Integration into the OpenJDK 6 and OpenJDK 7 will be handled by Sun. However, the software engine will also work standalone without any work from Sun. Developer ========= Karl Helgason is the developer for this project and has previously created the SoundFont engine for the RasmusDSP project: http://sourceforge.net/projects/rasmusdsp, he is also a member of the Frinika project which is a complete music workstation written in Java. http://sourceforge.net/projects/frinika From tor-einar at jarnbjo.name Sun Mar 2 16:42:58 2008 From: tor-einar at jarnbjo.name (Tor-Einar Jarnbjo) Date: Mon, 03 Mar 2008 01:42:58 +0100 Subject: FINAL PROPOSAL: JavaSound extensions and service providers for Ogg/Vorbis and Ogg/FLAC Message-ID: <6448749.11056981204504979087.JavaMail.root@yggdrasil.jarnbjo.name> * 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 gnu_andrew at member.fsf.org Sun Mar 2 16:46:16 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 3 Mar 2008 00:46:16 +0000 Subject: DRAFT PROPOSAL: Porting the HotSpot VM to Haiku x86 In-Reply-To: <47CB373C.2020201@sun.com> References: <47CB283C.8030901@varnernet.com> <194f62550803021502w8fdbb8cg30fc5b42c801fdc7@mail.gmail.com> <47CB373C.2020201@sun.com> Message-ID: <17c6771e0803021646u71427f45s7c7644d15f5a1306@mail.gmail.com> On 02/03/2008, Tim Bell wrote: > Clemens Eisserer wrote: > > fear that the proposal stage is already over (March > > 2, 2008 at 11:59 P.M. (PST)). > > > 11:59 PM is one minute before midnight. Compare that to 11:59 AM which is one minute before > noon. I had this discussion recently with some Danish friends. Perhaps this terminology is > more unique to the USA than we realize. > > It is currently 3:33PM out here in Silicon Valley, so by my reading of the rules the gates are > open for final proposals until bedtime PST tonite, Sunday 2 March 2008. > > Feel free to check the local time here (for any timezone, although I set up the link for PST): > http://www.time.gov/timezone.cgi?Pacific/d/-8 > > HTH - Tim > I understood the time correctly first time, but then all the odd comments today made me go and double-check that it was P.M. It's basically just the end of Sunday in California (the minute after is 00:00 on the 3rd, perhaps it should have been quoted as 23:59 to make it clearer, P.M. or Post-Meridiem can be unclear especially in other locales I guess). Times being in PST is something I sort of got used to during Google's Summer of Code which also uses this as its time basis. 23:59 PST is 8am on Monday morning here in the UK (UTC+0000 at the moment) and even more into the day if you're further east. Hope that clears things up, -- Andrew :-) Document Freedom Day - March 26th http://documentfreedom.org Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net From alexhsun at gmail.com Sat Mar 1 23:53:44 2008 From: alexhsun at gmail.com (Haitao Sun) Date: Sun, 2 Mar 2008 15:53:44 +0800 Subject: FINAL PROPOSAL: Implementing Modified CICE and Block-Attached Calling Message-ID: FINAL PROPOSAL Implementing Modified CICE and Block-Attached Calling SUN Haitao I propose implementing a Java compiler with the following features: * A new form of instance creating expression based on CICE[2] (with some modification). * A general control abstraction mechanism called "Block-Attached Calling" (like "blocks"[1] in Ruby). * An annotation to indicate the "major" method of concrete classes. (So they can be treated like single-abstract-method types) 1. Design Goals =============== The major goal of this proposal is to try to add an expressive control abstraction mechanism to Java in an easy-to-grasp way. The minor goal of this proposal is to try to find out an attractive solution for those who don't want closures in Java 7. A less expressive mechanism often is bundled with the following problems: 1) It can't express some useful abstractions. That takes programs both hard to write and hard to read. 2) It's not cool enough. Then no one want to try it in early stage. Without hundreds of thousands of explorers, it's pretty hard to know the feature's potentials, limitations, and proper usage. 3) Similar mechanism will be introduced again and again to express more useful abstractions. That hurts orthogonality and brings complexity. A hard-to-grasp mechanism often have the following short-comings: 1) It's hard to learn. Smart developers can certainly handle this problem, but they will yield much more and make a better world by focusing on real problems. 2) It's hard to implement and optimize. The absence of optimized implementation will prolong adoption cycle, and being adopted fast is a key factor to success in market. 2. Introductions ================ All three features proposed are inspired by original CICE proposal. 2.1 The modified CICE I propose the following modification to CICE: 1) For concrete classes, the name of the method to be override can be used to solve ambiguity. 2) When being used as arguments, the type part is optional. 2.2 the BAC mechanism I propose a mechanism called Block-Attached Calling. It works like Ruby blocks. So we can test whether mechanisms to define control constructs are worth adding. The main idea of BAC is that if the last argument is an CICE, its body can be placed after the right parenthesis of the method calling. If the CICE has a formal parameter list, it should be quoted with "|" and used as the last argument. If we adopt this proposal, we can write the following samples: // Loop Abstraction // ``repeat`` is an user-defined method repeat(3, |int i|) { //do something } // Resource Management // ``with`` is an user-defined method with(resource) { //do something } There is no public draft specification of BAC yet. 2.3 The "major" Annotation I propose an annotation called "major" to indicate the "major" method of concrete classes. Concrete classes with one method annotated as "major" can be treated like single-abstract-method types. The "major" method will be treated as the single abstract method. 3. Deliverables =============== The planned deliverables are: 1) The specification of the Block-Attached Calling mechanism and the modified CICE. 2) The source code of the prototype compiler and related test suite. 3) The implementation and javadoc of the "major" annotation. 4. Existing Works ================= The compiler will based on an SVN version of the compiler in OpenJDK. Some further ideas may be inspired by BGGA[3] proposal and FCM[4] proposal. 5. Dependencies on Sun ====================== There are no known dependencies on Sun with following exceptions: * The compiler is based on the compiler in OpenJDK. * "SUN" happens to be my surname. 6. Related Works ================ [1] Programming Ruby http://ruby-doc.org/docs/ProgrammingRuby/html/tut_containers.html [2] Concise Instance Creation Expressions: Closures without Complexity http://docs.google.com/View?docid=k73_1ggr36h [3] Closures for the Java Programming Language http://javac.info/ [4] First-Class Methods http://docs.google.com/View?docid=ddhp95vd_0f7mcns From bryan at varnernet.com Sun Mar 2 19:20:10 2008 From: bryan at varnernet.com (Bryan Varner) Date: Sun, 02 Mar 2008 22:20:10 -0500 Subject: FINAL PROPOSAL: Porting the HotSpot VM to Haiku x86 Message-ID: <47CB6E6A.70806@varnernet.com> FINAL PROPOSAL Porting the HotSpot VM to Haiku, x86. Bryan Varner (team lead) & Andrew Bachmann bryan(at)varnernet.com andrewbachmann(at)gmail.com 1.) Introduction ---------------- The OpenJDK porters group is sponsoring a project to port OpenJDK to the Haiku Operating System. Obviously, to achieve our projects goals, we must port the HotSpot VM to our platform. As this is a sizable amount of work for any team, we are proposing this project to help provide additional incentive to our team members, and bolster the fervor of development. The goals of this project are to port the HotSpot Client and Server Virtual Machines to Haiku for the x86 processor architecture. This project proposal meets the following criterion for project types as outlined by Official Rules of the OpenJDK Community Innovators' Challenge in section 3.F. 1.) Develops and implements ... that extend the applicability or use of the JavaSE platform into new markets... 3.) Ports the OpenJDK code base to a new and interesting OS and/or hardware architecture. 2.) Deliverables ---------------- This project will be considered complete with delivery of a) A working build system that others outside of the porting effort can easily duplicate. Artifacts may be generated from directly within Haiku OS using a native tool-chain, or cross-compiled from a host OS. b) All source modifications published to the OpenJDK Haiku Port project. c) Resulting artifacts including both client and server versions of the HotSpot VM. JIT will be enabled, and execution of the 'java -version' command will result in expected (no exceptions, no errors) behavior. 3.) Milestones -------------- To achieve these goals, the following basic porting tasks will need to be accomplished. a) Creating a sane build environment suitable for compiling OpenJDK for Haiku x86. b) Building out the initial project structure. c) Creation of Haiku specific code. d) Native implementations for many core JavaSE classes. e) Initialization of the "Universe". 4.) Dependencies on Sun ----------------------- There are no dependencies on Sun regarding the porting of OpenJDK to the Haiku OS. 5.) Relevance to the Community ------------------------------ Haiku is an emerging, modern Operating System targeted specifically for desktop computing. It's unique approach to system design, which impacts application scalability, threading performance, and it's tight focus on desktop computing gives it a promising future in a world that is increasingly using SMP to achieve better performance. Having OpenJDK and more specifically the HotSpot VM ported to Haiku will provide an attractive alternative environment for Java developers to work in and target, as well as place OpenJDK one step closer to achieving the goal of platform ubiquity. 6.) Developers -------------- Andrew Bachmann has worked with Java since 2000 and in open source since 2000. Andrew is a cross-kit committer on the Haiku OS project. Andrew was the lead developer for the BeUnited project to port the Sun JDK to BeOS. Andrew has ported several applications to BeOS and often contributes patches during these ports. Andrew is currently working at the NASA Ames Research Center building systems for mixed-initiative planning. Bryan Varner has worked with Java and has been an active contributor to several Open Source projects since 2001. Bryan was involved in the BeUnited project led by Andrew to port the Sun JDK to BeOS, and has committed code to the Haiku OS project in several areas. Bryan is a senior consultant at Moser Consulting, Inc. specializing in Java based systems by day, and administrative lead of the Haiku OS Java team by night. From ted at tedneward.com Sun Mar 2 20:07:41 2008 From: ted at tedneward.com (Ted Neward) Date: Sun, 2 Mar 2008 20:07:41 -0800 Subject: FINAL PROPOSAL: OpenJDK on Windows In-Reply-To: <013d01c87bcd$93425850$b9c708f0$@com> References: <013d01c87bcd$93425850$b9c708f0$@com> Message-ID: <037a01c87ce4$232fc4e0$698f4ea0$@com> FINAL PROPOSAL: OpenJDK on Windows ===================================== Ted Neward ted at tedneward dot com Revamp the OpenJDK build process on Windows I propose to rewrite/port the OpenJDK build processes for the Windows platform to take advantage of the new freely-available compilers and toolchain (Visual C++ 2008 Express) and more Windows-friendly tools (MinGW), so as to enable a more Windows-friendly environment in which OpenJDK developers can more easily participate. This proposal includes the following ideas o adjust the Hotspot build processes to Visual C++ 9.0 o adjust the Hotspot build processes to make use of MSBuild o adjust the overall build environment to use MinGW instead of Cygwin The result of the proposal will be an environment by which developers working on the Windows platform can simply download MinGW and the freely-available Visual C++ Express, run the appropriate batch file to establish an environment in which to build, and type ?make?. The Clear Need ============== Building the JDK on Windows has always been an arcane art. A quick glance at the build-dev mailing list archives reveals the disparity in ease between building the OpenJDK on a *nix-based platform and doing the same on Windows. The fact that Sun?s own expertise is clearly focused on the *nix platform does not help matters; developers trying to build the OpenJDK on Windows end up facing numerous challenges and find close to zero resources "in the field" to help navigate some of the more treacherous paths, despite the fact that the Windows platform, for all its flaws, clearly remains one of the most important development platforms of the day. If the OpenJDK project is going to be open to developers working on the Windows platform, significant steps must be made to ease this process. The transition to the free Microsoft toolchains will also have a huge financial impact on the OpenJDK community--and Sun Microsystems in particular, in that now the Professional versions (which charge a license fee for each seat using it) are required in order to build the OpenJDK sources, at several thousand dollars a head. Porting this over to Visual C++ Express and/or MinGW?s gcc could reduce that cost to zero. Development Guidelines ====================== Development of this project will take place in accordance with the openjdk development guidelines, on a branch of the official Mercurial repositories. No structural source changes are anticipated, however major changes to the build processes (makefiles and shell scripts) are obviously a key part of the project. Dependence on Sun and other resources ===================================== Development of this project should not require significant amounts of Sun resources: some level of coordination with the build team, most notably Kelly O?Hair and possibly any other Sun developers involved with the Windows build process, will obviously be required, and some degree of coordination with the development teams writing platform- specific parts of the OpenJDK sources (AWT, JavaSound, etc) may be required in order to ensure a smooth transition when compiling native code, but this is not anticipated to be large--ideally, a simple request to test the candidate build structure periodically and report errors. Project Plan and Milestones =========================== It is difficult to provide milestones and a concrete plan at this time, as much of this project is research-based: does the Visual C++ Express product have all the necessary library and include file support to build the OpenJDK, does the MinGW toolchain provide the necessary tools to build the OpenJDK, and so on. It is believed that the project would not exceed several months of work, however this is merely a guess at this point in time. Some of the project goals are also potentially unclear: for example, Microsoft?s clear ?path forward? with respect to build tools is to use MSBuild instead of Makefiles, however, MinGW could continue to use GNU make (or something similar) if the supporters of this proposal felt that a change to MSBuild would create a "competency gap" that the OpenJDK community would have a hard time closing. These recommendations could heighten or reduce project work accordingly. Copyright ========= This proposal, in its entirety, is hereby contributed under the terms of the Sun Contributor Agreement. Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing HYPERLINK "http://www.tedneward.com"http://www.tedneward.com No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.21.2/1305 - Release Date: 2/29/2008 6:32 PM No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.21.2/1305 - Release Date: 2/29/2008 6:32 PM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.21.2/1305 - Release Date: 2/29/2008 6:32 PM -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/challenge-discuss/attachments/20080302/750885a1/attachment.html From linuxhippy at gmail.com Sun Mar 2 23:20:38 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Mon, 3 Mar 2008 08:20:38 +0100 Subject: DRAFT PROPOSAL: Porting the HotSpot VM to Haiku x86 In-Reply-To: <17c6771e0803021646u71427f45s7c7644d15f5a1306@mail.gmail.com> References: <47CB283C.8030901@varnernet.com> <194f62550803021502w8fdbb8cg30fc5b42c801fdc7@mail.gmail.com> <47CB373C.2020201@sun.com> <17c6771e0803021646u71427f45s7c7644d15f5a1306@mail.gmail.com> Message-ID: <194f62550803022320t6ed2648ap8be3ee37714067b5@mail.gmail.com> Hi again, > > 11:59 PM is one minute before midnight. Compare that to 11:59 AM which is one minute before > > noon. I had this discussion recently with some Danish friends. Perhaps this terminology is > > more unique to the USA than we realize. Sorry, I misinterpreted the whole am/pm thing. Sorry for spreading confusion :-/ lg Clemens From dario at nycjava.net Mon Mar 3 21:01:25 2008 From: dario at nycjava.net (Dario Laverde) Date: Tue, 4 Mar 2008 00:01:25 -0500 Subject: FINAL PROPOSAL: Headless OpenJDK Message-ID: FINAL PROPOSAL: Headless OpenJDK Dario Laverde dario(at)nycjava.net 1.) Introduction ---------------- I propose the creation of a port or branch or more appropriately, a subset of the OpenJDK to specifically support embedded and mobile devices without any GUI (i.e. no AWT or Swing or Java 2D) and optionally without sound support or additional Java SE libraries that are not required by the application so as to run in disk and memory space constrained devices. The goals of this project is to provide a Java implementation that will be suited for devices such as wireless routers, single board devices, PDAs, mobile phones and essentially any device where either there is no user interface or the user interface is proprietary or not easy to port to without significant effort. Much like the case with headless servers, Java implementations should be able to run without any UI requirements but additionally it should also have all such related library code (both Java and native code) stripped to provide a minimal footprint suitable for use in embedded and mobile devices. Without resorting to a modular system, the goal is to provide a compact Java SE runtime deliverable targeting a specific device or platform. This project proposal meets the following criterion for project types as outlined by Official Rules of the OpenJDK Community Innovators' Challenge in section 3.F. 1.) Develops and implements ... that extend the applicability or use of the JavaSE platform into new markets... 3.) Ports the OpenJDK code base to a new and interesting OS and/or hardware architecture. 2.) Deliverables ---------------- This project will be considered complete with delivery of a) A working build system that others outside of the porting effort can easily duplicate. This can optionally include cross compilation tools/support. b) All source modifications (if required) published to the OpenJDK project. 3.) Milestones -------------- a) Develop an easy to use build environment consisting of either a branch or of tools that will strip away any dependencies on GUI support and unnecessary libraries for a given device and/or platform. b) Proof of concept releases running on several devices. 4.) Dependencies on Sun ----------------------- There is no dependence on Sun, outside of their role in the OpenJDK project. 5.) Relevance to the Community ------------------------------ In addition to eliminating all the issues regarding any remaining incumberances, developers should be able to freely use the latest OpenJDK sources (as opposed to 3rd part efforts) as the basis for porting to any device without regard to UI restrictions or the lack of UI support. For devices such as PDAs or mobile devices that provide web browsers, standalone, downloadable applications can provide users a UI via the web browser. Considering the current and future capabilities of the web browsers found on some devices, the need for native GUI becomes less of a requirement for custom Java applications to be available on almost any device. 6.) Developers -------------- Dario Laverde has been developing in Java since 1995 and has successfully ported and/or used third party open source JVMs in commercial and open source projects, from wireless routers to robots to mobile phones such as the iPhone. He is the JUG leader of the NYCJava.net JUG -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/challenge-discuss/attachments/20080304/6a294457/attachment.html From Richard.Sands at Sun.COM Wed Mar 5 03:46:01 2008 From: Richard.Sands at Sun.COM (Rich Sands) Date: Wed, 05 Mar 2008 06:46:01 -0500 Subject: FINAL PROPOSAL: Headless OpenJDK In-Reply-To: References: Message-ID: <47CE87F9.9040004@sun.com> Hello Dario, Thanks for your proposal. Unfortunately it did not come in before the deadline for proposal submissions as laid out in the Official Rules which you can find at http://openjdk.java.net/challenge/rules/. The submission deadline was March 2, 2008 at 11:59pm PST. Your proposal was received after this time. Thanks again for your proposal - this is not a judgement on its merit, but we can't add it to the entry list. Regards, -- rms Dario Laverde wrote: > FINAL PROPOSAL: Headless OpenJDK > -- 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 Richard.Sands at Sun.COM Wed Mar 5 04:00:57 2008 From: Richard.Sands at Sun.COM (Rich Sands) Date: Wed, 05 Mar 2008 07:00:57 -0500 Subject: List of received proposals Message-ID: <47CE8B79.7060700@sun.com> 17 Proposals - wow! Here's the list of Final Proposals we received. If you're on this list, you are entered in the proposal phase. Please check that we got your name(s) - I think I got all team members but I might have made a mistake. Thanks again for your interest in the Challenge! -- rms ------------------------------------ 1. An automatic process to shrink and optimize the OpenJDK run-time libraries Eric Lafortune 2. Implement Closures for Java Neal Gafter 3. Meta-compiler for non-java code to run on the java virtual machine Stig Anders Bj?rklund 4. Implement XRender pipeline for Java2D Clemens Eisserer 5. Porting the PyPy JIT to JVM and MLVM Antonio Cuni Carl Friedrich Bolz Nicholas Matsakis 6. Pattern Oriented Framework for the rapid implementation of Java applications Edgar Galvis 7. JSR-310, Date and Time API Stephen Colebourne Michael Nascimento Santos 8. Pot Pourri - Augmented Stack Traces, ServiceProvider annotation and processor, Enhanced For Loop utility class Bruce Chapman 9. Implementing Modified CICE and Block-Attached Calling Haitao Sun 10. Portable GUI Backends Roman Kennke Mario Torre 11. Virtual Machine Interface Andrew John Hughes 12. Provision of jrawio, a set of Image I/O codecs for "camera raw" formats, suitable for inclusion in OpenJDK Fabrizio Giudici 13. Stream connection between mobile device/application and desktop via bluetooth Robin Sreivastava 14. Free Software synthesizer implementation for the OpenJDK project Karl Helgason 15. "JavaSound extensions and service providers for Ogg/Vorbis and Ogg/FLAC" Tor-Einar Jarnbjo 16. Porting the HotSpot VM to Haiku, x86 Bryan Varner Andrew Bachmann 17. OpenJDK on Windows Ted Neward -- 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 twalljava at dev.java.net Wed Mar 5 06:20:30 2008 From: twalljava at dev.java.net (Timothy Wall) Date: Wed, 05 Mar 2008 09:20:30 -0500 Subject: List of received proposals In-Reply-To: <47CE8B79.7060700@sun.com> References: <47CE8B79.7060700@sun.com> Message-ID: Where's Wayne Meissner's native invocation proposal? On Mar 5, 2008, at 7:00 AM, Rich Sands wrote: > 17 Proposals - wow! > > Here's the list of Final Proposals we received. If you're on this > list, you are entered in the proposal phase. Please check that we > got your name(s) - I think I got all team members but I might have > made a mistake. Thanks again for your interest in the Challenge! > > -- rms > > ------------------------------------ > > 1. An automatic process to shrink and optimize > the OpenJDK run-time libraries Eric > Lafortune > > 2. Implement Closures for Java Neal Gafter > > 3. Meta-compiler for non-java code to run on > the java virtual machine Stig > Anders Bj?rklund > > 4. Implement XRender pipeline for Java2D Clemens > Eisserer > > 5. Porting the PyPy JIT to JVM and MLVM Antonio Cuni > Carl > Friedrich Bolz > Nicholas > Matsakis > > 6. Pattern Oriented Framework for the rapid > implementation of Java applications Edgar Galvis > > 7. JSR-310, Date and Time API Stephen > Colebourne > Michael > Nascimento Santos > > 8. Pot Pourri - Augmented Stack Traces, > ServiceProvider annotation and processor, > Enhanced For Loop utility class Bruce > Chapman > > 9. Implementing Modified CICE and Block-Attached > Calling Haitao Sun > > 10. Portable GUI Backends Roman Kennke > Mario Torre > > 11. Virtual Machine Interface Andrew > John Hughes > > 12. Provision of jrawio, a set of Image I/O codecs > for "camera raw" formats, suitable for inclusion > in OpenJDK Fabrizio > Giudici > > 13. Stream connection between mobile > device/application and desktop via bluetooth Robin > Sreivastava > > 14. Free Software synthesizer implementation for > the OpenJDK project Karl > Helgason > > 15. "JavaSound extensions and service providers > for Ogg/Vorbis and Ogg/FLAC" Tor-Einar > Jarnbjo > > 16. Porting the HotSpot VM to Haiku, x86 Bryan Varner > Andrew > Bachmann > > 17. OpenJDK on Windows Ted Neward > > -- > 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 Richard.Sands at Sun.COM Wed Mar 5 06:47:40 2008 From: Richard.Sands at Sun.COM (Rich Sands) Date: Wed, 05 Mar 2008 09:47:40 -0500 Subject: List of received proposals In-Reply-To: References: <47CE8B79.7060700@sun.com> Message-ID: <47CEB28C.8040303@sun.com> Oops - my bug! Thank you for pointing that one out. This is why having lots of eyes on things is good! New list coming out shortly. Sorry about that Wayne, and all! -- rms Timothy Wall wrote: > Where's Wayne Meissner's native invocation proposal? > > On Mar 5, 2008, at 7:00 AM, Rich Sands wrote: > >> 17 Proposals - wow! >> >> Here's the list of Final Proposals we received. If you're on this >> list, you are entered in the proposal phase. Please check that we got >> your name(s) - I think I got all team members but I might have made a >> mistake. Thanks again for your interest in the Challenge! >> >> -- rms >> >> ------------------------------------ >> >> 1. An automatic process to shrink and optimize >> the OpenJDK run-time libraries Eric Lafortune >> >> 2. Implement Closures for Java Neal Gafter >> >> 3. Meta-compiler for non-java code to run on >> the java virtual machine Stig Anders >> Bj?rklund >> >> 4. Implement XRender pipeline for Java2D Clemens >> Eisserer >> >> 5. Porting the PyPy JIT to JVM and MLVM Antonio Cuni >> Carl >> Friedrich Bolz >> Nicholas >> Matsakis >> >> 6. Pattern Oriented Framework for the rapid >> implementation of Java applications Edgar Galvis >> >> 7. JSR-310, Date and Time API Stephen >> Colebourne >> Michael >> Nascimento Santos >> >> 8. Pot Pourri - Augmented Stack Traces, >> ServiceProvider annotation and processor, >> Enhanced For Loop utility class Bruce Chapman >> >> 9. Implementing Modified CICE and Block-Attached >> Calling Haitao Sun >> >> 10. Portable GUI Backends Roman Kennke >> Mario Torre >> >> 11. Virtual Machine Interface Andrew John >> Hughes >> >> 12. Provision of jrawio, a set of Image I/O codecs >> for "camera raw" formats, suitable for inclusion >> in OpenJDK Fabrizio >> Giudici >> >> 13. Stream connection between mobile >> device/application and desktop via bluetooth Robin >> Sreivastava >> >> 14. Free Software synthesizer implementation for >> the OpenJDK project Karl Helgason >> >> 15. "JavaSound extensions and service providers >> for Ogg/Vorbis and Ogg/FLAC" Tor-Einar >> Jarnbjo >> >> 16. Porting the HotSpot VM to Haiku, x86 Bryan Varner >> Andrew Bachmann >> >> 17. OpenJDK on Windows Ted Neward >> >> -- >> 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. >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > -- 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 Richard.Sands at Sun.COM Wed Mar 5 06:52:07 2008 From: Richard.Sands at Sun.COM (Rich Sands) Date: Wed, 05 Mar 2008 09:52:07 -0500 Subject: UPDATED List of received proposals Message-ID: <47CEB397.3080201@sun.com> Now 18 Proposals! Sorry I missed you Wayne - you're in there now. -- rms ------------------------------------ 1. An automatic process to shrink and optimize the OpenJDK run-time libraries Eric Lafortune 2. Implement Closures for Java Neal Gafter 3. Meta-compiler for non-java code to run on the java virtual machine Stig Anders Bj?rklund 4. Implement XRender pipeline for Java2D Clemens Eisserer 5. Porting the PyPy JIT to JVM and MLVM Antonio Cuni Carl Friedrich Bolz Nicholas Matsakis 6. Pattern Oriented Framework for the rapid implementation of Java applications Edgar Galvis 7. JSR-310, Date and Time API Stephen Colebourne Michael Nascimento Santos 8. Pot Pourri - Augmented Stack Traces, ServiceProvider annotation and processor, Enhanced For Loop utility class Bruce Chapman 9. Java Foreign Function Interface Wayne Meissner 10. Implementing Modified CICE and Block-Attached Calling Haitao Sun 11. Portable GUI Backends Roman Kennke Mario Torre 12. Virtual Machine Interface Andrew John Hughes 13. Provision of jrawio, a set of Image I/O codecs for "camera raw" formats, suitable for inclusion in OpenJDK Fabrizio Giudici 14. Stream connection between mobile device/application and desktop via bluetooth Robin Sreivastava 15. Free Software synthesizer implementation for the OpenJDK project Karl Helgason 16. "JavaSound extensions and service providers for Ogg/Vorbis and Ogg/FLAC" Tor-Einar Jarnbjo 17. Porting the HotSpot VM to Haiku, x86 Bryan Varner Andrew Bachmann 18. OpenJDK on Windows Ted Neward -- 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 shubhanshu.pathak at gmail.com Wed Mar 5 10:33:31 2008 From: shubhanshu.pathak at gmail.com (shubhanshu pathak) Date: Thu, 6 Mar 2008 00:03:31 +0530 Subject: FINAL PROPOSAL: Robotics package in JDK Message-ID: *Robotic package in JDK* * * *Need for this API:* As robots are becoming increasingly popular, research at a very large scale is going on in the field of robotics. New robots are being developed everyday serving daily human work to scientific applications in laboratory. This increases the need to develop software for robots. In this context Microsoft had developed Microsoft robotic studio which provide environment to develop softwares which are written in visual studio languages. Also they had provided the tool which can burn these programs onto the robots memory. *Innovation:* Idea is to firstly develop a complete package which can provide a framework to develop robotic application in java. Secondly adding a Robotic Emulator in Net Beans to provide platform to test and run these applications virtually, and generate the assembly code. Then this code can be actually burnt on to the memory of the robot and made to run the robot physically. The package will provide a generic model for a robot with generic classes and interfaces. Like MidLets are the bases to develop mobile application. Similarly few classes will be provided to develop a model of robot. *Work Flow:* As we know that basis of the working of the robots is the micro-controller so in our first step we will provide all the possible configurations of the same and the possible customization for it. Since the hardware limitations are there so we will be providing output in terms of the best possible interface. Now once the robot engineer gets the prior look of the actual functioning of his/her robot he/she can go for the emulation device of the net-beans. Since the robots learn from the environment while performing there task so sense ability of them can also be embedded by having a parallel thread of the possible hurdles which let it to judge the best possible activity. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/challenge-discuss/attachments/20080306/0c79d848/attachment.html From gnu_andrew at member.fsf.org Wed Mar 5 10:40:22 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 5 Mar 2008 18:40:22 +0000 Subject: UPDATED List of received proposals In-Reply-To: <47CEB397.3080201@sun.com> References: <47CEB397.3080201@sun.com> Message-ID: <17c6771e0803051040x6e2caca3u3df0e9983a5bde72@mail.gmail.com> On 05/03/2008, Rich Sands wrote: > Now 18 Proposals! > > Sorry I missed you Wayne - you're in there now. > > -- rms > > ------------------------------------ > > 1. An automatic process to shrink and optimize > the OpenJDK run-time libraries Eric Lafortune > > 2. Implement Closures for Java Neal Gafter > > 3. Meta-compiler for non-java code to run on > the java virtual machine Stig Anders Bj?rklund > > 4. Implement XRender pipeline for Java2D Clemens Eisserer > > 5. Porting the PyPy JIT to JVM and MLVM Antonio Cuni > Carl Friedrich Bolz > Nicholas Matsakis > > 6. Pattern Oriented Framework for the rapid > implementation of Java applications Edgar Galvis > > 7. JSR-310, Date and Time API Stephen Colebourne > Michael Nascimento Santos > > 8. Pot Pourri - Augmented Stack Traces, > ServiceProvider annotation and processor, > Enhanced For Loop utility class Bruce Chapman > > 9. Java Foreign Function Interface Wayne Meissner > > 10. Implementing Modified CICE and Block-Attached > Calling Haitao Sun > > 11. Portable GUI Backends Roman Kennke > Mario Torre > > 12. Virtual Machine Interface Andrew John Hughes > > 13. Provision of jrawio, a set of Image I/O codecs > for "camera raw" formats, suitable for inclusion > in OpenJDK Fabrizio Giudici > > 14. Stream connection between mobile > device/application and desktop via bluetooth Robin Sreivastava > > 15. Free Software synthesizer implementation for > the OpenJDK project Karl Helgason > > 16. "JavaSound extensions and service providers > for Ogg/Vorbis and Ogg/FLAC" Tor-Einar Jarnbjo > > 17. Porting the HotSpot VM to Haiku, x86 Bryan Varner > Andrew Bachmann > > 18. OpenJDK on Windows Ted Neward > > -- > 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. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Interesting that in the end, proposals were all written by at most three people (with sole authorship being common). -- Andrew :-) Document Freedom Day - March 26th http://documentfreedom.org Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net From remaker at devtaste.com Tue Mar 11 09:13:52 2008 From: remaker at devtaste.com (Haitao Sun) Date: Wed, 12 Mar 2008 00:13:52 +0800 Subject: DRAFT PROPOSAL: Implementing Modified CICE and Block-Attached Calling In-Reply-To: <15e8b9d20803012100n890c536h1fa01af54cbaa811@mail.gmail.com> References: <15e8b9d20803012100n890c536h1fa01af54cbaa811@mail.gmail.com> Message-ID: My first reply was rejected for I hadn't join this mailing-list then. So only Neal got it. It is a little outdated now. There is a draft public specification currently: http://www.devtaste.com/extra/java/modified-cice-and-bami/ I wish there are some memes useful to the Java community in it. My favorite idea is "The Autonomous Block". From Richard.Sands at Sun.COM Mon Mar 17 18:54:23 2008 From: Richard.Sands at Sun.COM (Rich Sands) Date: Mon, 17 Mar 2008 21:54:23 -0400 Subject: Announcing Finalists for the OpenJDK Community Innovator's Challenge Message-ID: <47DF20CF.8030103@sun.com> OpenJDK Community, We're pleased to announce the finalists for the OpenJDK Community Innovator's Challenge. The judges have been meeting and discussing the 18 proposals received during the first phase of the Challenge, and evaluating these proposals based on their technical merit, and their likely impact on the OpenJDK Community and the adoption of OpenJDK-based implementations in new markets, for new applications and uses. It was not an easy decision, as most of the proposals were thoughtful and demonstrated passion and commitment to this code base and the community. The seven Finalists, in order of receipt of their proposals, are: Closures for Java Neal Gafter Implement XRender pipeline for Java2D Clemens Eisserer Provide date and time library from JSR-310 Stephen Colebourne, Michael Nascimento Santos Portable GUI backends Roman Kennke, Mario Torre Virtual Machine Interface Andrew John Hughes Free Software synthesizer implemention for the OpenJDK project Karl Helgason OpenJDK on Windows Ted Neward The judges, all Sun employees, are Alan Bateman, Alex Buckley, Danny Coward, Joe Darcy, Ray Gans, James Gosling, Onno Kluyt, Jim Melvin, Alex Potochkin, Phil Race, Mark Reinhold, and Rich Sands. We want to thank everyone who has entered their proposal into the Challenge. It is very exciting to see the level of enthusiasm and interest among developers for the OpenJDK code base. The finalists were chosen based on the completeness and relevance of their proposals and the degree to which the judges felt the end results were both achievable and valuable to the community at this time. Proposals that were not selected as finalists are still valuable and interesting but Sun could not select them all! The judges hope that everyone who has participated so far in the Challenge will consider continuing their efforts in the Community, and collaborating with their peers and with Sun to further the goals of the OpenJDK project. One other thing to remember -- there is no guarantee that completed Challenge projects will be integrated into the main OpenJDK code base, or into the Java SE Platform specification (which is governed by the JCP). Being chosen as a Finalist or completing a project for the Challenge might help to demonstrate the feasibility of a particular API or language proposal but it does not say anything about the likelihood of such a project becoming an approved JSR, or about the code being integrated into the main branch of the OpenJDK code base. Both the spec and the code are managed under processes that are separate from the Challenge. The finalists will be notified and project space set up for them if needed in the OpenJDK Community. As required by the Challenge rules, work must be done in the open, and the entire OpenJDK community is welcome to watch and comment as the projects progress. The Innovators Challenge will close on August 4th at which time each project will be reviewed to verify that it met the completion criteria of its proposal. Cash prizes will be awarded shortly afterwards. Thanks again to everyone who has participated. Good luck to all Finalists on your projects! Regards, -- 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 gnu_andrew at member.fsf.org Tue Mar 18 11:35:03 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 18 Mar 2008 18:35:03 +0000 Subject: Announcing Finalists for the OpenJDK Community Innovator's Challenge In-Reply-To: <47DF20CF.8030103@sun.com> References: <47DF20CF.8030103@sun.com> Message-ID: <17c6771e0803181135t6c9480bj372903b8c4c74afd@mail.gmail.com> > The finalists will be notified and project space set up for them if needed in the > OpenJDK Community. .... Sorry to be a pain, but I take it this is still a work in progress? I don't see any other mails yet. > > Regards, > > -- 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. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Thanks, -- Andrew :-) Document Freedom Day - March 26th http://documentfreedom.org Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From linuxhippy at gmail.com Tue Mar 18 12:36:35 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Tue, 18 Mar 2008 20:36:35 +0100 Subject: Announcing Finalists for the OpenJDK Community Innovator's Challenge In-Reply-To: <47DFB3FC.60501@kaffe.org> References: <47DF20CF.8030103@sun.com> <47DFB3FC.60501@kaffe.org> Message-ID: <194f62550803181236y577f69c7m500f185508a6acf0@mail.gmail.com> > Congrats to proposals that made it into the finals, and best of luck for > everyone involved for the projects. I can only second that, good luck and a lot of fun :) lg Clemens PS: By the way thanks a lot for adding Austria to the list of allowed countries :) From fabrizio.giudici at tidalwave.it Tue Mar 18 12:49:56 2008 From: fabrizio.giudici at tidalwave.it (Fabrizio Giudici) Date: Tue, 18 Mar 2008 20:49:56 +0100 Subject: Announcing Finalists for the OpenJDK Community Innovator's Challenge In-Reply-To: <194f62550803181236y577f69c7m500f185508a6acf0@mail.gmail.com> References: <47DF20CF.8030103@sun.com> <47DFB3FC.60501@kaffe.org> <194f62550803181236y577f69c7m500f185508a6acf0@mail.gmail.com> Message-ID: On Mar 18, 2008, at 20:36 , Clemens Eisserer wrote: >> Congrats to proposals that made it into the finals, and best of >> luck for >> everyone involved for the projects. > I can only second that, good luck and a lot of fun :) +1 -- 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 roman.kennke at aicas.com Tue Mar 18 13:07:06 2008 From: roman.kennke at aicas.com (Roman Kennke) Date: Tue, 18 Mar 2008 21:07:06 +0100 Subject: Announcing Finalists for the OpenJDK Community Innovator's Challenge In-Reply-To: <17c6771e0803181135t6c9480bj372903b8c4c74afd@mail.gmail.com> References: <47DF20CF.8030103@sun.com> <17c6771e0803181135t6c9480bj372903b8c4c74afd@mail.gmail.com> Message-ID: <1205870826.6162.22.camel@mercury> Hey, > > The finalists will be notified and project space set up for them if needed in the > > OpenJDK Community. > .... > > Sorry to be a pain, but I take it this is still a work in progress? I > don't see any other mails yet. Give them a short break! That must have been a lot of work to read through all the proposals and come to a decision. I'd like to say thank you for all that. And of course, good luck to all the finalists. Shouldn't be a problem to work in a private repo for one or some more days ;-) > > Regards, > > > > -- rms I always laugh my ass off when I read this! :-D Cheers, Roman -- 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 neugens.limasoftware at gmail.com Tue Mar 18 15:10:06 2008 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Tue, 18 Mar 2008 23:10:06 +0100 Subject: Announcing Finalists for the OpenJDK Community Innovator's Challenge In-Reply-To: <1205870826.6162.22.camel@mercury> References: <47DF20CF.8030103@sun.com> <17c6771e0803181135t6c9480bj372903b8c4c74afd@mail.gmail.com> <1205870826.6162.22.camel@mercury> Message-ID: <609cc3360803181510r107a0e74q59e290d59e91857f@mail.gmail.com> 2008/3/18, Roman Kennke : > Hey, > > > > > The finalists will be notified and project space set up for them if needed in the > > > OpenJDK Community. > > .... > > > > Sorry to be a pain, but I take it this is still a work in progress? I > > don't see any other mails yet. > > > Give them a short break! That must have been a lot of work to read > through all the proposals and come to a decision. I'd like to say thank > you for all that. And of course, good luck to all the finalists. > > Shouldn't be a problem to work in a private repo for one or some more > days ;-) > Hey, great news! Cheers to anyone! And good luck to who didn't make it, I think that all the projects were really great, so continue with the good work! Mario -- pgp key: http://subkeys.pgp.net/ Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/ From gnu_andrew at member.fsf.org Thu Mar 20 12:06:12 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 20 Mar 2008 19:06:12 +0000 Subject: Announcing Finalists for the OpenJDK Community Innovator's Challenge In-Reply-To: <1205870826.6162.22.camel@mercury> References: <47DF20CF.8030103@sun.com> <17c6771e0803181135t6c9480bj372903b8c4c74afd@mail.gmail.com> <1205870826.6162.22.camel@mercury> Message-ID: <17c6771e0803201206o60757ecch56d8df0a94f24dc6@mail.gmail.com> On 18/03/2008, Roman Kennke wrote: > Hey, > > > > > The finalists will be notified and project space set up for them if needed in the > > > OpenJDK Community. > > .... > > > > Sorry to be a pain, but I take it this is still a work in progress? I > > don't see any other mails yet. > > > Give them a short break! That must have been a lot of work to read > through all the proposals and come to a decision. I'd like to say thank > you for all that. And of course, good luck to all the finalists. > I am! Hence the disclaimer ;) I was more concerned some important mail had got lost en route than about immediate project access and such. That's why Mercurial (and other distributed version control systems for that matter) is so great, you can pile stuff up locally much easier. > Shouldn't be a problem to work in a private repo for one or some more > days ;-) > > > > Regards, > > > > > > -- rms > > I always laugh my ass off when I read this! :-D > Hehe, me too! > Cheers, Roman > > > -- > 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 > > -- Andrew :-) Document Freedom Day - March 26th http://documentfreedom.org Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From linuxhippy at gmail.com Wed Mar 26 03:23:31 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Wed, 26 Mar 2008 11:23:31 +0100 Subject: Has anybody received the request to execute "Affidavit of Eligibility/Liability" Message-ID: <194f62550803260323g363a1797w84e7b98bbc9f8537@mail.gmail.com> Hello, The official rules mention that the finalists will have to execute an "Affidavit of Eligibility/Liability" and if they can't be reached to do so may result in disqualification. Has anybody of the finalists already received this request, or am I just too nervous ;)? Thanks, lg Clemens From roman.kennke at aicas.com Wed Mar 26 03:43:35 2008 From: roman.kennke at aicas.com (Roman Kennke) Date: Wed, 26 Mar 2008 11:43:35 +0100 Subject: Has anybody received the request to execute "Affidavit of Eligibility/Liability" In-Reply-To: <194f62550803260323g363a1797w84e7b98bbc9f8537@mail.gmail.com> References: <194f62550803260323g363a1797w84e7b98bbc9f8537@mail.gmail.com> Message-ID: <1206528215.6515.2.camel@mercury> Hi, > The official rules mention that the finalists will have to execute an > "Affidavit of Eligibility/Liability" and if they can't be reached to > do so may result in disqualification. > > Has anybody of the finalists already received this request, or am I > just too nervous ;)? I haven't received anything either. /Roman -- 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 Wed Mar 26 05:45:51 2008 From: Richard.Sands at Sun.COM (Rich Sands) Date: Wed, 26 Mar 2008 08:45:51 -0400 Subject: Has anybody received the request to execute "Affidavit of Eligibility/Liability" In-Reply-To: <194f62550803260323g363a1797w84e7b98bbc9f8537@mail.gmail.com> References: <194f62550803260323g363a1797w84e7b98bbc9f8537@mail.gmail.com> Message-ID: <47EA457F.7020902@sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/challenge-discuss/attachments/20080326/20b1da42/attachment.html From linuxhippy at gmail.com Wed Mar 26 07:14:33 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Wed, 26 Mar 2008 15:14:33 +0100 Subject: Has anybody received the request to execute "Affidavit of Eligibility/Liability" In-Reply-To: <47EA457F.7020902@sun.com> References: <194f62550803260323g363a1797w84e7b98bbc9f8537@mail.gmail.com> <47EA457F.7020902@sun.com> Message-ID: <194f62550803260714l6fef60cdu83a295ba8263fa24@mail.gmail.com> > It is our delay - my apologies. No problem, thanks a lot for clarification. I was just afraid I could have missed it ;) Thanks , lg Clemens