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-0001.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-0001.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, E