Planet Classpath
http://planet.classpath.org/
Planet Classpath - http://planet.classpath.org/David Gilbert: JFreeChart / Bordeaux Java User Group
http://www.jroller.com/dgilbert/entry/jfreechart_bordeaux_jug_meeting
On Thursday night (January 8) I'll be making a short presentation about JFreeChart to the <a href="http://www.bordeauxjug.org/">Bordeaux Java User Group</a>. If you are in the area, register and come along.
<br /><br />
<a href="http://www.bordeauxjug.org/"><img src="http://www.object-refinery.com/images/bordeauxjug.jpg" alt="bordeauxjug.jpg" /></a>
<br /><br />
My French is nowhere near good enough (yet) so the presentation will be in English, but I'm trying to at least write the slides in French. And I'm planning to work through a live demo in code, so it doesn't really matter what language you speak, as long as it is Java!2009-01-06T14:35:17+00:00David Gilbert: JFreeChart 1.0.12
http://www.jroller.com/dgilbert/entry/jfreechart_1_0_12
A new version of <a href="http://www.jfree.org/jfreechart/">JFreeChart</a> was released on the last day of 2008, but I didn't have time to announce it until now. The sample chart below highlights a couple of features that made it into this release. First, the axes have support for minor tick marks (a long outstanding feature request that has at last been implemented). And second, despite JFreeChart having supported multiple axes and datasets since I can't remember how long ago now, it hasn't been so easy to add *duplicate* axes for a single dataset. That's been dealt with too.
<br /><br />
<img src="http://www.object-refinery.com/images/MinorTickUnitsDemo1.png" alt="MinorTickUnitsDemo1.png" />
<br /><br />
As usual the release contains a number of bug fixes and other small changes. Refer to the NEWS file and ChangeLog for details.
<br /><br />
Happy New Year to everyone!2009-01-06T14:20:10+00:00David Herron: It will be (Open)JDK7 where OpenJDK==JDK
http://weblogs.java.net/blog/robogeek/archive/2009/01/it_will_be_open.html
I'm listening to the 'holidays 2008ish' episode of Javaposse and in reviewing their last years predictions they have enough fumbling around the status of OpenJDK that I want to do a little bit of explaining. OpenJDK 6 != JDK 6...2009-01-05T22:48:05+00:00Mark Wielaard: planet.classpath.org moved
http://gnu.wildebeest.org/diary/2009/01/05/planetclasspathorg-moved/
<p><a href="http://planet.classpath.org/">planet.classpath.org</a> moved servers and if done correctly nobody will notice (except for the new server having a totally sweet favicon <img class="alignnone" src="http://planet.classpath.org/favicon.ico" alt="Tap" />). But if you do happen to notice anything odd with the planet after the move, then please do yell and scream.</p>2009-01-05T20:42:41+00:00Tom Tromey: Tampopo
http://tromey.com/blog/?p=609
<p>Elyn got me this DVD for Christmas. Aside from being a “spaghetti eastern” (har, har), it is a lovely meditation on the universal act of eating.</p>
<p>This is such an unusual film that I’ve been thinking a bit about what attracts me to it. I like the joy and the quietness of it — I like happy endings and mundane, as opposed to extreme, conflict. Also, I enjoy how very foreign it seems… I know zilch about Japan, and for all I know a truck-driving cowboy is some kind of icon there — but here he just seems bizarre. And, I like the film’s digressions from the main story, which are entertaining but not excessively distracting.</p>
<p>This is a must-see.</p>2009-01-04T23:36:32+00:00Ranjit Mathew: GCC Bootstraps
http://rmathew.blogspot.com/2005/04/gcc-bootstraps.html
As anyone working on GCC would know, GCC bootstrap times are getting worse. It is so <a href="http://gcc.gnu.org/ml/gcc/2005-04/msg01450.html">excruciating </a> on some platforms that it is nearly impossible to keep those platforms up-to-date even if people want to. Of course, many more optimisations, new languages and their ever-bloating runtimes, more comprehensive support for language standards, etc. make it inevitable that bootstrap times increase, but does it really have to increase so much?<br /><br />On my home PC, a "c,c++,java" bootstrap takes more than three hours and a complete testsuite run takes a lot of time as well. Considering that any change to the main compiler needs a complete bootstrap and testsuite run twice over (once without and once with your patch), that too in the best case of no regressions, is it small wonder that many people who might want to otherwise volunteer to help with GCC development just cannot afford to? I have only so much free time left after my job and my family and many a time I feel I am much better off reading a good book or watching a good movie, for example, than literally losing sleep over GCC. Small wonder then that almost all of the prolific contributors to GCC either work on it as a part of their job or on really fast machines with loads of memory (or both).<br /><br /><br />Perhaps it is not a good idea after all to have a single compiler codebase support so many languages and runtimes at the same time. Perhaps it would be better to start over by creating a well-defined (in terms of the structure and contract) set of language and platform-independent intermediate languages (different avatars of GENERIC and RTL) and have the front-ends and the back-ends as separate projects from the core framework. Of course, if things were this simple people would have done it already, but a man can dream, can't he?<br /><br />(<a href="http://www.advogato.org/person/rmathew/diary.html?start=80">Originally posted on Advogato</a>.)2009-01-02T20:45:32+00:00Ranjit Mathew: EXPR_WITH_FILE_LOCATION
http://rmathew.blogspot.com/2005/09/exprwithfilelocation.html
I <i>hate</i> EWFL tree nodes in GCJ. So many of the ICEs (internal compiler errors) I have seen in GCJ are because some piece of code expects or doesn't expect an EWFL node. To put it simply, the current front-end wants a WFL-wrapped expression node whenever there is a need to emit a warning or an error about that expression, but <i>not</i> otherwise.<br /><br />This can easily frustrate anyone wishing to fix some of these ICEs in the hopes of making GCJ better. For example, here I am discovering that many ICEs in the Jacks testsuite are because the body of an empty block (<tt>{}</tt>) or statement is not being wrapped in an EWFL for diagnostics about unreachable statements, finding that it is trivially fixed and <i>then</i> discovering that doing this creates a whole mess of new ICEs on other tests, which have to be individually addressed in this manner potentially creating yet other ICEs in other places, <i>ad nauseum</i>.<br /><br /><br />To quote Jeff Law (<tt>gcc/ChangeLog.tree-ssa</tt>), "Death to WFL nodes"!<br /><br /><br />(<a href="http://www.advogato.org/person/rmathew/diary.html?start=108">Originally posted on Advogato</a>.)2009-01-02T20:45:17+00:00Kelly O'Hair: Where has JVMPI gone?
http://blogs.sun.com/kto/entry/jvmpi
<p>
Have you seen this error before?
<blockquote>
<pre><tt><b>
FATAL ERROR: JVMPI, an experimental interface, is no longer supported.
Please use the supported interface: the JVM Tool Interface (JVM TI).
For information on temporary workarounds contact: jvmpi_eol@sun.com
</b></tt></pre>
</blockquote>
<p>
For a long time now, since we released JDK 1.5, we have been warning people
that the VM profiling interface JVMPI is going away.
Starting with the JDK 6 update 3 release (JDK6u3), it is gone for good.
<p>
If you really need JVMPI, your best bet is to use a JDK 1.5 or older release,
and also find out about transitioning to JVM TI.
More often than not, you have become dependent on a tool that uses JVMPI, in which
case you should try and upgrade that tool to a version that uses JVM TI instead.
But if you have written your own JVMPI code,
see the JVMPI transition article at
<a href="http://java.sun.com/developer/technicalArticles/Programming/jvmpitransition">
http://java.sun.com/developer/technicalArticles/Programming/jvmpitransition/</a>
for help in transitioning to JVM TI.
<p>
<i>
<b>NOTE:</b>
Getting this message indicates that JVMPI has been requested of the JVM.
A request for JVMPI must be made prior to JVM initialization and regardless of whether JVMPI is eventually used at runtime,
just the request for it will have a negative
performance impact on your Java application.
In most situations, JVMPI should never be requested unless some kind of
performance work is being done and slower performance is considered acceptable.
JVM TI does not have many of the JVMPI limitations.
</i>
<p>
A few references of interest:
<ul>
<li>
<a href="http://java.sun.com/j2se/1.4.2/docs/guide/jvmpi/jvmpi.html">
JVMPI: Java Virtual Machine Profiler Interface</a>
</li>
<li>
<a href="http://java.sun.com/javase/6/docs/technotes/guides/jvmti/index.html">
JVM TI: Java Virtual Machine Tool Interface</a>
</li>
<li>
<a href="http://java.sun.com/developer/technicalArticles/Programming/jvmpitransition/">
The JVMPI Transition to JVM TI</a>
</li>
<li>
<a href="http://java.sun.com/developer/technicalArticles/J2SE/jvm_ti/">
JVM TI: How Agents Work</a>
</li>
</ul>
<p>
-kto</p></p></p></p></p></p>2008-12-31T19:51:03+00:00Jeroen Frijters: IKVM 0.38 Released
http://weblog.ikvm.net/PermaLink.aspx?guid=cf993fab-fb1b-4f05-9948-fcc9fc121a17
<p>
I've <a href="http://sourceforge.net/project/showfiles.php?group_id=69637">released
IKVM 0.38</a> to SourceForge. The binaries are identical to the ones in <a href="http://weblog.ikvm.net/PermaLink.aspx?guid=288e2d5f-6568-49bf-a1b7-2a57537dcd2d">release
candidate 2</a>.
</p>
<p>
<b>Release Notes</b>
</p>
<p>
This document lists the known issues and incompatibilities.
</p>
<p>
<b>Runtime</b>
</p>
<ul>
<li>
Code unloading (aka class GC) is not supported.
</li>
<li>
In Java static initializers can deadlock, on .NET some threads can see uninitialized
state in cases where deadlock would occur on the JVM.
</li>
<li>
JNI<br /><ul><li>
Only supported in the default AppDomain.
</li><li>
Only the JNICALL calling convention is supported! (On Windows, HotSpot appears to
also support the cdecl calling convention).
</li><li>
Cannot call string contructors on already existing string instances
</li><li>
A few limitations in Invocation API support<br /><ul><li>
The Invocation API is only supported when running on .NET.
</li><li>
JNI_CreateJavaVM: init options "-verbose[:class|:gc|:jni]", "vfprintf", "exit" and
"abort" are not implemented. The JDK 1.1 version of JavaVMInitArgs isn't supported.
</li><li>
JNI_GetDefaultJavaVMInitArgs not implemented
</li><li>
JNI_GetCreatedJavaVMs only returns the JavaVM if the VM was started through JNI or
a JNI call that retrieves the JavaVM has already occurred.
</li><li>
DestroyJVM is only partially implemented (it waits until there are no more non-daemon
Java threads and then returns JNI_ERR).
</li><li>
DetachCurrentThread doesn't release monitors held by the thread.</li></ul></li><li>
Native libraries are never unloaded (because code unloading is not supported).</li></ul></li>
<li>
The JVM allows any reference type to be passed where an interface reference is expected
(and to store any reference type in an interface reference type field), on IKVM this
results in an IncompatibleClassChangeError.
</li>
<li>
monitorenter / monitorexit cannot be used on unitialized this reference.
</li>
<li>
Floating point is not fully spec compliant.
</li>
<li>
A method returning a boolean that returns an integer other than 0 or 1 behaves differently
(this also applies to byte/char/short and for method parameters).
</li>
<li>
Synchronized blocks are not async exception safe.
</li>
<li>
Ghost arrays don't throw ArrayStoreException when you store an object that doesn't
implement the ghost interface.
</li>
<li>
Class loading is more eager than on the reference VM.
</li>
<li>
Interface implementation methods are never really final (interface can be reimplemented
by .NET subclasses).
</li>
<li>
JSR-133 finalization spec change is not fully implemented. The JSR-133 changes dictate
that an object should not be finalized unless the Object constructor has run successfully,
but this isn't implemented.</li>
<li>
When a java.lang.Error (or subclass) is thrown in (and escapes) a static initializer,
the stack trace might be (partially) lost.</li>
</ul>
<p>
<b>Static Compiler (ikvmc)</b>
</p>
<ul>
<li>
Some subtle differences with ikvmc compiled code for public members inherited from
non-public base classes (so called "access stubs"). Because the access stub lives
in a derived class, when accessing a member in a base class, the derived cctor will
be run whereas java (and ikvm) only runs the base cctor.
</li>
<li>
Try blocks around base class ctor invocation result in unverifiable code (no known
compilers produce this type of code).
</li>
<li>
Try/catch blocks before base class ctor invocation result in unverifiable code (this
actually happens with the Eclipse compiler when you pass a class literal to the base
class ctor and compile with -target 1.4).
</li>
<li>
Only code compiled in a single assembly fully obeys the JLS binary compatibility rules.
</li>
<li>
An assembly can only contain one resource with a particular name.
</li>
<li>
Passing incorrect command line options to ikvmc may result in an exception rather
than a proper error messages.</li>
<li>
Under specific circumstances ikvmc may die with an exception if you're compiling code
that references missing classes. As a workaround, supply the missing classes (may
be stubs).</li>
<li>
Under specific circumstances ikvmc may produce unverifiable code if you're compiling
code that references missing classes. As a workaround, supply the missing classes
(may be stubs).</li>
</ul>
<p>
<b>Class Library</b>
</p>
<p>
Most class library code is based on OpenJDK 6 build 12. Below is a list of divergences
and IKVM specific implementation notes.
</p>
<table cellspacing="0">
<tbody>
<tr>
<td>
com.sun.security.auth.module
</td>
<td>
Not implemented.</td>
</tr>
<tr>
<td>
java.applet</td>
<td>
GNU Classpath implementation. Not implemented.</td>
</tr>
<tr>
<td>
java.awt</td>
<td>
GNU Classpath implementation with partial System.Windows.Forms based back-end. Not
supported.</td>
</tr>
<tr>
<td>
java.io.Console</td>
<td>
Not implemented.</td>
</tr>
<tr>
<td>
java.lang.instrument</td>
<td>
Not implemented.</td>
</tr>
<tr>
<td>
java.lang.management</td>
<td>
Not implemented.</td>
</tr>
<tr>
<td>
java.net</td>
<td>
No IPv6 support implemented.</td>
</tr>
<tr>
<td>
java.net.ProxySelector</td>
<td>
Getting the default system proxy for a URL is not implemented.</td>
</tr>
<tr>
<td>
java.text.Bidi</td>
<td>
GNU Classpath implementation. Not supported.</td>
</tr>
<tr>
<td>
java.util.zip</td>
<td>
Partially based on GNU Classpath implementation.</td>
</tr>
<tr>
<td>
javax.imageio.plugins.jpeg</td>
<td>
Not implemented.</td>
</tr>
<tr>
<td>
javax.management</td>
<td>
Not implemented.</td>
</tr>
<tr>
<td>
javax.print</td>
<td>
Not implemented.</td>
</tr>
<tr>
<td>
javax.script</td>
<td>
Not implemented.</td>
</tr>
<tr>
<td>
javax.smartcardio</td>
<td>
Not implemented.</td>
</tr>
<tr>
<td>
javax.sound</td>
<td>
Not implemented.</td>
</tr>
<tr>
<td>
javax.swing</td>
<td>
GNU Classpath implementation. Not supported.</td>
</tr>
<tr>
<td>
javax.tools</td>
<td>
Not implemented.</td>
</tr>
<tr>
<td>
org.ietfs.jgss</td>
<td>
Not implemented.</td>
</tr>
<tr>
<td>
sun.jdbc.odbc</td>
<td>
Not implemented.</td>
</tr>
<tr>
<td>
sun.net.www.content.audio</td>
<td>
Audio content handlers not implemented.</td>
</tr>
<tr>
<td>
sun.net.www.content.image</td>
<td>
Image content handlers not implemented.</td>
</tr>
</tbody>
</table>
<p>
The entire public API is available, so "Not implemented." for javax.print, for example,
means that the API is there but there is no back-end to provide the actual printing
support. "Not supported." means that the code is there and probably works at least
somewhat, but that I'm less likely to fix bugs reported in these areas.
</p>
<p>
Specific API notes:
</p>
<ul>
<li>
java.lang.Thread.stop(Throwable t) doesn't support throwing arbitrary exceptions on
other threads (only java.lang.ThreadDeath).
</li>
<li>
java.lang.Thread.holdsLock(Object o) causes a spurious notify on the object (this
is allowed by the J2SE 5.0 spec).
</li>
<li>
java.lang.String.intern() strings are never garbage collected.
</li>
<li>
Weak/soft references and reference queues are inefficient and do not fully implement
the required semantics.
</li>
<li>
java.lang.ref.SoftReference: Soft references are not guaranteed to be cleared before
an OutOfMemoryError is thrown.
</li>
<li>
Threads started outside of Java aren't "visible" (e.g. in ThreadGroup.enumerate())
until they first call Thread.currentThread().
</li>
<li>
java.lang.Thread.getState() returns WAITING or TIMED_WAITING instead of BLOCKING when
we're inside Object.wait() and blocking to re-acquire the monitor.
</li>
<li>
java.nio.channel.FileChannel.lock() shared locks are only supported on Windows NT
derived operating systems.
</li>
<li>
java.lang.SecurityManager: Deprecated methods not implemented: classDepth(String),
inClass(String), classLoaderDepth(), currentLoadedClass(), currentClassLoader(), inClassLoader()</li>
</ul>
<p>
<b>Supported Platforms</b>
</p>
<p>
This release has been tested on the following CLI implementations / platforms:
</p>
<table border="0">
<tbody>
<tr>
<td>
<b>CLI Implementation </b>
</td>
<td>
<b>Architecture </b>
</td>
<td>
<b>Operating System</b>
</td>
</tr>
<tr>
<td>
.NET 2.0 SP2</td>
<td>
x86</td>
<td>
Windows</td>
</tr>
<tr>
<td>
.NET 2.0 SP2</td>
<td>
x64</td>
<td>
Windows</td>
</tr>
</tbody>
</table>
<p>
<br />
<b>Partial Trust</b>
</p>
<p>
There is experimental support for running in partial trust.<br />
</p>
<img width="0" height="0" src="http://weblog.ikvm.net/aggbug.ashx?id=cf993fab-fb1b-4f05-9948-fcc9fc121a17" />2008-12-29T07:46:52+00:00Mario Torre: Happy new everything!
http://www.jroller.com/neugens/entry/happy_new_everything
<p>It‘s quite some time I am missing and have not update the blog. The reasons are quite obvious: heavy work load (had to port Jogl on an OpenGL capable VxWorks machine… quite challenging, but the Caciocavallo project helped me quite a lot, will post some details and screenshots when I am back), and now I am on holiday, in the beautiful and hot south Italy, without acess to the Internet or any <span class="caps">PC </span>(yahi, for 20 days!)...</p>
<p>It‘s so incredible for me to go out at night at 1 a.m. and still find people around… And no need of super warm clothes!!! Drinking beer on the promenade, staring at the moonlight shadow on the sea… oh, I feel alive again finally!</p>
<p>Ok, I could find a pc to write this little blog post, after all I am a geek, but at least I cannot program here (first, it‘s a windows machine, so by definition no one can ever program on this crap, second, I don‘t have a Linux <span class="caps">DVD</span> at hand, so I cannot fix the software, it‘s already a miracle I managed to write this stuff, btw).</p>
<p>I am spending some time with my family and going around doing photos, eating food, drinking wine… Meeting people…</p>
<p>In the idle evenings, I‘m trying to learn about the beautiful <span class="caps">CELL</span> processor and the Playstation 3 (yes, for gaming, but also for programming, and no, it‘s just because I like it, no official work/projects… yet). I really like its design, the idea of having a bunch of Synergetic Processing Elements (SPE, 8 on the “standard“ version, 6 + 1 on the <span class="caps">PS3</span>) controlled by a Power Processing Element.</p>
<p>While this makes programming quite difficult, the power unleashed is worthy of the strongest Jedi masters around. “Sadly“ the <span class="caps">GPU</span> on the <span class="caps">PS3</span> is “only” a <span class="caps">G70</span>, this means that, as far as I know, on this processor there is no <span class="caps">CUDA</span> support, but it‘s <a href="http://developer.nvidia.com/object/physx.html">PhysX</a> capable, quite important as I really think PhysX has been tuned for use on the <span class="caps">CELL</span> as well as the <span class="caps">G70</span>. Ok, the <span class="caps">CELL</span> already provides much of the funtionality that you can obtain via <span class="caps">CUDA</span>/OpenCL, so perhaps is not so important anyway. I can‘t wait to have one to start some hacking!!</p>
<p>What should go with the bundle? Probably Little Big Planet, Mirror‘s Edge, Dead Space, and, of course, The Force Unleashed. Feel free to google for them :)</p>
<p>Ok, time to eat some <a href="http://en.wikipedia.org/wiki/Pandoro">pandoro</a>, so better to rush. I wish you all a very great new year!</p>2008-12-28T13:10:07+00:00Jeroen Frijters: New Development Snapshot
http://weblog.ikvm.net/PermaLink.aspx?guid=885c4705-5032-4f03-be85-0b3fd3c01176
<p>
I've checked in all the changes required to split the class library into ten different
assemblies. So here is the first snapshot that contains the split binaries.
</p>
<p>
This means that the -sharedclassloader ikvmc option has been implemented, but it isn't
ready for prime time yet, for now I've only focussed on getting the core class library
to build with it.
</p>
<p>
Changes:
</p>
<ul>
<li>
Split IKVM.OpenJDK.ClassLibrary.dll into ten parts.</li>
<li>
Added -sharedclassloader option to ikvmc.</li>
<li>
Removed some GNU Classpath build leftovers.</li>
<li>
Removed workaround for com.sun.beans.ObjectHandler.classForName2() that hopefully
isn't necessary any more.</li>
<li>
Made ikvmc emit a warning whenever it emits code that throws a hard error.</li>
<li>
Fixed ikvmc to detect access to members in another assembly that expose non-public
types from that assembly (the CLR doesn't allow this) and generate java.lang.IllegalAccessError
(plus warning during compilation) instead of producing invalid code.</li>
<li>
Volker Berlin checked in his first set of changes to replace java.awt.image.BufferedImage
with the OpenJDK version.</li>
</ul>
<p>
As always with a development snapshot, don't use this in production, but please do
try it out and let me know about it. The sources are available in cvs and the binaries
here: <a href="http://www.frijters.net/ikvmbin-0.39.3280.zip">ikvmbin-0.39.3280.zip</a></p>
<img width="0" height="0" src="http://weblog.ikvm.net/aggbug.ashx?id=885c4705-5032-4f03-be85-0b3fd3c01176" />2008-12-24T06:14:18+00:00Joe Darcy: Criteria for desirable small language changes
http://blogs.sun.com/darcy/entry/criteria_for_desirable_small_language
<p>
The two primary goals of making small language changes in JDK 7 is to:</p>
<ol>
<li><p> Make the things programmers do everyday easier.
</p>
<li><p> Support other platform changes in JDK 7.
</p>
</li></li></ol>
<p>
Over the years, certain common coding patterns have been recognized as needlessly verbose including:
</p>
<ul>
<li><p>if-equals-X-else-if-equals-Y testing chains on strings</p>
<li><p>duplicated catch blocks for different exception types</p>
<li><p>repeated type parameters when declaring and initializing a variable of parameterized type</p>
</li></li></li></ul>
<p>
These patterns can be replaced with new constructs that are more concise and more clear without fundamentally altering the language. Besides improvements to support existing Java programs, language changes should also be made to allow appropriate access to new JVM capabilities, such as those being enabled by the <a href="http://openjdk.java.net/projects/mlvm/">Da Vinci Machine project</a>.
</p>
<p>
While language changes can fundamentally improve the modes of expression in a language, language changes have a number of drawbacks as solutions to programming problems:
</p>
<ul>
<li><p><b>Slow availability:</b> Language changes occur in platform releases, which typically only occur every few years.</p>
<li><p><b> Heavyweight:</b> The full extent of a language changes can affect <a href="http://blogs.sun.com/darcy/entry/so_you_want_to_change">multiple components of the platform</a>.</p>
<li><p><b> Changes may be needed at multiple points in the toolchain:</b> Even after a language change is fully available in the JDK, independent libraries and tools may need to be updated as well before the changes can be fully utilized.</p>
</li></li></li></ul>
<p>
Therefore, language changes are rarely the preferred solution if other workable solutions are available. Since IDEs are now commonly used for Java development, mitigating or solving problems using IDE tooling is one possibility. As of Java SE 6, compliant compilers are required to support annotation processing as standardized by <a href="http://jcp.org/en/jsr/detail?id=269">JSR 269</a>, see
<a href="http://java.sun.com/javase/6/docs/api/javax/annotation/processing/package-summary.html"><tt>javax.annotation.processing</tt></a>
and
<a href="http://java.sun.com/javase/6/docs/api/javax/lang/model/package-summary.html"><tt>javax.lang.model</tt></a>.
Annotation processing provides a general meta-programming framework; beyond processing annotations directly, annotation processors can be used to implement many currently extra-lingual checks based on a program's structure. Checks which previously would have required language changes can now be implemented by developers and just used by convention.
<a href="http://groups.csail.mit.edu/pag/jsr308/">JSR 308</a>, Annotations on Java Types, would enable more detailed checking by allowing annotations in more program locations.
</p>
<p>
When judging whether or not any change to the platform is worthwhile, a useful notion is estimating the feature's "thrust to weight ratio," that is estimating whether the benefits of making the change exceed the full cost of implementing the change. For language changes, this metric is improved by having a larger fraction of programs potentially benefiting from the change. For example, it would be roughly the same amount of engineering to add numerical operator overloading support for classes like <tt>BigInteger</tt> and <tt>BigDecimal</tt> as to add support for bracket, "<tt>[]</tt>", syntax for Lists and Maps. Besides complications with the <tt>==</tt> operator in the numerical case, bracket syntax for Maps and Lists has much higher utility since many more Java programs use Collections than large numbers.
</p>
<p>
Especially with the maturity of the Java platform, the onus is on the proposer to convince that a language change should go in; the onus is <em>not</em> to prove the change should stay out.
</p>
<p>
Given the upcoming holidays, the language change proposal form and the seeding proposals will both be coming in January 2009.
</p>2008-12-23T17:00:00+00:00Gary Benson: Super-dirty jtreg hacking
http://gbenson.net/?p=110
<p>Today I made my <a href="http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-December/000955.html">second official patch</a> to OpenJDK. I forgot how to make the <a href="http://openjdk.java.net/jtreg/">jtreg</a> test and had to figure it out all over again, so here’s my quick and dirty guide for the future:</p>
<ol>
<li>Build jtreg. I use the IcedTea one, because it’s there:
<pre>make jtreg</pre>
</li>
<li>Make a test root and copy your test into it:
<pre>mkdir -p tests/tests
touch tests/TEST.ROOT
mv ~/Test6779290.java tests/tests
</pre>
</li>
<li>Run the tests:
<pre>openjdk-ecj/control/build/linux-ppc/j2sdk-image/jre/bin/java -jar test/jtreg.jar -v1 -s tests</pre>
</li>
</ol>
<p>In other news it’s over a year since I started <a href="http://gbenson.net/?p=46">hacking on Zero</a>. I was hoping to be able to announce a TCK-passing build before Christmas but that’s not going to happen. Oh well.</p>2008-12-23T11:18:55+00:00Robert Schuster: Comments on latest post on OpenJDK
http://rschuster.blogs.evolvis.org/2008/12/23/comments-on-latest-post-on-openjdk/
<p>Hi,</p>
<p>there have been interesting questions in the comments sections of my last post. I take the time to answer them here:</p>
<p>Mark Wielaard asked: <strong>Finally, do you have any speed comparisons of the hotspot/zero and cacao on arm ?</strong></p>
<p>Unfortunately not. Subjective it feels as if the SwingSet2 demo runs better with Cacao. The Freerunner and its software are also not in a good shape to make performance tests. Even native C applications show unacceptable slow behavior.</p>
<p>Xerxes Rånby said: <strong>Your combined effort have provided the key to unlock the possibility to run OpenJDK on all embedded Linux NAS storage devices, home routers and more <img src="https://rschuster.blogs.evolvis.org/wp-includes/images/smilies/icon_smile.gif" alt=")" /></strong></p>
<p>Indeed and I very much welcome people to try compiling the recipes for their MIPS devices as well. I also wonder if OpenJDK can be compiled against uClibc and uClibc++. If that is the case then we can also have OpenJDK+Hotspot/Zero on AVR32 (though a few more patches to the build system will be needed for this). <strong><img src="https://rschuster.blogs.evolvis.org/wp-includes/images/smilies/icon_smile.gif" alt=")" /></strong></p>
<p>Andrew John Hughes wrote: <strong>What version of IcedTea did you use? I think some issues have changed/been fixed. Certainly –with-openjdk-src-dir isn’t broken any more <img src="https://rschuster.blogs.evolvis.org/wp-includes/images/smilies/icon_smile.gif" alt=")" /></strong></p>
<p>I used the latest from the stable release: 1.3.1. Good to hear that some issues are already fixed. I am looking forward to integrate some patches after Xmas.</p>
<p>Eric Herman wrote: <strong>My sense is that Java is not truly Free if I can not bootstrap it from C, and I was of the impression that I still needed a working Java in order to build Java. I look forward to learning more about the excellent work you’ve been doing.</strong></p>
<p>Actually with OpenEmbedded this is the case: OpenJDK is bootstrapped without the need for a pre-installed Java runtime. What I left out in my explanation is that all of this builds on top of my <a href="http://rschuster.blogs.evolvis.org/2007/11/28/jalimo-progress-piecing-together-the-gems/">previous</a> work on a completely self-hosting Java^H^H^H^HJava-like toolchain based on GNU Classpath, JamVM/Cacao, ECJ and eventually Jikes. I have written down the gory details of this in the <a href="http://wiki.openembedded.net/index.php/Java">OE wiki </a> to make it possible that anyone can pick up my work enhance it or re-use it in another build environment.</p>
<p>Finally Wladimir Mutul asked: <strong>Why not use Scratchbox(.org) for your cross-compilation ?</strong></p>
<p>Before starting with OpenEmbedded Jalimo was only targeting the Nokia Internet tablets and as such we build our stuff with Scratchbox. First of all: I really like the Debian-way of packaging things (all of the Java related recipes in OE resemble Debian conventions for instance). However three points were most important when deciding to leave the Scratchbox path:</p>
<ul>
<li> At the time we worked with SB it was not possible to either get JamVM or Cacao working reliably inside SB. So we had to use Jikes as a Java compiler. GNU Classpath adopting Java 1.5 syntax would have made it neccessary to use ECJ instead which needs a Java runtime.</li>
<li>OpenMoko appeared on the scene and we wanted to provide binaries for this platform. Additionally we had an Irex Iliad (an Ebook reader) and wanted to support it, too. OpenEmbedded built for those out of the box and it turned out that with little work OE could be modified to support Maemo as well.</li>
<li>Last but not least with SB a lot of manual work was involved when integrating a new patch or updating to a new version. With OE it is a matter of renaming a recipe and checking which patches are still needed. Gentoo packagers do it in the same way.</li>
</ul>
<p>It should go without saying that I miss things that would be available by basing everything on Debian. E.g. source packages, direct support for Ant builds, many many tried and tested packages and of course GCJ. Furthermore it isn’t all bright and shiny with OE either. For instance the project is an extremelyfast moving target. People add new stuff to it everyday. Some things have effects on your recipes and may cause build problems. However this is why projects like Poky exists which make stable release on top of OE snapshots.</p>
<p>I hope my explanations cleared things up a bit.</p>
<p>Happy holidays!</p>2008-12-23T10:00:44+00:00Kelly O'Hair: Bees
http://blogs.sun.com/kto/entry/bees
<p>
I was working in my yard trimming bushes when I heard a buzzing sound.
At first I thought maybe one of the automatic valves had gone haywire,
so I opened up the box that had the valves in it, and ran back into the house
as hundreds of bees started flying around me.
Later I went back and took a few pictures.<br />
<center>
<img width="512" />
</center>
<p>
You can see where I dropped the clippers.
This happened a while back but I just recently found the images on my camera
while doing my pool pump blog. Here is a close up of the hive:<br />
<center>
<img width="512" />
</center>
<p>
Underneath the bees are two pancake sized honeycombs, which I saw as I ran into
the house, but wasn't able to get pictures before the bees all came back.
<p>
I was at a loss as to what to do with the bees, I didn't want to kill them.
Eventually we found a local bee person who gladly came to get them and we
donated $50 to his 'save the bees' fund.
They are called feral bees, and we were told that there is probably a larger
hive somewhere close, and these was a new hive from that split from the larger hive.
<a href="http://en.wikipedia.org/wiki/Colony_Collapse_Disorder">
The Bees are disappearing</a> and we were glad we managed to save these.
The bee person almost talked me into creating my own bee hive as a hobby,
seems like it would be an interesting hobby.
<p>
-kto</p></p></p></p></p>2008-12-23T00:31:36+00:00Kelly O'Hair: Energy Saving Pool Pump
http://blogs.sun.com/kto/entry/energy_saving_pool_pump
<p>
This really is about pool pumps, not Java. ;^)
<p>
Almost 10 years ago we upgraded to a new house and when planning out the landscaping,
we decided on a pool. I'd never owned a pool before and had no idea what I was getting
into. Growing up in Southern California, a great deal of my childhood summers
were spent in the local city pool.
The thought of having my own pool seemed like a cool idea, and it is great to have,
and it looks really cool:<br />
<center>
<img width="512" src="http://blogs.sun.com/kto/resource/Pool.jpg" />
</center>
<p>
But... pools do not come cheap.
One expense is the pool service, which runs me over $130 per month.
As an expense compromise, we decided to do our own the yard work, but
pay to have the pool taken care of.
<p>
Anyway, more to the point of this blog.
Pools use pumps, electric pumps, to circulate and filter the water.
Depending on your electric rates, the cost of running these pumps can easily
run thousands of dollars a year. In my area of California, the cost of electricity
is priced in 5 tiers, the highest 5th tier is twice the lowest or baseline tier.
Larger homes are pretty much guaranteed to enter the 3rd tier, many get into the
4th and 5th, and the pool pump alone could cost people $4,000 per year.
And this cost includes cutting back the time the pump runs in the winter, these
pool pumps use lots of electricity.
<p>
So about 9 months ago, a loud screeching out by the pool equipment area
announced that our pool pump had lost a bearing and managed to destroy itself
enough that it needed to be replaced.
Just replacing the pump was going to be over $500, but having been given some
variable speed pump information recently from Allan Freeman at
Alliance Solar.
I decided to wait and investigate.
Luckily we have two pool pumps, one for the waterfalls and one for the
pool filtering, so we had the pool people swap the pumps,
temporarily giving up using the waterfalls (not a big deal).
This bought us some time.
<p>
Then recently Allan contacted me with an estimate to install a variable
speed pool pump including the interface to the pool automation system.
His estimate also included a predicted electricity savings of
somewhere between $700 to $1500 per year!
These variable speed pool pumps can potentially pay for
themselves in roughly 2 years.
So we went for it. Go green! ;^)
<p>
The new interface box is on the left of the pool control box,
and the new variable speed pump is the left pump, the right one is the
pump for the waterfall.
The interface box is what somehow maps the pump settings to the
older pool control system settings, different speeds are needed for different
pumping situations.<br />
<center>
<img width="200" src="http://blogs.sun.com/kto/resource/PumpBox.jpg" />
<img width="200" src="http://blogs.sun.com/kto/resource/Pumps.jpg" />
<img width="200" src="http://blogs.sun.com/kto/resource/Pump.jpg" />
</center>
<p>
Basically the old pump was drawing 9amps, all the time. The new pump will draw
anywhere from .7amps to 5amps at the highest speed setting.
The really big savings comes from the fact that the
basic pool filtering action can use the
lower if not lowest pump speeds, and the basic pool filtering is probably 80%
of the pump's usage. What a deal!
<p>
So if you have a pool, and you want to save on your electric bill, before you
go buy solar electric panels, investigate these new variable speed pool pumps.
Dollar for dollar, these new pumps could pay for themselves well before
solar electric panels could.
<p>
Just to note, we have had solar electric and solar pool water panels for many
years:<br />
<center>
<img width="300" />
<img width="300" />
</center>
<p>
The panels on the right are only used in the summer, heating the pool water,
we had those installed probably 8 years ago.
The panels on the left are solar electric panels we have had for 4 years or so.
The goal on the solar electric panels was to get us out of the more expensive
4th and 5th tiers of the electricity rates, which they have done, and they
save us maybe $150 a month, but the system cost close to $8,000 after all the
rebates and tax credits
(the rebates/credits change from year to year, so investigate this carefully before you buy anything).
The panels send DC electricity to the Sunny Boy converted in the garage:<br />
<center>
<img width="300" />
</center>
<p>
The AC electricity is mostly consumed but if there is excess, it spins the electric
meter backwards (no batteries on ours),
kind of giving us a credit or in a sense using PG&E (the elctric company)
as our battery. We generate far less
than we consume, but that was the plan when it was installed, to generate the
electricity we would have paid a premium for.
Of course, that's why our new pool pump won't save us as much as a neighbor
who doesn't have solar electric panels.
Still, it saves us money, but it takes much longer
to get your money back from a solar electric system.
Don't get me wrong, I'm glad we did it, but people need to understand that
these systems do cost quite a bit to have installed.
First, go for the variable speed pool pump, well, assuming you have a pool.
Then look into solar electric panels.
<p>
Allan Freeman and his excellent professional crew from Alliance Solar Services in
Alameda installed all our solar panels and the new
variable speed pump. They can be reached at (510)-523-2833 and I HIGHLY recommend
them.
<p>
-kto</p></p></p></p></p></p></p></p></p></p></p></p></p></p>2008-12-22T23:07:33+00:00Robert Schuster: Serving cross-compiled OpenJDK with IcedTea
http://rschuster.blogs.evolvis.org/2008/12/21/serving-cross-compiled-openjdk-with-icedtea/
<p>As <a href="http://community.buglabs.net/kgilmer/posts/45-BUG-OpenJDK">Ken</a> and <a href="http://smancke.blogs.evolvis.org/2008/12/20/integrating-the-openjdk-into-jalimo/">Sebastian</a> have already announced it OpenJDK integration into Jalimo was finished. However there was a bit of work to do to not only compile OpenJDK but to also package it nicely. This work is now also completed.</p>
<p>Additionally - and this was not told anywhere else yet - we can now also offer Cacao+OpenJDK. So anyone who is in need of a decent JIT for its target platform can now build this combination, too.</p>
<p>Those who do not know OpenEmbedded may wonder what is so special about the work I have done in the last weeks. Well, the special thing is that we are cross-compiling the OpenJDK. That means the machine on which the JDK is built is of a different kind than the one on which we want to run it later on. The difficulty stems from the fact that the OpenJDK build system is not designed for this (in contrast to the one used by PhoneME btw).</p>
<p>Before I will tell you about the guts of cross-compiling OpenJDK lets enjoy some screenshots:</p>
<p><a href="http://rschuster.blogs.evolvis.org/files/2008/12/9-jtuner.png" title="Direct link to file"><img src="http://rschuster.blogs.evolvis.org/files/2008/12/9-jtuner.thumbnail.png" alt="jtuner" height="128" width="96" /></a><a href="http://rschuster.blogs.evolvis.org/files/2008/12/8-metalworks.png" title="metalworks"><img src="http://rschuster.blogs.evolvis.org/files/2008/12/8-metalworks.thumbnail.png" alt="metalworks" /></a><a href="http://rschuster.blogs.evolvis.org/files/2008/12/7-fontdemo.png" title="fontdemo"> <img src="http://rschuster.blogs.evolvis.org/files/2008/12/7-fontdemo.thumbnail.png" alt="fontdemo" /></a><a href="http://rschuster.blogs.evolvis.org/files/2008/12/6-netx-warning.png" title="netx - warning"> <img src="http://rschuster.blogs.evolvis.org/files/2008/12/6-netx-warning.thumbnail.png" alt="netx - warning" /></a><a href="http://rschuster.blogs.evolvis.org/files/2008/12/5-netx.png" title="netx - about"><img src="http://rschuster.blogs.evolvis.org/files/2008/12/5-netx.thumbnail.png" alt="netx - about" /></a><a href="http://rschuster.blogs.evolvis.org/files/2008/12/3-netx-jdiskreport.png" title="jdiskreport"><img src="http://rschuster.blogs.evolvis.org/files/2008/12/3-netx-jdiskreport.thumbnail.png" alt="jdiskreport" /></a><a href="http://rschuster.blogs.evolvis.org/files/2008/12/1-swingset2.png" title="swingset2 (openjdk at freerunner)"><img src="http://rschuster.blogs.evolvis.org/files/2008/12/1-swingset2.thumbnail.png" alt="swingset2 (openjdk at freerunner)" /></a></p>
<p>People may have seen these apps on their desktops and as such they are not very exciting. However for me they have a special meaning: As a contributor to GNU Classpath it was always my wish to be able to run any Java (=J2SE) program on any device running a Free operating system. I was contributing to the Free Swing implementation and together with the enormous work done by Roman, Thomas, Lillian and many others we were able to run a few Swing and AWT programs. Still performance, completeness and correctness of our implementation where limited in many places and would require more years of dedicated effort. Thanks to Sun releasing Java as free software and the important work done by the IcedTea team we can now have the real thing on our devices and suddenly get 100% compatibility. <img src="http://rschuster.blogs.evolvis.org/wp-includes/images/smilies/icon_smile.gif" alt=":-)" class="wp-smiley" /> </p>
<p>Now on to the cross-compilation guts:</p>
<p>First of all compared to the work that would have been required with plain OpenJDK IcedTea made the effort of cross-compiling the thing a breeze. The best thing that IcedTea provides is the ability to use a GNU Classpath-based toolchain to build OpenJDK. On the major distros GCJ is used as a runtime and ECJ as the bootstrap Java compiler. In OpenEmbedded we have JamVM, Cacao and plain GNU Classpath as runtime options which work equally well. JamVM does not understand some of the “-X”options so I had to patch their use away.</p>
<p>Although IcedTea is a nice environment I had to patch a few things to get things started. E.g. IcedTea requires you to point to a GCJ home directory. It will then create symlinks to libraries and headers files contained within them. The problems with IcedTea are: When cross-compiling the libraries provided by your system’s GCJ do not make sense for your target (e.g. your system GCJ has AMD64 binaries while your target requires those for ARM). Secondly in a cross-compilation environment like OpenEmbedded you do not want to rely on stuff outside the environment. As such I had to modify this behavior to link to header files (jni.h and likes) which are provided by the OE-built GNU Classpath.</p>
<p>There where other problems like IcedTea not respecting the –with-openjdk-src-dir option. It will still try to download the OpenJDK sources itself (which is not allowed in OE, because this is done through the environment).</p>
<p>All in all I collected my changes in patches which I called ‘build hacks’. I consider these hacks fixable and will work together with the IcedTeam team to resolve those for future releases in order to make cross-compiling OpenJDK even easier in the future.</p>
<p>Besides IcedTea I had to patch OpenJDK itself to get things compiled properly. The first thing that causes trouble is that you cannot chose the compiler being used. OpenJDK contains some complicated makefiles that check your system environment and then decide which compiler to use. I used good old sed to replace the respective part of the makefile. I believe this behavior can be added to IcedTea without causing any harm to the other IcedTea users.</p>
<p>The next problem is the sanitizing step. This one will compile a few binaries (for the target platform!), run them (impossible) and decide on their output whether the build can continue. These checks are done for CUPS and Alsa. The fix is to patch them away. I think an optional –disable-sanity-checks would be OK for IcedTea.</p>
<p>The final big problem with OpenJDK’s build system is that it uses the result of ‘uname -m’ for its decision. This is troublesome because ‘uname -m’ will only tell you the architecture of your build machine not the target one. I solved this by replacing all these calls with a variable and allowed IcedTea’s makefile to provide a value for this.</p>
<p>The remaining issues where minor: Some unsuitable paths here, a sizer.32 binary that I had to take from a previous non-cross build there.</p>
<p>Apropos non-cross build. This was the really ambitious undertaking. But before I explain this here are some cross-compilation basics that I learned in the years contributing to OpenEmbedded:</p>
<p>Non-cross compilation aware projects are troublesome when they create binaries whose output is going to be used directly in the build. The general approach to this problem is that you first compile this particular binary for your build system and use it in the cross-build. In OpenEmbedded this will often result in a separate build recipe. If your project is cross-compilation aware it will allow you to specify the location of such binaries. E.g. Cacao 0.99.x has the –with-cacaoh option to point to the location of the non-cross-compiled header generator. In non-cross-compilation aware projects you need to patch the makefiles accordingly.</p>
<p>The IcedTea build normally consists of two builds of the JDK. The first one creates a bootstrap JDK. This one is heavily patched, stripped down and can be build using GNU Classpath-based software. In the second step the bootstrap JDK’s java, javac and a few other binaries are run to build the final JDK. For our cross-compilation effort this means we need to get this bootstrap JDK built for the build machine and as said above this is where things get troublesome.</p>
<p>The reason for this is that OpenJDK depends on a few libraries like CUPS, Alsa, libjpeg and giflib which I either had to provide in their native (= for the build system) form or patch their use away. Remember that I cannot just take e.g. Debian’s libcupsys-dev because that would be outside the OpenEmbedded build environment (and would make people unhappy who use OE on a different distro).</p>
<p>I decided to go the way of patching the bootstrap JDK build since printing and sound would not be needed for bootstrap purposes anyway. Originally I also disabled most of the AWT (and as such the libxt, xproto dependencies). However it turned out that at one point the OpenJDK build converts a bunch of GIF pictures into Java byte array source code using javax.imageio which requires the headless variant of the AWT.</p>
<p>A few lines above I told you that the bootstrap JDK is compiled separately for the build machine. In a simple project we could now skip this part from the cross-compilation build. However the bootstrap JDK build also creates libraries (for the target machine) to which the final JDK links against. That is why we cannot skip this part.</p>
<p>So cross-compiling OpenJDK consists of the major steps:</p>
<ul>
<li>build a GNU Classpath-based toolchain (gjar, gjavah), ECJ and Ant</li>
<li>build the bootstrap JDK for the build machine (’make icedtea-against-ecj’)</li>
<li>build the bootstrap JDK for the target machine</li>
<li>replace the binaries in bootstrap/icedtea/bin with those of your native boostrap JDK</li>
<li>build the final JDK</li>
</ul>
<p>and as I have written in the first part of this posting: You need to patch everything heavily to get some problems out of the way which stem from the fact that OpenJDK is not cross-compilation aware.</p>
<p>Finally a screenshot showing Cacao+OpenJDK:</p>
<p><a href="http://rschuster.blogs.evolvis.org/files/2008/12/2-cacao-openjdk.png" title="Direct link to file"><img src="http://rschuster.blogs.evolvis.org/files/2008/12/2-cacao-openjdk.thumbnail.png" alt="cacao + openjdk" height="128" width="96" /></a></p>
<p>The next step will be integrating Hotspot-Shark into OpenEmbedded and of course getting as many of my patches upstream as possible.</p>
<p>Compared to GNU Classpath + Cacao/JamVM the OpenJDK packages are ~6 times larger. I am curious to see how the modularization efforts of Java7 works out. With the work done now it will be much easier to follow those developments. <img src="http://rschuster.blogs.evolvis.org/wp-includes/images/smilies/icon_smile.gif" alt=":-)" class="wp-smiley" /> </p>
<p>Edit: Fixed images links.</p>2008-12-21T16:05:36+00:00Andrew Cowie: Positive Y
http://research.operationaldynamics.com/blogs/andrew/software/java-gnome/cairo-arcs.html
<p>The excellent <a href="http://www.cairographics.org/">Cairo</a> graphics library has a simple function to draw arcs; in C it’s <code>cairo_arc()</code>; from java-gnome it’s Context’s <code>arc()</code> method, etc.</p>
<p>Quite unsurprisingly they define increasing angles as going from the positive <em>x</em> axis on toward the positive <em>y</em> axis. Nothing unusual about that. The only thing that was surprising is that they even mention this in their documentation.</p>
<p>I should know better.</p>
<p>What I totally missed was the <em>implication</em> of this. I didn’t quite clue in that the positive <em>y</em> direction in screen positioning and page drawing is <strong>down</strong>, and so increasing angles go <strong>clockwise</strong>. Using <code>cr.arc()</code> to go from <code>0</code> to say <span>π</span>/3 radians does <em>not</em> give a rise of 60° like I expected; it gives this:</p>
<p><img src="http://java-gnome.sourceforge.net/4.0/doc/api/org/freedesktop/cairo/Context-arc.png" alt="cairo arc positive" title="" /></p>
<p>Whoa. This is not the counter-clockwise increasing <span>θ</span> like we’re all used to seeing in normal Cartesian or Polar co-ordinates. But it <em>is</em> indeed increasing toward the positive <em>y</em> axis. Oops. Oh well <code>:)</code></p>
<p>So I made this illustration and added it to the documentation for Context’s <a href="http://java-gnome.sourceforge.net/4.0/doc/api/org/freedesktop/cairo/Context.html#arc(double,%20double,%20double,%20double,%20double)"><code>arc()</code></a> method. Really it’s mostly about pointing out which direction positive <em>y</em> is, but when I’ve learned something like this the hard way, I do my best to try and incorporate that knowledge into our public API. With any luck others can be spared my folly.</p>
<p><em>Drawn with Cairo, of course!</em></p>
<p>AfC</p>
<p>Update: Some people have pointed out that you can use a transformation matrix, and if you happen to (say) mirror across the horizontal axis then the clockwise notion would no longer apply. Fair enough; but if you have forgotten that +<em>y</em> starts out going down, then you’re not going to think to do such a flip in the first place.</p>2008-12-21T15:47:00+00:00Andrew Cowie: You never know
http://research.operationaldynamics.com/blogs/andrew/travel/germany/rhone-beaune.html
<p><img src="http://www.entrecote.de/images/pic_left/restaurant_sevice.jpg" alt="" title="" /></p>
<p>I was pleased to find a decent l’Entrecôte <a href="http://www.entrecote.de/">restaurant</a> in east Berlin around the corner from where I was staying.</p>
<p>I ordered what looked like it might be a promising little Côte de Rhône. Somewhat to my chagrin, a bottle of Côte de Beaune showed up instead. Which turned out to be delightful.</p>
<blockquote>
<p>Hautes-Côtes De Beaune 2005 <br />
“Clos De La Perrière” <br />
Domaine Parigot Père et Fils <br />
Meloisey</p>
</blockquote>
<p>Which just goes to show that what you ask for has little to do with what’s actually going to work with the meal you’re having.</p>
<p>AfC</p>2008-12-20T10:52:00+00:00Ken Gilmer: BUG + OpenJDK
http://community.buglabs.net/kgilmer/posts/45-BUG-OpenJDK
<p>Today we're happy to announce we are working with Robert Schuster and Sebastian Mancke of <a href="http://www.tarent.com/">tarent</a> and <a href="https://wiki.evolvis.org/jalimo/index.php/Main_Page">Jalimo</a> on porting <a href="http://community.buglabs.net/tags/openjdk.java.net">OpenJDK</a> to the BUG. We have watched excitedly in the past of progress being make in this effort from
various developers, and wanted to get involved. A few days back Robert reported his <a href="http://scap.linuxtogo.org/files/c039a99b7851be69c75e2bcdffea247f.png">initial success</a> with HotSpot and OpenJDK build from OpenEmbedded running on an <a href="http://wiki.openmoko.org/wiki/Neo_FreeRunner">OpenMoko phone</a>. This will have a big impact on BUG and impact on others as well. </p><p>
<span>What this means for BUG:</span> The BUG, being a platform for building custom gadgets and applications using Java and OSGi, has been served well with <a href="https://phoneme.dev.java.net/">PhoneME</a>. It's fast, has excellent support, and is very compatible and stable. However the BUG is a cutting-edge platform and we'd like to offer cutting-edge Java features as well. Based on tarent's work, we plan to offer a version of BUG that has all the latest language and classpath enhancements in OpenJDK. This future version will not have
GPL classpath restrictions, and will have the potential as being tested as a compliant Java environment. This is important for those wishing to extend the product.</p><p>
<span>What this means for Linux devices</span>: Java on embedded devices is a controversial subject. Some say it's too big, some say it's not "real" Java. Everyone has an opinion. This is an interesting time because it means shortly we will have access to same open Java environments on mobile devices that developers have gotten used to on the desktop and server. Embedded systems and general purpose computer categories have been converging for a while now, and this seems like another step in the progression.</p><p>
<span>What it means for ARM Linux Distros</span>: It was important for Bug and tarent to do the development in the open, and to use an existing community-based build system: <a href="http://community.buglabs.net/tags/www.pokylinux.org">Poky Linux</a>/<a href="http://www.openembedded.org">OpenEmbedded</a>. As work proceeds, the customers and contributors to open source projects and products such as <a href="http://gumstix.com">Gumstix</a>, <a href="http://www.openmoko.com">OpenMoko</a>, and the <a href="http://beagleboard.org">BeagleBoard</a> can easily and quickly benefit. We have been using a lot of great stuff from these projects and it's great to be able to work with tarent in giving back.</p><p>
We encourage others to get involved! The Jalimo source repository is here: <a href="http://evolvis.org/scm/?group_id=11">http://evolvis.org/scm/?group_id=11</a>. Open source Java is a great thing, and we're really looking forward to BUG + OpenJDK! </p>2008-12-19T18:32:37+00:00Dalibor Topic: The Devoxx That Was
http://robilad.livejournal.com/42289.html
This year's <a href="http://www.devoxx.com">Devoxx</a> ended a week ago, so after catching up on my mail queue (still some way to go until <a href="http://video.google.com/videoplay?docid=973149761529535925">Inbox Zero</a>, but also nowhere near having to declare <a href="http://www.wired.com/wired/archive/14.08/howtodesk.html">e-mail bankruptcy</a> yet), flushing my Community One talk ideas out, booking my <a href="http://wiki.debian.org/Java/DevJam/2009/Fosdem">FOSDEM</a> trip, and penning another little <a href="http://it-republik.de/jaxenter/news/Project-Jigsaw-Das-Siebener-Puzzle-046585.html">piece</a> in German, it's time to reflect on the conference that was.<br /><br />And it was great! It was the first time I went to Devoxx as a speaker on the regular track, so I was a little nervous how a <a href="http://mediacast.sun.com/users/robilad/media/EvolutionOfJavaOnLinux-Devoxx.pdf">talk</a> (that's describing how we're right in the middle of progressing from a world a few years ago in which Java was a second class citizen on GNU/Linux, that had to be tamed and updated manually, into one in which more and more of the rich commons of Free Software and Open Source projects written in the Java language is available out of the box along with an integrated JVM, and what kind of technological and cultural challenges are waiting for the unwary developer & packager) would play to an audience that I didn't really expect to be using GNU/Linux much yet.<br /><br />Well, was I in for a surprise! Contrary to my fears, my talk was well attended, with many attendees using Linux themselves, and some good conversations and <a href="http://www.jroller.com/peter_pilgrim/entry/devoxx_2008_university_wednesday">feedback</a> spinning out of it. In the hallways, there was the usual set of <a href="http://devoxx.com/display/JV08/Whiteboards">whiteboards</a>, including one with a favourite operating system poll - Linux collected the most votes on that one. This year, familiar Fedora and Ubuntu desktop themes also showed up along side Macs wherever notebooks were opened up to get hold of the WiFi. And thanks to Mark Reinhold's keynote session, Linux had at least 25% of the Devoxx keynote desktop operating system market share, possibly even more ...<br /><br />Looking back at the conference, it seems as if 'Open Source is simply the way we do things around here these days' is silently moving to the center stage in the Java world, just like how Linux seems to be gradually maturing into a good developer desktop choice without much fanfare. Many of the sessions in the conference schedule covered open source technologies - I think it's been the majority of the content this year, and I suspect it'll continue to grow further over the coming years. That's reflected in some of the conversations I had - the JavaFX ones were all about Linux support, and in particular support for use of free media formats.<br /><br />One of the surprisingly interesting BOFs I attended was the JCP one, organized by <a href="http://jcp.org/en/press/pmo/pmo_profiles/commFocusPMO-ulescu">Corina Ulescu</a>. Alex Buckley, Brian Goetz and others debated how to make the specification development process more transparent to more developers without turning it into a mess. Making it easier for JUGs to join the JCP came up as one way of adding more transparency to the process. Using more modern tools for collaboration came up as another, etc. There is a lot experimentation going on, apparently, but it's all moving in the right direction, from where I stand, and seems to be increasingly driven by developers participating in the JCP themselves.<br /><br />What I enjoy most about conferences like Devoxx is the opportunity to explore ideas and have conversations with old friends and to make new ones. This one was no exception, the hallway track was excellent - many thanks to <a href="http://www.javapolis.com/confluence/display/~stephan/Home">Stephan</a> & BeJUG for putting a great event together year after year!2008-12-19T18:22:04+00:00Jeroen Frijters: Modularization Status Update
http://weblog.ikvm.net/PermaLink.aspx?guid=f5cd40bc-d6ff-4fa1-8c0b-33a07f7ef967
<p>
I've been doing lots of modularization work, but I'm not quite ready to check it in
yet. I've now split the class library assembly into ten assemblies and I've got "shared
class loader" support working (at least for the core class library scenario).
</p>
<p>
I've been positively surprised by how many scenarios can be supported while only loading
IKVM.OpenJDK.Core.dll. As the graph below shows, it has more (necessarily circular)
dependencies than I would like, but for a number of scenarios I've carefully tweaked
the set of classes in Core to enable lazy loading the dependencies only when they
are really needed.
</p>
<p>
I'm not yet ready to commit to supported "Core-only" scenarios, but here's a flavor
of some things I've been able to do:
</p>
<ul>
<li>
Running "Hello, World!" in dynamic mode</li>
<li>
Serialization</li>
<li>
Reflection</li>
<li>
File I/O & Socket I/O (both classic and nio)</li>
</ul>
<p>
Packages included in Core:
</p>
<ul>
<li>
java.io</li>
<li>
java.lang</li>
<li>
java.lang.annotation</li>
<li>
java.lang.ref</li>
<li>
java.lang.reflection</li>
<li>
java.math</li>
<li>
java.net</li>
<li>
java.nio</li>
<li>
java.nio.channels</li>
<li>
java.nio.channels.spi</li>
<li>
java.nio.charset</li>
<li>
java.nio.charset.spi</li>
<li>
java.security</li>
<li>
java.security.cert</li>
<li>
java.util</li>
<li>
java.util.concurrent</li>
<li>
java.util.concurrent.atomic</li>
<li>
java.util.concurrent.locks</li>
<li>
java.util.regex</li>
<li>
javax.net</li>
</ul>
<p>
Here is the assembly dependency graph (click the image to enlarge):
</p>
<p>
<a href="http://www.frijters.net/OpenJDK-deps.png">
<img src="http://www.frijters.net/OpenJDK-deps-small.png" border="0" />
</a>
</p>
<p>
Here are the current assembly file sizes:
</p>
<p>
<table border="0">
<tbody>
<tr>
<td>
IKVM.OpenJDK.Core.dll</td>
<td align="right">
3,278,848</td>
</tr>
<tr>
<td>
IKVM.OpenJDK.Security.dll</td>
<td align="right">
2,646,016</td>
</tr>
<tr>
<td>
IKVM.OpenJDK.Util.dll</td>
<td align="right">
1,111,040</td>
</tr>
<tr>
<td>
IKVM.OpenJDK.Xml.dll</td>
<td align="right">
8,497,664</td>
</tr>
<tr>
<td>
IKVM.OpenJDK.SwingAWT.dll</td>
<td align="right">
3,040,768</td>
</tr>
<tr>
<td>
IKVM.OpenJDK.Charsets.dll</td>
<td align="right">
5,017,088</td>
</tr>
<tr>
<td>
IKVM.OpenJDK.Corba.dll</td>
<td align="right">
2,335,232</td>
</tr>
<tr>
<td>
IKVM.OpenJDK.Management.dll
</td>
<td align="right">
1,180,160</td>
</tr>
<tr>
<td>
IKVM.OpenJDK.Misc.dll</td>
<td align="right">
2,668,032</td>
</tr>
<tr>
<td>
IKVM.OpenJDK.Text.dll</td>
<td align="right">
628,736</td>
</tr>
<tr>
<td>
</td>
<td align="right">
30,403,584</td>
</tr>
</tbody>
</table>
</p>
<p>
It's interesting to see that the total is slightly less than the previous size of
IKVM.OpenJDK.ClassLibrary.dll (30,472,704).
</p>
<img width="0" height="0" src="http://weblog.ikvm.net/aggbug.ashx?id=f5cd40bc-d6ff-4fa1-8c0b-33a07f7ef967" />2008-12-19T07:49:00+00:00Petteri Räty: Binary package for icedtea6
http://blogs.gentoo.org/betelgeuse/2008/12/17/binary_packages_for_icedtea6
<p>Quite a few people have reported problems building icedtea6 or needed dependencies on our IRC channel and as the build is quite resource intensive, Caster has now made binary builds for icedtea6. The package is available via layman using:</p>
<pre>
layman -a java-overlay
emerge icedtea6-bin
</pre>
<p>The binary package should also make it easier to bootstrap the from source build. The binaries are built in stable chroots so they should run for our stable users too. Please report any problems to <a href="https://bugs.gentoo.org">https://bugs.gentoo.org</a> with [java-overlay] in the subject. For amd64 users this should be the easiest way to get a 64 bit browser plugin.</p><div class="item_footer"><p><small><a href="http://blogs.gentoo.org/betelgeuse/2008/12/17/binary_packages_for_icedtea6">Original post</a> blogged on <a href="http://b2evolution.net/">b2evolution</a>.</small></p></div>2008-12-18T15:15:11+00:00Roman Kennke: Caciocavallo Architecture Overview
http://kennke.org/blog/2008/12/18/caciocavallo-architecture-overview/
<p>I’m not a big fan of UML diagrams, but in this case I think it really helps to explain how Cacio works (and to recognize its beauty <img src="http://kennke.org/blog/wp-includes/images/smilies/icon_wink.gif" alt=";-)" class="wp-smiley" /> ).</p>
<p><img src="http://kennke.org/~roman/caciouml.png" alt="Caciocavallo Architecture Overview UML Diagram" width="341" height="477" /></p>
<p>Let me go from top to bottom and explain the parts that make up Caciocavallo:</p>
<ul>
<li>Swing: Everybody knows it. It is a universe of its own. Basically, it builds on AWT, is implemented in 100% Java, only uses so-called lightweight (non-native) components, has a lot of Look & Feel fluff, etc.</li>
<li>AWT: Slightly less known than Swing, this dinosaur is the foundation of Swing. It provides another, so-called heavyweight set of widgets, that are usually implemented by the corresponding platform widgets, as well as the toplevel containers (windows, dialogs, frames). It’s still 100% Java, but talks to AWT peers…</li>
<li>AWT peers: a set of interfaces that are used by AWT for the platform dependent parts. AWT doesn’t care who it talks to, as long as it provides the implementations for all the widgets in AWT. OpenJDK has two implementations of the peers, one for Win32, one for X11. If you happen to have a system that has all the required widgets and stuff available, this is the place to plug in. Caciocavallo is yet another one that helps for the cases where you don’t have native widgets.</li>
<li>The Cacio peers is another set of peers for AWT. It implements all the widgets by using Swing for drawing and logic. The idea is that each AWT widget should live in its own window. This means we have the obvious toplevel windows plus nested windows for all the components and containers. This makes sure that the widgets behave as they should - heavyweight. However, this windowing behaviour is not implemented in the peers directly, but instead hides behind the PlatformWindow interface.</li>
<li>PlatformWindow is an interface that provides all the windowing behaviour that we need for the AWT widgets and toplevels. It looks very similar to ComponentPeer aggregated with WindowPeer, but there are also some differences. The PlatformWindow implementation to be used for a widget is created by a PlatformWindowFactory that lives in the CacioToolkit. If you have a system that has no widgets, but supports (nestable) windows, you implement PlatformWindow and get all the AWT widgets for free.</li>
<li>ManagedWindow is an implementation of PlatformWindow for the case where you don’t have any native support for windows, for example a plain framebuffer. It implements all the necessary windowing behaviour, including nested and overlapping windows in Java, and builds only on another interface ManagedWindowContainer. Interestingly, it implements this same interface itself. This makes sense so that windows can be nested. ManagedWindows can also be useful on systems where you have support for toplevel windows, but not for nested windows. All you need to do is to implement the ManagedWindowContainer for the topmost container (e.g. the screen or the native toplevel windows).</li>
<li>ManagedWindowContainer is a really small interface, it only has a handful of methods, the most important beeing getGraphics(). If you implement this correctly (e.g. the example PlatformScreen class in the diagram), you can serve everything that builds on it - you get windows, you get heavyweight widgets, and of course all the heavyweight and lightweight AWT/Swing stuff.</li>
</ul>
<p>To summarize, there are 3 points to plug in potential implementations: at the peer level for systems with full widget sets, on the PlatformWindow level for systems w/o widgets but with windows or on the ManagedWindowContainer level for bare bones systems w/o anything. It’s also possible to start a full implementation on ManagedWindowContainer and then work the way up, because the interfaces are similar and higher-level interfaces are more or less supersets of the lower-level interfaces (it should be possible to transform a ManagedWindowContainer into a PlatformWindow, and to transform a PlatformWindow into a ComponentPeer and WindowPeer, etc). To give you a feel of the size: ManagedWindowContainer has ~4 methods, PlatformWindow ~20 methods, the whole set of peer interfaces ~100 methods.</p>
<p>Of course, this overview leaves out a lot of details, but in general it’s that easy. The implementation is not complete though: the peers don’t support all the widgets yet, the managed window doesn’t support every feature yet (i.e. restacking), but the general architecture is in place now, and it will most likely only change in the details.</p>2008-12-18T14:27:01+00:00Roman Kennke: Caciocavallo Managed Windows
http://kennke.org/blog/2008/12/18/caciocavallo-managed-windows/
<p>Yesterday evening I got the managed windows in Caciocavallo to the point where they draw correctly even in the case of obscuring overlapping windows. This is pretty neat:</p>
<p><a href="http://kennke.org/~roman/caciomanagedwindows.png"><img src="http://kennke.org/~roman/caciomanagedwindows.png" alt="Caciocavallo Managed Windows" width="300" height="200" /></a></p>
<p>You see the dialog in the middle is a heavyweight window that overlaps the main window beneath, which shows an animation. This behaviour is very important for supporting toplevel windows as well as AWT heavyweight widgets.</p>
<p>Implementing AWT on a fullscreen system using Caciocavallo is now as easy as implementing a Java2D pipeline for that screen, and let Cacio do all the funny stuff like handling windows, implement the widget peers, etc. And implementing the pipeline in the easiest (unoptimized) case also boils down to implementing SurfaceData for the system, which is one day of work or so. Rapid prototyping, yay!</p>2008-12-18T12:15:04+00:00Dalibor Topic: QotD: Jeet Kaul on Open Source plans for JavaFX
http://robilad.livejournal.com/42232.html
<blockquote><br />There are some dependencies on licensed code that cannot be open sourced. We are working towards decoupling the dependencies so that the non-proprietary portions can be open sourced. Currently the JavaFX compiler, Netbeans JavaFX plugin and Eclipse JavaFX plugin are already being developed in the open source. The scene graph is out in the open. We will put the core runtime out in the open over time. <br /></blockquote><br /><br />Jeet Kaul, VP of the Client Software Group at Sun Microsystems, <a href="http://blogs.sun.com/meetjeet/entry/javafx_the_road_ahead">mapping</a> out the road ahead towards an open source JavaFX runtime.2008-12-18T12:07:21+00:00Tom Tromey: The Eyre Affair
http://tromey.com/blog/?p=538
<p>Our friend Jennifer recommended this the other week.</p>
<p>Initially I put this book into the same category as <em>The Yiddish Policemen’s Union</em> — which is to say, tough competition. And, while enjoyable, <em>The Eyre Affair</em> is not really up to the same standard; the writing is decent but not popping, the ideas are fun but, after a while, perhaps a bit obvious.</p>
<p>By midway through I decided that this book fits more into the genre of <em>The Hitchhiker’s Guide</em>. It has a similar approach to logic and reality, and I found it enjoyable in a similar sort of way. Where <em>Union</em>, improbably, is a serious book in goofy trappings, <em>Affair</em> makes no excuses for its goofiness — every character has an absurd, jokey name.</p>
<p><em>Affair</em> is the first of a series. I read the second (good as well) and the third (less good). The series went meta — events happening inside of books in the book — and I lost my connection with the characters. Though… even the third has some gems, like the discussion of “had had” and “that that”.</p>
<p>I realized after a while that sometimes I am not positive enough about the good books, or <a href="http://tromey.com/blog/?p=462">detailed enough about my reasons for liking them</a>. You really ought to read <em>Union</em>. It is great. <em>Soon I Will Be Invincible</em> is another one — I wrote about it tepidly, but it really is a must-read.</p>2008-12-17T00:51:34+00:00Tom Tromey: 11. The End
http://tromey.com/blog/?p=552
<p>We’ve covered many of the features of python-gdb:</p>
<ul>
<li>Writing new commands</li>
<li>Convenience functions</li>
<li>Pretty-printing</li>
<li>Auto-loading of Python code</li>
<li>Scripting gdb from Python</li>
<li>Bringing up a GUI</li>
</ul>
<p>In fact, that is probably all of the user-visible things right now. There are classes and methods in the Python API to gdb that we have not covered, but you can read about those when you need to use them.</p>
<p>What next? There are a few things to do. There are probably bugs. As we saw in some earlier sections, support for I/O redirection is not there. We need better code for tracking the inferior’s state. Barring the unexpected, all this will be done in the coming months.</p>
<p>Now is an exciting time to be working on gdb. There are a number of very interesting projects underway:</p>
<ul>
<li>Reversible debugging is being developed. The idea here is that gdb can record what your program does, and then you can step backward in time to find the bug.</li>
<li>Sérgio Durigan Júnior, at IBM, has been working on syscall tracing support. This will let us do strace-like tracing in gdb. What’s nice about this is that all the usual gdb facilities will also be available: think of it as a Python-enabled strace, with stack dump capability.</li>
<li>The excellent folks at Code Sourcery (I would name names, but I’m afraid of leaving someone out) are working on <a href="http://sourceware.org/gdb/wiki/MultiProcess">multi-process support</a> for gdb. This is the feature I am most looking forward to. In the foreseeable future, gdb will be able to trace both the parent and the child of a <code>fork</code>. The particular “wow” use-case is something I read on the frysk web site: run “<code>make check</code>” in gdb, and have the CLI fire up whenever any program SEGVs. No more futzing with setting up the debug environment! In fact, no more figuring out how to get past libtool wrapper scripts — we could add a little hack so that you can just run them in gdb and the right thing will happen.</li>
</ul>
<p>Naturally, we’ll be wiring all this up to Python, one way or another.</p>
<p>I’ve also got some longer-term plans for the Python support. I’m very interested in extending gdb to debug interpreted languages. As with most computer problems, this means inserting a layer of indirection in a number of places: into expression parsing, into symbol lookup, into breakpoints, into watchpoints, etc. The goal here is to be able to write support for, say, debugging Python scripts, as a Python extension to gdb. Then, users could switch back and forth between “raw” (debugging the C implementation) and “cooked” (debugging their script) views easily.</p>
<p>I have two basic models I use when thinking about python-gdb: valgrind and emacs.</p>
<p>Emacs is a great example of managing the split between the core implementation and scripts. Emacs developers prefer to write in elisp when possible; the core exists, more or less, to make this possible for a wide range of uses. I’m trying to steer gdb in this direction. That is, push Python hooks into all the interesting places in gdb, and then start preferring Python over C. (Mozilla might have been another good example here — but I am more familiar with Emacs.)</p>
<p>Naturally, we’ll pursue this with extraordinary wisdom and care. Cough cough. Seriously, there are many areas of gdb which are not especially performance sensitive. For example, consider the new commands we wrote during this series. Even support for a new language would not require anything that could not be comfortably — and excellently — done in Python.</p>
<p>Valgrind taught me the <em>Field of Dreams</em> model: even a fairly esoteric area of programming can attract a development community, provided that you build the needed infrastructure. In other words, just look at all those cool valgrind skins. This library orientation, by the way, is something I would like to see GCC pursue more vigorously.</p>
<p>I’m very interested to hear your feedback. Feel free to post comments here, or drop us a line on the Archer list.</p>
<p>We’ve come to the end of this series of posts. I’m sad to see it end, but now it is time to stop writing about python-gdb features, and to go back to writing the features themselves. I’ll write more when there is more to be said.</p>2008-12-12T20:15:33+00:00Joe Darcy: Guidance on measuring the size of a language change
http://blogs.sun.com/darcy/entry/guidance_measure_language_change_size
<p>
Soon a
<a href="http://mail.openjdk.java.net/pipermail/compiler-dev/2008-December/000799.html">project</a>
will be starting to consider adding a to-be-determined set of <em>small</em> language changes to JDK 7. Given the rough timeline for JDK 7 and other on-going efforts to change the language, such as <a href="http://www.jcp.org/en/jsr/detail?id=294">modules</a> and <a href="http://groups.csail.mit.edu/pag/jsr308/">annotations on types</a>, only a limited number of small changes can be considered for JDK 7. That does <em>not</em> imply that larger changes aren't appropriate or worthwhile at some point in the future; in the mean time such changes can be
<a href="https://kijaro.dev.java.net/">explored</a> and honed for JDK 8 or later.
</p>
<p>
Separate from its size, criteria to evaluate the utility of a language change will be discussed in a future blog entry.
</p>
<p>
The JCP process defines three deliverables for a JSR:
</p>
<ul>
<li><p>Specification.
</p>
<li><p>Reference Implementation
</p>
<li><p>Compatibility Tests
</p>
</li></li></li></ul>
<p>
These three distinct aspects of a language change, specification, implementation, and general testing, exist whether or not the change is managed under a JSR. For this project, a language change will be judged small if it is simultaneously a small-enough effort under all three of specification, implementation, and testing. In other words, if a change is medium sized or larger in a single area, it is not a small change. (This corresponds to using an infinity norm to measure size; see <a href="http://blogs.sun.com/darcy/feed/entries/rss">"Norms: How to Measure Size"</a>.) Another concern is the size of change to developers, but if the change is small in these three areas, it is likely to be small for developers to learn and adopt too. Because there is limited fungiblity between the people working on specification, implementation, and testing, a single oversize component can't necessarily be compensated for by the other two components being small enough to managed on their own.
</p>
<p>
The size of a specification change is not just related to the amount of text that is altered; it also depends on <a href="http://blogs.sun.com/abuckley/entry/complexity_in_language_design">which text</a>, how many new concepts are needed, and the complexity of those concepts. Similarly, the implementation effort can be large if a limited amount of tricky code is involved as well as if a large volume of prosaic code is needed. An estimate of the future maintenance effort should factor into judging the net implementation cost too.
The specification size and implementation size are often not closely related; a small spec change can require large implementation efforts and vice versa. JCK-style conformance testing is based on testing assertions in the specification, so the size of this kind of testing effort should have some positive correlation with the size of the specification change. Likewise, regression testing should have at least a weak positive correlation with the size of the implementation change. However, adequate conformance testing can be disproportionately large compared to the size of the specification change depending on how the assertions interact and how many programs they affect.
</p>
<p>
Due to complexity of the Java type system and the desire to maintain backwards compatibility, almost any type system change will be at least a medium-sized effort for the implementation, specification, or both. Each new feature of the type system can interact with all the existing features, as well as all the future ones, so type system changes must be approached with healthy skepticism.
</p>
<p>
As a point of reference, the set of Java SE 5 language features will be sized according to the above criteria; from smallest to largest:
</p>
<ul>
<li><p><b>Normal maintenance, Size: Tiny</b><br />
In the course of maintaining the platform, small changes and corrections are made to the
<a href="http://java.sun.com/docs/books/jls/">Java Language Specification</a> (JLS) and <tt>javac</tt>. These changes even take together are not large enough to warrant a JSR separate from the platform umbrella JSR.
</p>
<li><p><b>Hexadecimal floating-point literals, Size: Very small</b><br />
<a href="http://blogs.sun.com/darcy/entry/hexadecimal_floating_point_literals">Hexadecimal floating-point literals</a> were a small new feature added to the language in JDK 5 under maintenance. Only very localized grammatical changes were needed in the JLS together with well-bounded supporting library methods.
</p>
<li><p><b>for-each loop, Size: Small</b><br />
Part of <a href="http://www.jcp.org/en/jsr/detail?id=201">JSR 201</a>, the enhanced <tt>for</tt> statement required a <a href="http://java.sun.com/docs/books/jls/third_edition/html/statements.html#14.14.2">new section</a> in the JLS and a straightforward desugaring by the compiler. However, there were still complications; calamity was narrowly averted in the new libraries needed to support the <tt>for</tt> loop. A new <tt>java.<b>lang</b>.Iterator</tt> type that would have broken migration compatibility was dropped in favor of reusing the less than ideal <tt>java.<b>util</b>.Iterator</tt>.
</p>
<li><p><b>static import, Size: Small, but more complicated than expected</b><br />
<a href="http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.5.3">Static import</a> added more ways to influence the mapping of simple names in source code to the binary names in class files. The mapping already had complexities, including rules for
<a href="http://java.sun.com/docs/books/jls/third_edition/html/classes.html#227928">hiding</a>,
<a href="http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.3.1">shadowing</a>,
and <a href="http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.3.2">obscuring</a>;
static import introduced more interactions.
</p>
<li><p><b>enum types, Size: Medium</b><br />
By introducing a new kind of type, adding enum types included a type system modification and so were a medium-sized change. While the normative <a href="http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.9">JLS text</a> devoted to enums is brief, JVMS changes were also required, as well as surprising time-consuming and intricate libraries work, including interactions with IIOP serialization.
</p>
<li><p><b>autoboxing and unboxing, Size: Medium</b><br />
The complications with autoboxing and unboxing come not from the feature directly, but from its interactions with generics and method resolution.
</p>
<li><p><b>Annotation types, Size: Large</b><br />
As an enum was a new kind of specialized class, an annotation type, introduced in <a href="http://www.jcp.org/en/jsr/detail?id=175">JSR 175</a>, were a new kind of specialized interface. Besides being a type change, annotation types required coordinated JVM and library modifications as well as a <a href="http://java.sun.com/j2se/1.5.0/docs/guide/apt/">new tool and framework</a>, and a
<a href="http://jcp.org/en/jsr/detail?id=269">subsequent standardization</a>,
to fulfill the potential of the feature.
</p>
<li><p><b>Generics, Size: Huge</b><br />
<a href="http://www.jcp.org/en/jsr/detail?id=14">Generics</a> were a pervasive change to the platform, introducing many new concepts in the specification, considerable change to the compiler, and far-reaching libraries updates.
</p>
</li></li></li></li></li></li></li></li></ul>
<p>
Some examples of bigger-than-small language changes that have been discussed in the community include:
</p>
<ul>
<li><p><b><a href="http://www.javac.info/">BGGA closures</a>:</b> Independent of the technical merit of the proposal, BGGA closures would be a large change to the language and platform.
</p>
<li><p><b>Properties:</b> While a detailed judgment would have to be made against a specific proposal, as a new kind of type properties would most likely be at least medium-sized.
</p>
<li><p><b><a href="http://java.sun.com/docs/books/jls/third_edition/html/classes.html#227928" title="Add reification of generic type parameters to the Java programming language">Reification</a>:</b> The addition of information about the type parameters of objects at runtime would involve language changes, nontrivial JVM changes to maintain efficiency, and raise compatibility issues.
</p></li></li></li></ul>
<p>
Specific small language changes we at Sun are advocating for JDK 7 will be discussed in the near future.
</p>2008-12-11T17:00:00+00:00Roman Kennke: Caciocavallo updates
http://kennke.org/blog/2008/12/11/caciocavallo-updates/
<p>The last couple of days I came around to work a little more on Caciocavallo. I added two notable features:</p>
<p><strong>Event Handling</strong></p>
<p>Event handling is now done in Caciocavallo. We now have a generic event pump that pulls event data out of a CacioEventSource implementation. EventSource is an interface that has to be provided by the target implementation and delivers event data. This data is then processed, possibly transforming some things, and eventually an AWT event is generated of it and posted to the AWT event queue. On the target implementation, only the CacioEventSource has to be implemented, which usually simply polls the native event queue and fills in the event data.</p>
<p><strong>Managed Windows</strong></p>
<p>Cacio will support ‘managed windows’ soon, only needs some cleanup before committing. A little background is probably in place: the idea in Cacio is that all the AWT widgets live in their own heavyweight window. Those windows are nested and laid out according to the structure and layout of the heavyweight AWT widgets. The peers implement the painting and logic by using Swing, and delegate the windowing stuff to an interface called PlatformWindow. A target implementation basically only needs to implement the PlatformWindow interface and gets all the AWT widgets for free.</p>
<p>But what if your target system doesn’t support any windows? Think of a plain framebuffer as example? In this case you need to implement the windowing logic yourself. In order to help making this easier, I added a generic ‘window manager’ (it’s not like the X11 window managers, more like what X Windows itself does: handle rectangular, possibly nested areas on the screen). This implements the PlatformWindow interface and only needs an implementation of an even simpler interface (called ManagedWindowContainer) as the backend.</p>
<p>This also will do alot of work for events: the target implementation only needs to provide mouse and keyboard events, and the window manager will generate focus, window and component events for you.</p>
<p>With this window manager in place it will be possible to support all kinds of setups I can think of: 1. A fullscreen target with no window support at all. The window manager then manages all the toplevel AND nested windows. 2. Basic toplevel window support on the target. Let your target handle the toplevel window and use the window manager to handle the nested windows. 3. Full window support on the target (think X11). You don’t need the window manager then and implement PlatformWindow directly.</p>2008-12-11T16:24:43+00:00Tom Tromey: 10. Wacky stuff
http://tromey.com/blog/?p=550
<p>Last time I promised something flashy in this post. What could be flashier than a GUI?</p>
<p>Here’s some code to get you started:</p>
<pre>from threading import Thread
import gtk
def printit ():
print "Hello hacker"
class TestGtkThread (Thread):
def destroy (self, *args):
self.window.hide()
def hello (self, *args):
gdb.post_event (printit)
def run (self):
gtk.gdk.threads_init()
self.window = gtk.Window(gtk.WINDOW_TOPLEVEL)
self.window.connect("destroy", self.destroy)
self.window.set_border_width(10)
button = gtk.Button("Hello World")
# connects the 'hello' function to the clicked signal from the button
button.connect("clicked", self.hello)
self.window.add(button)
button.show()
self.window.show_all()
gtk.main()
class TestGtk (gdb.Command):
def __init__ (self):
super (TestGtk, self).__init__ ("testgtk", gdb.COMMAND_NONE,
gdb.COMPLETE_NONE)
self.init = False
def invoke (self, arg, from_tty):
self.dont_repeat()
if not self.init:
self.init = True
v = TestGtkThread()
v.setDaemon (True)
v.start ()
TestGtk()</pre>
<p>Note that we finesse the problem of main loop integration by simply starting a separate thread. My thinking here is to just use message passing: keep gdb operations in the gdb thread, and gtk operations in the GUI thread, and send active objects back and forth as needed to do work. The function <code>gdb.post_event</code> (<code>git pull</code> to get this) arranges to run a function during the gdb event loop; I haven’t really investigated sending events the other direction.</p>
<p>The above isn’t actually useful — in fact it is just a simple transcription of a python-gtk demo I found somewhere in <code>/usr/share</code>. However, the point is that the addition of Python cracks gdb open: now you can combine gdb’s inferior-inspection capabilities with Python’s vast suite of libraries. You aren’t tied to the capabilities of a given gdb GUI; you can write custom visualizers, auto-load them or load them on demand, and use them in parallel with the CLI. If your GUI provides a CLI, you can do this without any hacks there at all; for example, this kind of thing works great from inside Emacs.</p>
<p>The next post is the final one in this series, I’m sorry to say.</p>2008-12-10T21:21:25+00:00Robert Lougher: BUG Labs JVM saga end game
http://draenog.blogspot.com/2008/12/bug-labs-jvm-saga-end-game.html
I've been following <a href="http://www.buglabs.net">Bug Labs</a> choice of JVM quite closely. After a series of comparisons between JamVM, CacaoVM and PhoneME they adopted PhoneME (initial test <a href="http://bugblogger.com/java-vms-compared-160/">here</a> <span></span>and the <a href="http://bugblogger.com/java-vms-compared-ii-187/">follow-up</a>). I <a href="http://draenog.blogspot.com/2008/07/embedded-jvm-comparison.html">blogged</a> on the results of the first test, which were favourable to JamVM. However, for the second test, they sorted out the problems with running PhoneME's JIT, and the positions of JamVM and PhoneME reversed.<br /><br />This was disheartening, but the results spoke for themselves. However, one odd fact is that the second test did not give any details of start-up time. JamVM clearly won this in the first test, and it's unlikely enabling PhoneME's JIT would have changed this.<br /><br />So, I read with great interest the recent <a href="http://community.buglabs.net/kgilmer/posts/37-CACAO-GNU-Classpath-on-BUG">blog</a> entry where they've got CacaoVM/GNU Classpath running on the BUG. It appears they will still ship with PhoneME, but CacaoVM/GNU Classpath will be an option for customers who require the Classpath exception.<br /><br />So what? Well, I'd like an explanation why they seem so reluctant to use JamVM. From their own tests, JamVM came out on top for start-up, and came second in performance to PhoneME with JIT.<br /><br />Perhaps they've finally cracked the performance problems with CacaoVM. But JamVM is not configured for top performance on ARM either (by default, the inlining interpreter is disabled on ARM).<br /><br />Of course, there are many other advantages to JamVM on embedded systems besides start-up time. It has its own, compacting garbage-collector with full support for soft, weak and phantom references in addition to class unloading. CacaoVM relies on Boehm GC, exhibiting <a href="http://server.complang.tuwien.ac.at/cgi-bin/bugzilla/show_bug.cgi?id=32">memory fragmentation issues</a>, and it has no support for soft/weak/phantom references or class-unloading.<br /><br />Things like this makes me very disheartened. As I've said before, it makes me wonder why I continue to work on JamVM at all. However, giving up will be a case of "cutting my nose off to spite my face".<br /><br />If they've hit any problems with JamVM I'll be quite happy to work with them to fix them, but I've received no feedback or requests. Unfortunately, I have been unable to leave any comments on the blog entry itself. On enquiring with the webmaster, it appears that this is new software which is at an early stage. However, they've put this functionality at the top of their TODO list, and I can expect it in a day or two (thanks Brian).<br /><br />To finish on a positive note, I've done quite a lot of work on JamVM over the last few months, including memory footprint and performance improvements over JamVM 1.5.1. Hopefully I'll make a new release before Christmas.2008-12-09T22:12:51+00:00Kelly O'Hair: OpenJDK6 Repositories!
http://blogs.sun.com/kto/entry/openjdk6_repositories
<p>
I see it! It actually exists! Yes Virginia, There Is a Santa Claus!
<center>
<img src="http://blogs.sun.com/kto/resource/WhaleSighting.jpg" border="0" width="500" />
</center>
<p>
Actually that's a whale we saw in Alaska this summer. No I'm not trying to insult Santa. ;^)
<p>
Seriously, we have our first cut at generated OpenJDK6 repositories:
<blockquote>
<a href="http://hg.openjdk.java.net/jdk6/jdk6">http://hg.openjdk.java.net/jdk6/jdk6</a>
</blockquote>
<p>
You can browse all 7 repositories:
<blockquote>
<ul>
<li> Top Repository (forest root):
<a href="http://hg.openjdk.java.net/jdk6/jdk6">http://hg.openjdk.java.net/jdk6/jdk6</a>
</li>
<li> Jdk Repository:
<a href="http://hg.openjdk.java.net/jdk6/jdk6/jdk">http://hg.openjdk.java.net/jdk6/jdk6/jdk</a>
</li>
<li> Hotspot Repository
<a href="http://hg.openjdk.java.net/jdk6/jdk6/hotspot">http://hg.openjdk.java.net/jdk6/jdk6/hotspot</a>
</li>
<li> Langtools Repository:
<a href="http://hg.openjdk.java.net/jdk6/jdk6/langtools">http://hg.openjdk.java.net/jdk6/jdk6/langtools</a>
</li>
<li> Corba Repository:
<a href="http://hg.openjdk.java.net/jdk6/jdk6/corba">http://hg.openjdk.java.net/jdk6/jdk6/corba</a>
</li>
<li> Jaxp Repository:
<a href="http://hg.openjdk.java.net/jdk6/jdk6/jaxp">http://hg.openjdk.java.net/jdk6/jdk6/jaxp</a>
</li>
<li> Jaxws Repository
<a href="http://hg.openjdk.java.net/jdk6/jdk6/jaxws">http://hg.openjdk.java.net/jdk6/jdk6/jaxws</a>
</li>
</ul>
</blockquote>
<p>
Or you can clone them, or do a forest clone to get the entire forest:
<blockquote>
<tt>hg fclone http://hg.openjdk.java.net/jdk6/jdk6 yourjdk6</tt>
</blockquote>
(See <a href="http://openjdk.java.net/guide/repositories.html#installConfig">
the OpenJDK Developer Guide</a>
for more information on how to setup Mercurial and the forest extension).
<p>
A few important notes:
<ul>
<li>
These should be treated as experimental and read-only, official ones should be next week
</li>
<li>
They should match the contents of the OpenJDK6 source bundles, except:
<ul>
<li>
No control directory, these files are in the top repository now
</li>
<li>
Previously you had to 'cd control/make && gnumake', now just 'cd . && gnumake'
</li>
<li>
README-builds.html is in the top repository, it's movement has created
a little confusion in the changesets, ultimately we will have one copy.
</li>
</ul>
<li>
Contributed changes should be documented in the changeset comments,
if the contribution information is missing please let me know
</li>
<li>
These repositories were created from the TeamWare workspaces and a set
of patches and documentation on those patches, we may have to re-create them.
If we re-create repositories again, the old ones will not be related
to the new ones. So any changesets you create with your clones
should be viewed as temporary until the final repositories are put in place.
</li>
<li>
The hotspot repository may be completely replaced when we upgrade to HS14,
so when that happens you may need to re-clone the hotspot repository.
</li>
</li></ul>
<p>
Please let me know if you see anything wrong with these repositories.
<p>
The target date for official repositories is next week, once it is official
we can add more changesets to correct problems, but we can't go back and
change the changesets already created.
<p>
-kto</p></p></p></p></p></p></p></p></p>2008-12-09T00:17:44+00:00Tom Tromey: 9. Scripting gdb
http://tromey.com/blog/?p=548
<p>So far we’ve concentrated on way to use Python to extend gdb: writing new commands, writing new functions, and customized pretty-printing. In this post I want to look at gdb from a different angle: as a library. I’ve long thought it would be pretty useful to be able to use gdb as a kind of scriptable tool for messing around with running programs, or even just symbol tables and debug info; the Python work enables this.</p>
<p>One word of warning before we begin: we’re starting to get into the work-in-progress parts of python-gdb. If you play around here, don’t be surprised if it is not very polished. And, as always, we’re interested in your feedback; drop us a line on the Archer list.</p>
<p>For historical and technical reasons, it is pretty hard to turn gdb into an actual loadable Python library. This might be nice to do someday; meanwhile we’ve made it possible to invoke gdb as an interpreter: add the “<code>-P</code>” (or “<code>--python</code>“) option. Anything after this option will be passed to Python as <code>sys.argv</code>. For example, try this script:</p>
<pre>#!/home/YOURNAME/archer/install/bin/gdb -P
print "hello from python"</pre>
<p>Ok… so far so good. Now what? How about a little app to print the size of a type?</p>
<pre>#!/home/YOURNAME/archer/install/bin/gdb -P
import sys
import gdb
gdb.execute("file " + sys.argv[1])
type = gdb.Type (sys.argv[0])
print "sizeof %s = %d" % (sys.argv[0], type.sizeof ())</pre>
<p>You can script that with gdb today, though the invocation is uglier unless you write a wrapper script. More complicated examples are undeniably better. For instance, you can write a “pahole” clone in Python without much effort.</p>
<p>That invocation of <code>gdb.execute</code> is a bit ugly. In the near future (I was going to do it last week, but I got sick) we are going to add a new class to represent the process (and eventually processes) being debugged. This class will also expose some events related to the state of the process — e.g., an event will be sent when the process stops due to a signal.</p>
<p>The other unfinished piece in this area is nicer I/O control. The idea here is to defer gdb acquiring the tty until it is really needed. With these two pieces, you could run gdb invisibly in a pipeline and have it bring up the CLI only if something goes wrong.</p>
<p>It will look something like:</p>
<pre>#!/home/YOURNAME/archer/install/bin/gdb -P
import sys
import gdb
def on_stop(p):
(status, value) = p.status
if status != gdb.EXIT:
gdb.cli ()
else:
sys.exit (value)
process = gdb.Inferior(sys.argv)
process.connect ("stop", on_stop)
process.run ()</pre>
<p>I’ll probably use python-gobject-like <code>connect</code> calls, unless Python experts speak up and say I should do something different.</p>
<p>The next post will cover a flashier use of Python in gdb. Stay tuned.</p>2008-12-09T00:00:39+00:00Joe Darcy: OpenJDK 6: Trial Mercurial Repositories Available
http://blogs.sun.com/darcy/entry/openjdk_6_trial_mercurial_repositories
<p>
Thanks to <a href="http://blogs.sun.com/kto">Kelly</a>, trial <a href="http://hg.openjdk.java.net/jdk6/jdk6">Mercurial repositories</a> for OpenJDK 6 are now available for evaluation.
These trial repositories will be available read-only for about a week to find any problems before creating the final live repositories; for details, see
<a href="http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-December/000310.html">Kelly's email</a>
to the jdk6-dev alias.
</p>2008-12-08T23:44:09+00:00Ken Gilmer: CACAO + GNU Classpath on BUG
http://community.buglabs.net/kgilmer/posts/37-CACAO-GNU-Classpath-on-BUG
<p>In order to support a partner, we needed to get a JVM on the BUG that had the commericial-friendly classpath exception clause to the GPL. Unfortuantely <a href="http://www.sun.com/software/opensource/java/faq.jsp">phoneME does not have this</a>, however <a href="http://www.gnu.org/software/classpath/">GNU Classpath</a> does. I know of two JVMs we could use: <a href="http://jamvm.sourceforge.net/">JamVM</a> and <a href="http://www.cacaovm.org/">CACAO</a>. The <a href="https://wiki.evolvis.org/jalimo/index.php/Main_Page">Jalimo</a> people have done a good job updating OpenEmbedded with the latest CACAO sources. <a href="http://marcin.juszkiewicz.com.pl/">Marcin</a> completed the work in getting a build image from sources with CACAO and all the BUG OSGi code including JNI support, and poof! Java 1.5 on BUG! Of course we will continue to ship phoneME on the BUG, but it's great to give our customers and collaborators the option of dropping something else in on a whim. Without the OpenEmbedded, Jalimo, GNU Classpath, CACAO, and other Java FOSS communities we could never have done this!</p><p><code name="code" class="python">
root@bug:~# java -version
</code></p><p><code name="code" class="python">java version "1.5.0"
</code></p><p><code name="code" class="python">CACAO version 0.99.3
Copyright (C) 1996-2005, 2006, 2007, 2008
CACAOVM - Verein zur Foerderung der freien virtuellen Maschine CACAO
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
</code></p><p><code name="code" class="python">root@bug:~#</code> </p>2008-12-08T23:26:44+00:00Jonathan Gibbons: Raising the (langtools) quality bar
http://blogs.sun.com/jjg/entry/raising_the_langtools_quality_bar
<p>Recently, we've been working to raise the quality bar for
the code in the OpenJDK langtools repository.
<p>Before OpenJDK, the basic quality bar was set by the JDK's
product team and SQE team. They defined the test suites to be
run, how to run them, and the target platforms on which they
should be run. The test suites included the JDK regression
tests, for which the standard was to run each test in its
own JVM (simple and safe, but slow), and the platforms were
the target platforms for the standard Sun JDK product.
<p>Even so, the bar was somewhat higher in selected areas. The
javac team has pushed the use of running the javac regression
tests in "same JVM" mode, because it is so much faster.
Starting up a whole JVM to compile a three line program to
verify that a particular error message is generated is like
using a bulldozer to crack an egg. Likewise, as a pure Java
program, it has been reasonable to develop the compiler and
related tools, and to run the regression tests, on non-mainstream
supported platforms.
<p>With the advent of OpenJDK, the world got a whole lot bigger,
and expectations got somewhat higher, at least for the langtools
component. If nothing else, there's a bigger family of developers
these days, with a bigger variety of development environments,
to be used for building and testing OpenJDK.
<p>We've been steadily working to make it so that all the langtools
regression tests can be run in "same JVM" mode. This has required
fixes in a number of areas:
<ul compact="compact">
<li> in the regression test harness (jtreg)
<li> in tools like javadoc, which used to be neither reusable nor
re-entrant. This made it hard to test it with different
tests in the same VM. javadoc is now reusable, re-entrant
is coming soon
<li> in the tests themselves: some tests we changed to make them
same-VM safe; others, like the apt tests, we simply
marked as requiring "othervm" mode. Marking a test as
requiring "othervm" allows these tests to succeed when
the default mode for the rest of the test suite is "samevm".
</li></li></li></ul>
<p>We've also made it so that you can run the langtools tests without
building a full JDK, by using the -Xbootclasspath option. For a
while, that left one compiler test out in the cold (versionOpt.sh)
but that test was finally rewritten, recently.
<p>We've been working to use Hudson to build and test the langtools
repository, in addition to the standard build and test done by
Release Engineering and QA teams. This allows us (developers) to perform
additional tests more easily, such as running FindBugs, or
testing "developer" configurations as well as "product" configurations.
(i.e. the configurations an OpenJDK developer might use.)
This has also made us pay more attention to the documented way
to run the langtools regression tests, using the standard Ant
build file. In practice, the Sun's "official" test runs are
done using jtreg from the command line, and speaking for myself,
I prefer to run the tests from the command line as well, to have
more control over which tests to run or rerun, and how to run them.
<p>The net result of all of this is that the langtools regression tests
should all always pass, however they are run. This includes
<ul compact="compact">
<li> as part of testing a fully built JDK
<li> as part of testing a new version of langtools, using an earlier
build of JDK as a baseline
<li> from the jtreg command line in "other vm" mode
<li> from the jtreg command line in "same vm" mode
<li> from the <code><jtreg></code> Ant task, such as used in the
standard build.xml file
<li> on all Java platforms
</li></li></li></li></li></li></ul></p></p></p></p></p></p></p></p>2008-12-08T21:53:30+00:00Joe Darcy: Coming Soon: A JSR for small language changes in JDK 7
http://blogs.sun.com/darcy/entry/small_language_changes_jdk_7
<p>
I'm happy to announce that I'll be leading up Sun's efforts to develop a set of small language changes in JDK 7; we intend to submit a JSR covering those changes during the first half of 2009. However, before the JSR proposal is drafted and submitted to the JCP, we'll first be running a call for proposals so Java community members can submit detailed, thoughtful changes for consideration too. We'll be seeding the discussion with a few proposals we think would improve the language. More information on our proposed changes, guidance for measuring the size of a change, and criteria for judging the desirability of a language change will be coming over the next several weeks.
</p>
<p>
I've <a href="http://mail.openjdk.java.net/pipermail/announce/2008-December/000065.html">proposed an OpenJDK project</a> to host the discussion of the proposals and potentially some prototype implementations.
</p>
<p><b>Suggested Reading</b><br />
<i><a href="http://blogs.sun.com/darcy/entry/so_you_want_to_change">So you want to change the Java Programming Language...</a></i>
</p>2008-12-08T19:25:14+00:00Jeroen Frijters: Modularizing OpenJDK
http://weblog.ikvm.net/PermaLink.aspx?guid=2ecd5b7e-ae32-413b-8970-fc467d9e3f12
<p>
Recently Mark Reinhold <a href="http://blogs.sun.com/mr/entry/big_jdk">started</a><a href="http://blogs.sun.com/mr/entry/packaging_java_code">blogging
about</a><a href="http://blogs.sun.com/mr/entry/modular_java_platform">modularizing</a><a href="http://blogs.sun.com/mr/entry/jigsaw">the
JDK</a>. I've been getting requests to split up IKVM.OpenJDK.ClassLibrary.dll for
a long time. It's good to see that the Java platform is also moving in that direction,
but we needn't wait for that.
</p>
<p>
I've been working on making ikvmc support "<a href="http://weblog.ikvm.net/PermaLink.aspx?guid=46dbafeb-4d5a-42ff-a34b-414b8b2361c0">multi
target</a>" mode for a while now. Last week I used this mode to compile the OpenJDK
classes into 743 different assemblies (one per package) . I then tried to use NDepend
to dig through the dependencies, but it turns out that 743 assemblies is a bit too
much to handle (NDepend handled it resonably well, but the dependency graph was way
too large to be useful). So I started moving some obvious stuff together. The result
was this <a href="http://www.frijters.net/NDepend/NDependReport.html">NDepend report</a>.
Still a lot of data and a lot of dependencies, but some patterns are starting to emerge.
</p>
<p>
Here's my preliminary view of how things could be split:
</p>
<p>
<table border="0">
<tbody>
<tr>
<td>
IKVM.OpenJDK.Core.dll</td>
<td>
5 MB</td>
</tr>
<tr>
<td>
IKVM.OpenJDK.Security.dll</td>
<td>
3 MB</td>
</tr>
<tr>
<td>
IKVM.OpenJDK.Util.dll</td>
<td>
1 MB</td>
</tr>
<tr>
<td>
IKVM.OpenJDK.Xml.dll</td>
<td>
8 MB</td>
</tr>
<tr>
<td>
IKVM.OpenJDK.SwingAWT.dll</td>
<td>
3 MB</td>
</tr>
<tr>
<td>
IKVM.OpenJDK.Charsets.dll</td>
<td>
5 MB</td>
</tr>
<tr>
<td>
IKVM.OpenJDK.Corba.dll</td>
<td>
2 MB</td>
</tr>
<tr>
<td>
IKVM.OpenJDK.Management.dll
</td>
<td>
2 MB</td>
</tr>
<tr>
<td>
IKVM.OpenJDK.Misc.dll</td>
<td>
3 MB</td>
</tr>
</tbody>
</table>
</p>
<p>
(The sizes are only approximate.)
</p>
<p>
I had originally hoped to make IKVM.OpenJDK.Core.dll smaller by keeping java.util,
java.net and java.io out of it, but it looks like you won't be able to run anything
non-trivial without requiring classes from these packages, so it makes more sense
to put them into the core assembly. The IKVM.OpenJDK.Security.dll and IKVM.OpenJDK.Util.dll
assemblies contain other util and security related packages that shouldn't be needed
as often.
</p>
<p>
It is possible to split packages across assemblies (e.g. <a href="http://java.sun.com/javase/6/docs/api/java/awt/AWTPermission.html">java.awt.AWTPermission</a> will
be in IKVM.OpenJDK.Core.dll because <a href="http://java.sun.com/javase/6/docs/api/java/lang/SecurityManager.html">java.lang.SecurityManager</a> depends
on it), but given the potential for confusion my current thinking is that it is probably
best to only move individual classes into Core should it be necessary (because, realistically,
you can't develop without having a reference to Core you're less likely to be confused
when trying to locate the class).
</p>
<p>
To avoid confusion or expectations that are too high: I haven't yet built the runtime
infrastructure to support this. So while I can compile the class library into all
these parts, the runtime won't actually be able to work correctly, because it still
expects all the boot class loader classes in a single assembly.
</p>
<p>
As always, feedback on the proposed split is very welcome.
</p>
<p>
<b>NDepend</b>
</p>
<p>
I really like NDepend's ability to show the dependencies in different ways and the
interactive dependency matrix that allows you to drill down into a dependency to see
exactly where it comes from. Beyond dependency analysis it also has a power SQL like
query language to allows use to query dependencies and compute all the code metrics
you can come up with. It also includes a number of code metrics out of the box, but
those aren't really my cup of tea, so I can't comment how useful they are.
</p>
<p>
One other small but really nice thing about it is that you can run it without installing.
IMO this is very nice compared with installers that do who knows what to your system
(and require administrator access).
</p>
<p>
An evaluation copy can be downloaded from their <a href="http://www.ndepend.com/">website</a>.
</p>
<p>
Full disclosure: I was given a free copy of NDepend Professional Edition.
</p>
<img width="0" height="0" src="http://weblog.ikvm.net/aggbug.ashx?id=2ecd5b7e-ae32-413b-8970-fc467d9e3f12" />2008-12-08T05:51:28+00:00Mark Reinhold: Project Jigsaw
http://blogs.sun.com/mr/entry/jigsaw
<p><span>Vision</span> The JDK is big—and hence it <a href="http://blogs.sun.com/mr/entry/massive_monolithic_jdk">ought to be
modularized</a>. Doing so would enable significant improvements to the key
performance metrics of download size, startup time, and memory
footprint. </p>
<p> Java libraries and applications can also <a href="http://blogs.sun.com/mr/entry/packaging_java_code">benefit from
modularization</a>. Truly modular Java components could leverage the
performance-improvement techniques applicable to the JDK and also be easy to
publish in the form of familiar native packages for many operating
systems. </p>
<p> Finally, in order to realize the full potential of a modularized JDK and
of modularized applications the <a href="http://blogs.sun.com/mr/entry/modular_java_platform">Java Platform
itself should also be modularized</a>. This would allow applications to be
installed with just those components of the JDK that they actually require.
It would also enable the JDK to scale down to smaller devices, yet still
offer conformance to specific Profiles of the Platform Specification. </p>
<p> Okay—so where do we start? </p>
<p><span>JDK 7</span> As a first step toward this brighter, modularized
world, Sun’s primary goal in the upcoming JDK 7 release will be to
modularize the JDK. </p>
<p> There will be other goals, to be sure—more on those later—but the
modularization work will drive the release, which we hope to deliver early
in 2010. </p>
<p><span>Tools</span> Modularizing the JDK requires a module system capable
of supporting such an effort. It requires, in particular, a module system
whose core can be implemented directly within the Java virtual machine, since
otherwise the central classes of the JDK could not themselves be packaged
into meaningful modules. </p>
<p> Modularizing the JDK—or indeed any large code base—is best done with
a module system that’s tightly integrated with the Java language, since
otherwise the compile-time module environment can differ dramatically from
the run-time module environment and thereby make the entire job far more
difficult. </p>
<p> Now—which module system should we use? </p>
<p><span>JSR 277</span> The current draft of <a href="http://jcp.org/en/jsr/detail?id=277">this JSR</a> proposes the JAM
module system, which has been the subject of much debate and is far from
finished. This system is intended to be at least partly integrated with the
Java language. Owing to some of its rich, non-declarative features, however,
it would be impossible to implement its core functionality directly within
the Java virtual machine. </p>
<p> Sun has therefore decided to halt development of the JAM module system,
and to put JSR 277 on hold until after Java SE 7. </p>
<p><span>JSR 294</span> This JSR, <a href="http://jcp.org/en/jsr/detail?id=294"><i>Improved Modularity Support in
the Java Programming Language</i></a>, is chartered to extend the Java
language and the Java virtual machine to support modular programming. Its
Expert Group has already discussed language changes that have been <a href="http://www.osgi.org/blog/2008/04/jsr-294-superpackages-no-more.html">well
received</a> for their simplicity as well as their utility to existing module
systems such as OSGi. </p>
<p> Earlier this year JSR 294 was effectively folded into the
JSR 277 effort. Sun intends now to revive 294 as a separate activity,
with an expanded Expert Group and greater community involvement, in support
of the immediate JDK 7 modularization work as well as the larger goal
of modularizing the Java SE Platform itself. </p>
<p><span>OSGi</span> If JSR 277’s JAM module system is an unsuitable
foundation for modularizing the JDK, what about the <a href="http://osgi.org/About/Technology#Framework">OSGi Framework</a>? This module system is reasonably
mature, stable, and robust. Its core has even already been implemented
within a Java virtual machine, namely that of <a href="http://harmony.apache.org/">Apache Harmony</a>. OSGi is not at all
integrated with the Java language, however, having been built atop the
Java SE Platform rather than from within it. </p>
<p> This last problem can be fixed. Sun plans now to work directly with the
OSGi Alliance so that a future version of the OSGi Framework may fully
leverage the features of JSR 294 and thereby achieve tighter integration
with the language. </p>
<p><span>Jigsaw</span> In order to modularize JDK 7 in the next year
or so, and in order better to inform the work of JSR 294, Sun will
shortly propose to create <i>Project Jigsaw</i> within the <a href="http://openjdk.java.net">OpenJDK Community</a>. </p>
<p> This effort will, of necessity, create a simple, low-level module system
whose design will be focused narrowly upon the goal of modularizing the JDK.
This module system will be available for developers to use in their own code,
and will be fully supported by Sun, but it will not be an official part of
the Java SE 7 Platform Specification and might not be supported by other
SE 7 implementations. </p>
<p> If and when a future version of the Java SE Platform includes a
specific module system then Sun will provide a means to migrate Jigsaw
modules up to that standard. In the meantime we’ll actively seek ways in
which to interoperate with other module systems, and in particular with
OSGi. </p>
<p> All work on Project Jigsaw will be done
completely in the open, in as transparent a manner as possible. We hope
you’ll join us! </p>
<blockquote><i>My thanks to <a href="http://blogs.sun.com/abuckley/">Alex
Buckley</a> for comments on drafts of this entry.</i></blockquote>2008-12-07T04:23:51+00:00Tom Tromey: 8. Pretty printing, Part 2
http://tromey.com/blog/?p=546
<p>In the previous entry we covered the basics of pretty-printing: how printers are found, the use of the <code>to_string</code> method to customize display of a value, and the usefulness of autoloading. This is sufficient for simple objects, but there are a few additions which are helpful with more complex data types. This post will explain the other printer methods used by gdb, and will explain how pretty-printing interacts with MI, the gdb machine interface.</p>
<p>Python-gdb’s internal model is that a value can be printed in two parts: its immediate value, and its children. The immediate value is whatever is returned by the <code>to_string</code> method. Children are any sub-objects associated with the current object; for instance, a structure’s children would be its fields, while an array’s children would be its elements.</p>
<p>When pretty-printing from the CLI, gdb will call a printer’s “<code>children</code>” method to fetch a list of children, which it will then print. This method can return any iterable object which, when iterated over, returns pairs. The first item in the pair is the “name” of the child, which gdb might print to give the user some help, and the second item in the pair is a value. This value can be be a string, or a Python value, or an instance of <code>gdb.Value</code>.</p>
<p>Notice how “pretty-printers” don’t actually print anything? Funny. The reason for this is to separate the printing logic from the data-structure-dissection logic. This way, we can easily implement support for gdb options like “<code>set print pretty</code>” (which itself has nothing to do with this style of pretty-printing — sigh. Maybe we need a new name) or “<code>set print elements</code>“, or even add new print-style options, without having to modify every printer object in existence.</p>
<p>Gdb tries to be smart about how it iterates over the children returned by the <code>children</code> method. If your data structure potentially has many children, you should write an iterator which computes them lazily. This way, only the children which will actually be printed will be computed.</p>
<p>There’s one more method that a pretty-printer can provide: <code>display_hint</code>. This method can return a string that gives gdb (or the MI user, see below) a hint as to how to display this object. Right now the only recognizedd hint is “map”, which means that the children represent a map-like data structure. In this case, gdb will assume that the elements of <code>children</code> alternate between keys and values, and will print appropriately.</p>
<p>We’ll probably define a couple more hint types. I’ve been thinking about “array” and maybe “string”; I assume we’ll find we want more in the future.</p>
<p>Here’s a real-life printer showing the new features. It prints a C++ map, specifically a std::tr1::unordered_map. Please excuse the length — it is real code, printing a complex data structure, so there’s a bit to it. Note that we define a generic iterator for the libstdc++ hash table implementation — this is for reuse in other printers.</p>
<pre>import gdb
import itertools
class Tr1HashtableIterator:
def __init__ (self, hash):
self.count = 0
self.n_buckets = hash['_M_bucket_count']
if self.n_buckets == 0:
self.node = False
else:
self.bucket = hash['_M_buckets']
self.node = self.bucket[0]
self.update ()
def __iter__ (self):
return self
def update (self):
# If we advanced off the end of the chain, move to the next
# bucket.
while self.node == 0:
self.bucket = self.bucket + 1
self.node = self.bucket[0]
self.count = self.count + 1
# If we advanced off the end of the bucket array, then
# we're done.
if self.count == self.n_buckets:
self.node = False
def next (self):
if not self.node:
raise StopIteration
result = self.node.dereference()['_M_v']
self.node = self.node.dereference()['_M_next']
self.update ()
return result
class Tr1UnorderedMapPrinter:
"Print a tr1::unordered_map"
def __init__ (self, typename, val):
self.typename = typename
self.val = val
def to_string (self):
return '%s with %d elements' % (self.typename, self.val['_M_element_count'])
@staticmethod
def flatten (list):
for elt in list:
for i in elt:
yield i
@staticmethod
def format_one (elt):
return (elt['first'], elt['second'])
@staticmethod
def format_count (i):
return '[%d]' % i
def children (self):
counter = itertools.imap (self.format_count, itertools.count())
# Map over the hash table and flatten the result.
data = self.flatten (itertools.imap (self.format_one, Tr1HashtableIterator (self.val)))
# Zip the two iterators together.
return itertools.izip (counter, data)
def display_hint (self):
return 'map'</pre>
<p>If you plan to write lazy <code>children</code> methods like this, I recommend reading up on the <code>itertools</code> package.</p>
<p>Here’s how a map looks when printed. Notice the effect of the “map” hint:</p>
<pre>(gdb) print uomap
$1 = std::tr1::unordered_map with 2 elements = {
[23] = 0x804f766 "maude",
[5] = 0x804f777 "liver"
}</pre>
<p>The pretty-printer API was designed so that it could be used from MI. This means that the same pretty-printer code that works for the CLI will also work in IDEs and other gdb GUIs — sometimes the GUI needs a few changes to make this work properly, but not many. If you are an MI user, just note that the <code>to_string</code> and <code>children</code> methods are wired directly to <code>varobj</code>s; the change you may have to make is that a <code>varobj</code>’s children can change dynamically. We’ve also added new <code>varobj</code> methods to request raw printing (bypassing pretty-printers), to allow efficient selection of a sub-range of children, and to expose the <code>display_hint</code> method so that a GUI may take advantage of customized display types. (This stuff is all documented in the manual.)</p>
<p>Next we’ll learn a bit about scripting gdb. That is, instead of using Python to extend gdb from the inside, we’ll see how to use Python to drive gdb.</p>2008-12-05T19:10:47+00:00David Herron: Using an external library w/ JavaFX app
http://weblogs.java.net/blog/robogeek/archive/2008/12/using_an_extern.html
I've been toying with doing a blog or podcast aggregator with JavaFX. I have a feeling that the strengths of JavaFX, animation, graphics, media, etc, could be put to good use in such an app. Additionally most podcasters put little...2008-12-05T01:27:06+00:00David Herron: JavaFX 1.0 is launched
http://weblogs.java.net/blog/robogeek/archive/2008/12/javafx_10_is_la.html
You can view the updated site, launch videos, sample apps, and more, at javafx.com .. well .. when the server comes back up, it's having a little bit of trouble at this moment. Anyway, I want to post a few...2008-12-05T00:17:10+00:00Tom Tromey: 7. Pretty printing, part 1
http://tromey.com/blog/?p=524
<p>Consider this simple C++ program:</p>
<pre>#include <string>
std::string str = "hello world";
int main ()
{
return 0;
}</pre>
<p>Compile it and start it under gdb. Look what happens when you print the string:</p>
<pre>(gdb) print str
$1 = {static npos = 4294967295,
_M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x804a014 "hello world"}}</pre>
<p>Crazy! And worse, if you’ve done any debugging of a program using libstdc++, you’ll know this is one of the better cases — various clever implementation techniques in the library will send you scrambling to the gcc source tree, just to figure out how to print the contents of some container. At least with string, you eventually got to see the contents.</p>
<p>Here’s how that looks in python-gdb:</p>
<pre>(gdb) print str
$1 = hello world</pre>
<p>Aside from the missing quotes (oops on me), you can see this is much nicer. And, if you really want to see the raw bits, you can use “<code>print /r</code>“.</p>
<p>So, how do we do this? Python, of course! More concretely, you can register a pretty-printer class by matching the name of a type; any time gdb tries to print a value whose type matches that regular expression, your printer will be used instead.</p>
<p>Here’s a quick implementation of the <code>std::string</code> printer (the real implementation is more complicated because it handles wide strings, and encodings — but those details would obscure more than they reveal):</p>
<pre>class StdStringPrinter:
def __init__(self, val):
self.val = val
def to_string(self):
return self.val['_M_dataplus']['_M_p'].string()</pre>
<pre>gdb.pretty_printers['^std::basic_string<char,.*>$'] = StdStringPrinter</pre>
<p>The printer itself is easy to follow — an initializer that takes a value as an argument, and stores it for later; and a <code>to_string</code> method that returns the appropriate bit of the object.</p>
<p>This example also shows registration. We associate a regular expression, matching the full type name, with the constructor.</p>
<p>One thing to note here is that the pretty-printer knows the details of the implementation of the class. This means that, in the long term, printers must be maintained alongside the applications and libraries they work with. (Right now, the libstdc++ printers are in archer. But, that will change.)</p>
<p>Also, you can see how useful this will be with the auto-loading feature. If your program uses libstdc++ — or uses a library that uses libstdc++ — the helpful pretty-printers will automatically be loaded, and by default you will see the contents of containers, not their implementation details.</p>
<p>See how we registered the printer in <code>gdb.pretty_printers</code>? It turns out that this is second-best — it is nice for a demo or a quick hack, but in production code we want something more robust.</p>
<p>Why? In the near future, gdb will be able to debug multiple processes at once. In that case, you might have different processes using different versions of the same library. But, since printers are registered by type name, and since different versions of the same library probably use the same type names, you need another way to differentiate printers.</p>
<p>Naturally, we’ve implemented this. Each <code>gdb.Objfile</code> — the Python wrapper class for gdb’s internal <code>objfile</code> structure (which we briefly discussed in an earlier post) — has its own <code>pretty_printers</code> dictionary. When the “<code>-gdb.py</code>” file is auto-loaded, gdb makes sure to set the “current objfile”, which you can retrieve with “<code>gdb.get_current_objfile</code>“. Pulling it all together, your auto-loaded code could look something like:</p>
<pre>import gdb.libstdcxx.v6.printers
gdb.libstdcxx.v6.printers.register_libstdcxx_printers(gdb.get_current_objfile())</pre>
<p>Where the latter is defined as:</p>
<pre>def register_libstdcxx_printers(objfile):
objfile.pretty_printers['^std::basic_string<char,.*>$'] = StdStringPrinter</pre>
<p>When printing a value, gdb first searches the <code>pretty_printers</code> dictionaries associated with the program’s objfiles — and when gdb has multiple inferiors, it will restrict its search to the current one, which is exactly what you want. A program using libstdc++.so.6 will print using the v6 printers, and (presumably) a program using libstdc++.so.7 will use the v7 printers.</p>
<p>As I mentioned in the previous post, we don’t currently have a good solution for statically-linked executables. That is, we don’t have an automatic way to pick up the correct printers. You can always write a custom auto-load file that imports the right library printers. I think at the very least we’ll publish some guidelines for naming printer packages and registration functions, so that this could be automated by an IDE.</p>
<p>The above is just the simplest form of a pretty-printer. We also have special support for pretty-printing containers. We’ll learn about that, and about using pretty-printers with the MI interface, next time.</p>2008-12-04T17:56:39+00:00Gary Benson: Fedora 10
http://gbenson.net/?p=109
<p>Apparently Fedora 10’s eclipse-ecj doesn’t have gcj-compiled libraries any more. Never mind:
<pre>mkdir /usr/lib/gcj/eclipse-ecj
aot-compile -c "-O3" /usr/lib/eclipse/dropins/jdt/plugins /usr/lib/gcj/eclipse-ecj
rebuild-gcj-db</pre>
<p>Also, whilst I’m messing with my system, I’ve always had to do the following for ppc64 builds to work:
<pre>mkdir -p /usr/lib/jvm/java-gcj/jre/lib/ppc64/server
ln -s /usr/lib64/gcj-4.3.2/libjvm.so /usr/lib/jvm/java-gcj/jre/lib/ppc64/server</pre>
<p>I never figured out how anyone else manages without this. Maybe nobody else is trying to build two platforms on the one box.</p></p></p>2008-12-04T11:46:37+00:00Joe Darcy: Hexadecimal Floating-Point Literals
http://blogs.sun.com/darcy/entry/hexadecimal_floating_point_literals
<p>
One of the more obscure language changes included back in JDK 5 was the addition of <i>hexadecimal floating-point literals</i> to the platform. As the name implies, hexadecimal floating-point literals allow literals of the <tt>float</tt> and <tt>double</tt> types to be written primarily in base 16 rather than base 10. The underlying primitive types use binary floating-point so a base 16 literal avoids various decimal ↔ binary rounding issues when there is a need to specify a floating-point value with a particular representation.
</p>
<p>
The conversion rule for decimal strings into binary floating-point values is that the binary floating-point value nearest the exact decimal value must be returned. When converting from binary to decimal, the rule is more subtle: the shortest string that allows recovery of the same binary value in the same format is to be used. While these rules are sensible, surprises are possible from the differing bases used for storage and display. For example, the numerical value 1/10 is <em>not</em> exactly representable in binary; it is a binary repeating fraction just as 1/3 is a repeating fraction in decimal. Consequently, the numerical values of <tt>0.1f</tt> and <tt>0.1d</tt> are <em>not</em> the same; the exact numeral value of the comparatively low precision <tt>float</tt> literal <tt>0.1f</tt> is <br />
0.100000001490116119384765625<br />
and the shortest string that will convert to this value as a <tt>double</tt> is <br />
0.10000000149011612.<br />
This in turn differs from the exact numerical value of the higher precision <tt>double</tt> literal <tt>0.1d</tt>,<br />
0.1000000000000000055511151231257827021181583404541015625. Therefore, based on decimal input, it is not always clear what particular binary numerical value will result.
</p>
<p>
Since floating-point arithmetic is almost always approximate, dealing with some rounding error on input and output is usually benign. However, in some cases it is important to exactly specify a particular floating-point value. For example, the Java libraries include constants for the
<a href="http://java.sun.com/javase/6/docs/api/java/lang/Double.html#MAX_VALUE">
largest finite</a>
<tt>double</tt> value, numerically equal to (2-2<sup>-52</sup>)·2<sup>1023</sup>, and the
<a href="http://java.sun.com/javase/6/docs/api/java/lang/Double.html#MIN_VALUE">
smallest nonzero value</a>, numerically equal to 2<sup>-1074</sup>. In such cases there is only one right answer and these particular limits are derived from the binary representation details of the corresponding IEEE 754 <tt>double</tt> format. Just based on those binary limits, it is not immediately obvious how to construct a minimal length decimal string literal that will convert to the desired values.
</p>
<p>
Another way to create floating-point values is to use a bitwise conversion method, such as
<tt><a href="http://java.sun.com/javase/6/docs/api/java/lang/Double.html#doubleToLongBits(double)">doubleToLongBits</a></tt>
and
<tt><a href="http://java.sun.com/javase/6/docs/api/java/lang/Double.html#longBitsToDouble(double)">longBitsToDouble</a></tt>.
However, even for numerical experts this interface is inhumane since all the gory bit-level encoding details of IEEE 754 are exposed and values created in this fashion are not regarded as
<a href="http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.28">constants</a>.
Therefore, for some use cases it helpful to have a textual representation of floating-point values that is simultaneously human readable, clearly unambiguous, and tied to the binary representation in the floating-point format. Hexadecimal floating-point literals are intended to have these three properties, even if the readability is only in comparison to the alternatives!
</p>
<p>
Hexadecimal floating-point literals originated in C99 and were later included in the recent <a href="http://en.wikipedia.org/wiki/IEEE_754-2008">revision of the IEEE 754 floating-point standard</a>.
The grammar for these literals in Java is given in
<a href="http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.10.2">JLSv3 §3.10.2</a>:</p>
<blockquote>
<dl>
<dt><p><i>HexFloatingPointLiteral</i>:</p>
<dd> <p><i>HexSignificand BinaryExponent FloatTypeSuffix<sub>opt</sub></i></p>
</dd></dt></dl>
</blockquote>
<p>
This readily maps to the sign, significand, and
exponent fields defining a finite floating-point value; <i>sign</i><b><tt>0x</tt></b><i>significand</i><b><tt>p</tt></b><i>exponent</i>.
This syntax allows the literal </p>
<blockquote>
<p><tt>0x1.8p1</tt></p>
</blockquote>
<p>
to be to used represent the value 3; 1.8<sub>hex</sub> × 2<sup>1</sup> = 1.5<sub>decimal</sub> × 2 = 3.
More usefully, the maximum value of <br />
(2-2<sup>-52</sup>)·2<sup>1023</sup> can be written as<br />
<tt>0x1.fffffffffffffp1023</tt><br />
and the minimum value of <br />
2<sup>-1074</sup> can be written as<br />
<tt>0x1.0P-1074</tt> or <tt>0x0.0000000000001P-1022</tt>, which are clearly mappable to the various fields of the floating-point representation while being much more scrutable than a raw bit encoding.
</p>
<p>
Retroactively reviewing the possible <a href="http://blogs.sun.com/darcy/entry/so_you_want_to_change">steps</a> needed to add hexadecimal floating-point literals to the language:</p>
<ol>
<li><p><b>Update the Java Language Specification</b>: As a purely syntactic changes, only a single section of the JLS had to updated to accommodate hexadecimal floating-point literals.
</p>
<li><p><b>Implement the language change in a compiler</b>: Just the lexer in <tt>javac</tt> had to be modified to recognize the new syntax; <tt>javac</tt> used new platform library methods to do the actual numeric conversion.
</p>
<li><p><b>Add any essential library support</b>: While not strictly necessary, the usefulness of the literal syntax is increased by also recognizing the syntax in
<tt><a href="http://java.sun.com/javase/6/docs/api/java/lang/Double.html#parseDouble(java.lang.String)">Double.parseDouble</a></tt> and similar methods and outputting the syntax with <tt><a href="http://java.sun.com/javase/6/docs/api/java/lang/Double.html#toHexString(double)">Double.toHexString</a></tt>; analogous support was added in corresponding <tt>Float</tt> methods. In addition the new-in-JDK 5 Formatter "<tt>printf</tt>" facility included the <a href="http://java.sun.com/javase/6/docs/api/java/util/Formatter.html#dndec"><tt>%a</tt> format</a> for hexadecimal floating-point.
</p>
<li><p><b>Write tests</b>: Regression tests (under <tt>test/java/lang/Double</tt> in the JDK workspace/repository) were included as part of the library support
(<a href="http://bugs.sun.com/view_bug.do?bug_id=4826774" title="Add library support for hexadecimal floating-point strings">4826774</a>).
</p>
<li><p><b>Update the Java Virtual Machine Specification</b>: No JVMS changes were needed for this feature.
</p>
<li><p><b>Update the JVM and other tools that consume classfiles</b>: As a Java source language change, classfile-consuming tools were not affected.
</p>
<li><p><b>Update the Java Native Interface (JNI)</b>: Likewise, new literal syntax was orthogonal to calling native methods.
</p>
<li><p><b>Update the reflective APIs</b>: Some of the reflective APIs in the platform came after hexadecimal floating-point literals were added; however, only an API modeling the syntax of the language, such as the <a href="http://java.sun.com/javase/6/docs/technotes/guides/javac/index.html">tree API</a> might need to be updated for this kind of change.
</p>
<li><p><b>Update serialization support</b>: New literal syntax has no impact on serialization.
</p>
<li><p><b>Update the javadoc output</b>: One possible change to javadoc output would have been supplementing the existing entries for floating-point fields in the <a href="http://java.sun.com/javase/6/docs/api/constant-values.html">constant fields values page</a> with hexadecimal output; however, that change was not done.
</p>
</li></li></li></li></li></li></li></li></li></li></ol>
<p>
In terms of language changes, adding hexadecimal floating-point literals is about as simple as a language change can be, only straightforward and localized changes were need to the JLS and compiler and the library support was clearly separated. Hexadecimal floating-point literals aren't applicable to that many programs, but when they can be used, they have extremely high utility in allowing the source code to clearly reflect the precise numerical intentions of the author.
</p>2008-12-04T08:00:02+00:00Joe Darcy: Build architectures and managing dependencies
http://blogs.sun.com/darcy/entry/build_architectures_and_managing_dependencies
<p>
Since the OpenJDK source was released, there have been various discussions about aspects of the build architecture, including how dependencies on third parties libraries should be managed. For example, on a Linux system should the JDK use its own libzip or the libzip that comes with the distribution?
I think the appropriate answers to these and related question hinge on whether the final deliverable from the OpenJDK project is viewed as the source code itself or a binary built from the source.
</p>
<p>
Traditionally before OpenJDK, the end result of the Sun's JDK project that most people used were the JDK and JRE binaries. These binaries were meant to be universal in the sense of being usable on a given processor family across a version range of operating systems. For example, there was a single windows x86 binary for use on, say, Windows NT, Windows XP, etc., a single Solaris SPARC binary for use across Solaris 8 through Solaris 10, and effectively a single Linux x86 binary for use across different Linux distributions.
</p>
<p>
This "single binary" model drives decisions about what platform to produce the binary on, generally an older release, and what assumptions can be made about available system resources, generally rather weak ones. With a single binary deliverable, since fewer environment resources can be relied on, making the JDK build self-contained is necessary for it to be reliable in a wide variety of environments. With this delivery architecture, there is some justification to, for example, including a copy a library like libzip in the JDK build rather than relying on a system library, even though there are increased maintenance costs.
</p>
<p>
However, when an OpenJDK/IcedTea binary is being built on a particular Linux distribution for use only on that distribution, the constraints are different. If the build is being done by the OS vendor, the vendor controls the OS contents and knows whether or not system libraries like libzip are reliable and kept up to date. Since stronger assumptions can be made about the host environment, weaker conditions need to be fulfilled by the JDK source tree. For an OS vendor, relying on a single copy of native libraries for the OS and the JDK is preferable to building (and maintaining) multiple copies.
</p>
<p>
Going forward, I'd expect the JDK build to evolve to better accommodate options to use host platform resources.
Perhaps modules systems in the future can help manage such dependencies more transparently.
</p>2008-12-04T08:00:01+00:00Dalibor Topic: Conference circuit roundup: FOSDEM, DeVoxx and more
http://robilad.livejournal.com/41779.html
If you are not reading the <a href="http://www.kaffe.org">Kaffe</a>, <a href="http://gcc.gnu.org/java/">gcj</a>, <a href="http://classpath.org">Classpath</a> or <a href="http://openjdk.java.net">OpenJDK</a> mailing lists on a daily basis, you may have missed that we are continuing a fine tradition of meeting in a developer room at <a href="http://fosdem.org">FOSDEM</a> again - our developer room <a href="http://mail.openjdk.java.net/pipermail/discuss/2008-November/001360.html">request</a> was <a href="http://mail.openjdk.java.net/pipermail/discuss/2008-December/001393.html">approved</a> earlier this week by the FOSDEM organizers. <br /><br />With my friendly ad hoc FOSDEM meeting committee hat, I'll say that FOSDEM is just plain great, there is no other way to put it. In the past years we've turned our dev room into a lightning talk fest on all kinds of Java Libre projects issues (and more!), and I hope we'll continue that fine tradition, while making more room for discussions and debates in the schedule this year. <br /><br />Since we don't know yet how large the room we get will be, and other small details, the <a href="http://wiki.debian.org/Java/DevJam/2009/Fosdem">wiki</a> is currently light on content, but as we are using the tried and proven procedure of letting the dev room content evolve on the wiki, while politely poking people to sign up and offer subjects they want to talk about, it'll all appear as we go in the coming weeks. Meanwhile, if you're planning to come, please sign up so that we can have an estimate of how many people will join us for the talks and our regular dev room dinner event. If you are a FOSDEM Java Libre dev room regular, make sure to notice the shift from the regular pattern in the past: FOSDEM '09 is on February 7th/8th, rather then at the end of the month. It's still in Brussels, Belgium, of course!<br /><br />Coming up a lot sooner in Belgium is <a href="http://devoxx.com">DeVoxx</a>, next week in Antwerp. I'll have a little <a href="http://devoxx.com/display/JV08/The+Evolution+of+Java+software+on+GNU+Linux">talk</a> there, and I'm sure <a href="http://blogs.sun.com/mr/entry/jigsaw">Mark Reinhold</a>, <a href="http://blogs.sun.com/mr/entry/jigsaw">Alex Buckley</a> and others will have interesting things to say in their sessions on <a href="http://blogs.sun.com/mr/entry/jigsaw">Project Jigsaw</a>. I'll be there from Tuesday until Friday, and hope to catch up with a lot of people I haven't met in a while.<br /><br />Finally, about right between DeVoxx and FOSDEM, (except that it's on another continent) is the <a href="https://developerdays.dev.java.net/nonav/overview.html">M3DD conference</a> that I've mentioned in the previous <a href="http://robilad.livejournal.com/41556.html">entry</a>. I forgot to mention that the early bird registration deadline for M3DD is in two days, on Friday. The <a href="http://robilad.livejournal.com/40483.html">deadlines</a> for submissions for Community One and Java One are approaching very quickly, too.2008-12-04T00:03:22+00:00Joe Darcy: OpenJDK 6 b13 and JCK testing
http://blogs.sun.com/darcy/entry/openjdk_6_b13_and_jck
<p>
The JCK tests probe the conformance of a Java platform implementation to a specification. For example, <a href="http://blogs.sun.com/darcy/entry/matching_jdk_and_jck_versions">JCK 6b is the current test suite</a> to determine conformance to the Java SE 6 spec. Official claims of conformance require not only passing the complete set of relevant tests, but also meeting the other requirements spelled out in the
<a href="http://openjdk.java.net/groups/conformance/docs/JCK6bUsersGuide/html/index.html
">JCK user's guide</a>.
</p>
<p>
Regarding the JCK, conformance is measured with respect to a binary rather than to a source base directly, which is sensible since a Java platform implementation will typically rely on and be affected by the properties of the host environment, including the OS, the C compiler, and the processor.
</p>
<p>
Previously Red Hat announced that using OpenJDK sources augmented with IcedTea patches, an OpenJDK binary on Fedora 9 <a href="http://blog.softwhere.org/archives/196">passed the JCK</a> and met the other conformance requirements.
</p>
<p>
Amongst other changes, after incorporating community-developed patches
(notably
<a href="http://bugs.sun.com/view_bug.do?bug_id=6748251" title="Apply IcedTea midi sound patch">6748251</a> in b13) and following the OpenJDK 6 build instructions, inside Sun a binary resulting from building the unmodified OpenJDK 6 b13 sources on Redhat Enterprise AS 2.1 with gcc 2.95 (the official Linux build platform for Sun's 6 update releases) passed all the JCK 6b tests when run on Fedora Core 8 x86. That binary also meets all the other JCK requirements.
</p>
<p>
OpenJDK 6 binaries built from b13 (and later) sources on and for different host environments are now more likely to share those favorable conformance properties, but testing would be necessary to verify conformance status and to make any formal statements.
</p>
<p><b>More information</b></p>
<ul>
<li><p>
<a href="http://www.sun.com/software/opensource/java/faq.jsp#k
">Free and Open Source Java FAQ on TCKs</a>
</p>
<li><p>
<a href="http://openjdk.java.net/groups/conformance/">OpenJDK Conformance Group</a>
</p>
</li></li></ul>2008-12-03T23:56:27+00:00Joe Darcy: OpenJDK 6: Some regression test results for b14
http://blogs.sun.com/darcy/entry/openjdk_6_some_regression_test2
<p>
Running with the usual <tt>jtreg</tt> flags, <tt>-a -ignore:quiet</tt> always and <tt>-s</tt> for the <tt>langtools</tt> area, the basic regression test results on Linux for
<a href="http://blogs.sun.com/darcy/entry/openjdk_6_sources_for_b14">OpenJDK 6 build 14</a> are:
</p>
<ul>
<li><p><a href="http://blogs.sun.com/darcy/resource/OpenJDK_6/b14-hotspot-linux-summary.txt">HotSpot</a>, 3 tests passed.
</p>
<li><p><a href="http://blogs.sun.com/darcy/resource/OpenJDK_6/b14-langtools-linux-summary.txt">Langtools</a>, 1,351 tests passed.
</p>
<li><p><a href="http://blogs.sun.com/darcy/resource/OpenJDK_6/b14-jdk-linux-summary.txt">JDK</a>, 3,077 tests pass, 26 tests fail, 3 tests have errors.
</p>
</li></li></li></ul>
<p>
In this build, we upgraded from a HotSpot 10 base to HotSpot 11. HotSpot 11 is also being used in the 6u10 release. The set of included tests for the HotSpot versions differ:
</p>
<blockquote>
<pre>
0: b13-hotspot/summary.txt pass: 5
1: b14-hotspot/summary.txt pass: 3
0 1 Test
pass --- compiler/6547163/Test.java
pass --- compiler/6563987/Test.java
pass --- compiler/6571539/Test.java
pass --- compiler/6595044/Main.java
--- pass compiler/6663621/IVTest.java
--- pass compiler/6724218/Test.java
6 differences
</pre>
</blockquote>
<p>
In <tt>langtools</tt> all the tests continue to pass:
</p>
<blockquote>
<pre>
0: ./b13-langtools/summary.txt pass: 1,351
1: ./b14-langtools/summary.txt pass: 1,351
No differences
</pre>
</blockquote>
<p>
And in <tt>jdk</tt>, a few new tests were added in b14 and the existing tests have generally consistent results:
</p>
<blockquote>
<pre>
0: b13-jdk/summary.txt pass: 3,072; fail: 23; error: 3
1: b14-jdk/summary.txt pass: 3,077; fail: 26; error: 3
0 1 Test
--- fail com/sun/org/apache/xml/internal/ws/server/Test.java
pass fail java/awt/TextArea/UsingWithMouse/SelectionAutoscrollTest.html
--- pass java/awt/image/ConvolveOp/EdgeNoOpCrash.java
--- pass javax/management/monitor/DerivedGaugeMonitorTest.java
pass fail javax/swing/JColorChooser/Test6541987.java
--- pass javax/swing/JFileChooser/6484091/bug6484091.java
--- pass sun/management/jmxremote/LocalRMIServerSocketFactoryTest.java
--- pass sun/nio/cs/TestUTF8.java
--- pass sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/EmptyExtensionData.java
--- pass tools/pack200/MemoryAllocatorTest.java
10 differences
</pre>
</blockquote>2008-12-03T19:44:47+00:00