JSR 355, JCP Executive Committee Merge, has been posted this week for JSR Review, with the JSR Review Ballot scheduled for 7-20 February. From Section 2.1 of the JSR proposal, this JSR proposes to make changes to the JCP's Process Document and the Executive Committee's Standing Rules with the goal of merging the two Executive Committees into one and reducing the total number of Executive Committee members from the current total of 32. The existing two-to-one ratio of ratified to elected seats will be maintained. On the merged EC neither Oracle nor any other member may hold more than one seat.

Heather Vancura-Chilson, group manager of the JCP PMO in a blog post on JSR 355.

This is a followup to my earlier post on converting the Emacs C code into Common Lisp.  This one is a bit more technical, diving into some specifics of the conversion process.

Basics

One important fact is that we do not need to convert an arbitrary C program to Common Lisp.  This might or might not be efficiently possible — but we do not care.  We only need to convert Emacs.  This is simpler for two reasons.  First, we can just ignore any C construct that Emacs does not use.  If the translator barfs after some new update, we can fix it then.  Second, Emacs itself is already written in a relatively Lispy style, being a Lisp implementation itself.  We further exploit this by allowing the translator to know some details about Emacs.  As a trivial example, all the Smumble globals created by the DEFUN marco need not be translated into Common Lisp as structure constants — they are an artifact of the implementation, and will show up directly in the generated defuns instead.

What to ignore

A good portion of Emacs is simply redundant in the CL world.  There are a few types (cons, vector, integers, functions) that are shareable — in fact, sharing these is part of the goal of this effort.  There are also a number of functions which are effectively identical.  There are also entire redundant modules, like the garbage collector, or the bytecode interpreter.

The question is how to have the translator differentiate between what is useful and what is not, without breaking builds of future versions of Emacs.

I don’t currently think there is a high road to solving this problem.  For modules like the GC, I plan to have ad hoc translator rules for the particular source files.  For functions and data types, I’m adding new GCC attributes that I can use to mark the ignorable definitions.

Types

There are two type-related issues that arise when translating the source.

First, how should Emacs-specific types be represented?  Primarily these types are structures, like struct buffer or struct string (we cannot use the CL string type, because Emacs adds properties directly to the string, and Emacs has its own idiosyncratic character handling).  My answer here is to just straightforwardly translate them to defstruct.

The other question is when translating a C function, what do we do with the types of local variables?  For the most part I am pretending that they don’t exist.  This works fine except for local arrays and structures, but these are easily handled by initializing variables properly. My rationale is that while this is slower, it lets me get something working more quickly, and we can always update the translator to emit CL type declarations later on.

This simple approach doesn’t actually cover all the needed cases.  For example, there is code in Emacs that takes the address of a local variable and passes it somewhere.  This is easy to deal with; much of the remaining work is just digging through the code looking for special cases to clean up.

I’m similarly omitting type declarations from the generated structures.  One possible nice side effect of this approach is that it will make it easier to lift Emacs’ file-size restrictions, because there will no longer be any code assuming that the size is a fixnum.

Macros

Many low-level details of the Emacs implementation are hidden in macros.  For example, Emacs stuffs some type information into the low-order bits of pointers.  It uses macros to add or remove this information.  For this build, I redefine these macros to do nothing.  This makes the GCC Gimple representation much closer to the abstract meaning of the program, and thus simpler to translate.

There are also some macros that are useful to redefine so that we can more easily hook into them from the translator.  For example, Emacs has a C macro INTEGERP that is used to check whether its argument is an integer.  Normally this macro uses bit twiddling to get its answer, but I redefine it like so:

#undef INTEGERP
extern Lisp_Object *INTEGERP (Lisp_Object)
    __attribute__((lisp_form("integerp")));

Example

The translator is not nearly complete, but it can already do a fair job at translating simple functions.  For example, here is “forward-point” from the Emacs C code:

DEFUN ("forward-point", Fforward_point, Sforward_point, 1, 1, 0,
       doc: /* Return buffer position N characters after (before if N negative) point.  */)
  (Lisp_Object n)
{
  CHECK_NUMBER (n);

  return make_number (PT + XINT (n));
}

Here is what the translator comes up with:

(defun Fforward_point (n)
  (let (
    temp-var-0
    Qintegerp.316
    temp-var-1
    current_buffer.317
    temp-var-2
    )
    (block nil (tagbody
      bb-0
        ; no gimple here
      bb-1
        ; no gimple here
      bb-2
        (setf temp-var-0 (integerp n))
        (if (== temp-var-0 nil)
          (go bb-3)
          (go bb-4))
      bb-3
        (setf Qintegerp.316 Qintegerp)
        (wrong_type_argument Qintegerp.316 n)
      bb-4
        (setf current_buffer.317 current_buffer)
        (setf temp-var-2 (buffer-pt current_buffer.317))
        (setf temp-var-1 (+ temp-var-2 n))
        (return temp-var-1)
  ))))

(defun elisp:forward-point (arg0)
  (Fforward_point arg0))

The output looks pretty weird, because the translator works after GCC’s CFG is built, and so the most straightforward translation is to use this mess with tagbody.  I doubt this matters much, but in any case the translator is readily hackable — it is still less than 400 lines of Python, including comments.

One thing to note is the translation of “PT“.  This is actually a macro that refers to the current buffer:

#define PT (current_buffer->pt + 0)

The translator properly turns this into a reference to “buffer-pt“.

Another detail is the handling of packages.  My plan is to put the Emacs implementation into one package, and then any elisp into a second package called “elisp“.  A DEFUN in the C code will actually generate two functions: the internal one, and the elisp-visible one; hence the “elisp:” in the translation.

Next Steps

There’s still a good amount of work to be done.  The converter punts on various constructs; type translation is implemented but not actually wired up to anything; the translator should emit definitions for alien functions; and plenty more.

I’ve been waiting for a while to say this, but we now have JavaFX 2.1 developer preview builds available for Windows, Mac and Linux. From here on out we’ll be putting out developer preview builds for all three platforms. Hopefully that pleases everyone who has been asking for Linux support :-)

Jonathan Giles in a post pointing to the downloads.

Time for a new snapshot. Not too many changes, but the IKVM.Reflection API changes should suggest what I've been working on.

Changes:

• Updated version to 7.1.4406.0.
• Handle Main-Class manifest value that spans multiple lines. Fix for bug #3461012.
• When constructing a generic class loader we can't use GetWrapperFromType() on the type arguments, because they might refer to a subtype that is currently being loaded.
• Made base TypeWrapper resolution lazy for compiled and .NET TypeWrappers.
• Use modopt custom modifiers for methods instead of name mangling and NameSigAttribute.
• Added version info resource to JVM.DLL. Modified version of patch #3472413.
• Added version info resource to ikvm-native-win32-{arch}.dll. Modified version of patch #3472413.
• Added support for delegates with ByRef parameters.
• When a dynamic only interface method ends up being "implemented" by a static or non-public method, it should throw the appropriate exception.
• When instantiating a delegate and the object passed in does not properly implement the delegate's Method interface, bind the delegate to an error stub that throws the appropriate error.
• The right remap filename should be put in the SourceFileAttribute, instead of the last one.
• Stack trace elements in methods in remapped .NET types should not list the source filename as map.xml.
• IKVM.Reflection: FieldInfo.IsAssembly should test for FieldAttributes.Assembly access, not FieldAttributes.Family.
• IKVM.Reflection: Added Module.__FileAlignment property.
• IKVM.Reflection: Added ManifestResourceInfo.__Offset property.
• IKVM.Reflection: Avoid the need for (expensive) ResolveMethod call when emitting debug symbols. Thanks to Miguel Garcia for pointing this out.
• IKVM.Reflection: Add AssemblyName.__Hash property (to expose the hash in an AssemblyRef).
• IKVM.Reflection: Added Module.__EntryPointRVA and Module.__EntryPointToken properties.
• IKVM.Reflection: Added MethodBase.__MethodRVA property.
• IKVM.Reflection: Fixed regression introduced with AssemblyName rewrite. The AssemblyName returned from __GetReferencedAssemblies() should include an empty public key token if the referenced assembly is not strong named.
• IKVM.Reflection: API change. Allow Type.MetadataToken to be called on missing type (it will return 0 or the token hint when the type was forwarded).
• IKVM.Reflection: Added Universe.ResolveType() API that can be used to construct missing types.
• IKVM.Reflection: Fixed various Module.Resolve* methods to throw proper exception when wrong metadata token is supplied.
• IKVM.Reflection: Fixed type parameter binding for missing types.
• IKVM.Reflection: Added Module.__EnumerateCustomAttributeTable() API.
• IKVM.Reflection: Removed Module.__GetDeclarativeSecurityFor() API.
• IKVM.Reflection: Added CustomAttributeData.__Parent API.
• IKVM.Reflection: Added Module.__ImageRuntimeVersion API.

Binaries available here: ikvmbin-7.1.4406.zip

On the road, again and again :)

I finally decided to accept a great opportunity at Red Hat and signed with them!

I will join the Java Team with Andrew[s] and Deepak and all the other great hackers in a really cool team.

I'm not the only new joiner, and it's amazing how things go in the world at times :)

I'm very proud of being at Red Hat, is since ever I wanted this, so you guess how I'm the happiest person ever now :)

Let me share with you two pictures about this: 

The second one comes from one of my contact of Flickr. It's amazing, since she posted this the same day I signed the contract and she was not aware of this. I take it as a good sign :)

Thanks Deepak for this opportunity! 

UPDATE: Seems now that the identity of the mysterious guy is finally revealed :) Cheers Roman!

Just like my good friend Mario, I will join Red Hat, starting from February, 1st. It seems like we only come in pairs, like Laurel & Hardy. I just can’t decide who would be Laurel and who would be Hardy The thing about us is that we don’t just add up. We amplify each other.

I am very excited about this, Red Hat is about the best company I can imagine working for. They stand for all the values that I stand for myself. Let me also document this important step in my life with a picture:

Last year my girlfriend did a training for an important architecture studio in Biel (Switzerland), and one of the projects she was working on more actively has been now selected as a finalist for "Building of the year".

I'm very proud of her! I've seen this project growing from almost zero since you she was updating me for every single small step, and it's quite amazing to see something that on paper looks like:

Actually becomes like this:

Since the election is open to public, if you would like to help us promoting her amazing job, I share with you the link for the voting; either visit: 

http://www.swiss-architects.com/de/projekte/bau-der-woche-detail/33528_janus_sanierung_und_ausbau_stadtmuseum_rapperswil_jona?vote=49 

or:

http://www.swiss-architects.com/de/projekte/reviews_voting/33 and select the project number 49:

Rapperswil-Jona 

You can  vote by clicking on "Mein Favorit" (In the form: Herr is Mr, Frau is Mrs, Vorname is Name and Nachname is family name... well, I think :)

Thanks for helping out!

At long last, after due discussion and review, I've just pushed initial API support for unsigned integer arithmetic into JDK 8! The support is implemented via static methods, primarily on java.lang.Integer and java.lang.Long, that:

• Provide bidirectional conversion between strings and unsigned integers
• Compare values as unsigned
• Compute unsigned divide and remainder

Colloquially, "unsigned integer" means a 32-bit int or 64-bit long value where all the bits are interpreted as contributing to the magnitude. In the unsigned realm, the values of an integer type of a given bit-width range from 0 to 2^width-1 rather than from -(2^width-1) to 2^width-1-1. A feature of the two's complement encoding of Java integers is that the bitwise results for add, subtract, and multiply are the same if both inputs are interpreted as signed values or both inputs are interpretted as unsigned values. (Other encodings like one's complement and signed magnitude don't have this properly.) Therefore, of the basic arithmetic operations, only a separate divide method needs to be provided to operate on values interpreted as unsigned.

To avoid dealing with the overhead of boxed values and to allow reuse of the built-in arithmetic operators, the unsigned API support does not introduce new types like UnsignedInt with instance methods to perform addition, subtraction, etc. However, that lack of separate Java-level unsigned types does mean a programmer can accidentally improperly mix signed and unsigned values. However, new unsigned types aren't the only way to mitigate this hazard. For example, a naming convention of adding a trailing "U" or "_U" to variables holding unsigned values could be adopted. A more structured approach would be to add an @Unsigned annotation type to the platform and apply that annotation to variables and fields holding unsigned values. One of the extra-linguistic checkers to be enabled by JSR 308 could then analyze code for signed/unsigned correctness.

I'm glad these methods are finally in the JDK. Later in JDK 8, there may be a few more fun bit-twiddling additions, such as methods to get the high order bits of a full multiply and methods which throw exceptions on integer overflow instead of wrapping around.

After many years of speaking at JavaOne, I was happy to get notification yesterday that for giving The Heads and Tails of Project Coin this year, I was inducted as a 2011 JavaOne Rock Star.

With Project Coin successfully shipped as part of JDK 7, I'm looking forward to exploring speaking about other topics at JavaOne this year. Perhaps I'll sumbit a proposal for a "lessons from mathematics" talk I've long wanted to give. I've found approaches and results from fields like stocastics and linear algebra can be helpful in other contexts, including language design and API work.

Planet Classpath is offline today, because the US congress is considering legislation that could kill us forever. The legislation is called the PROTECT IP Act (PIPA). This legislation threatens everyone’s freedom of speech, privacy, and security online.

This would unmake the Web, just as proposed in the Stop Online Piracy Act (SOPA). We don’t want that world. Visit AmericanCensorship.org for some options to contact your representatives if you are an American citizen. The Electronic Frontier Foundation has more information on this and other issues central to your freedom online.

We will return tomorrow,

The Management

The IcedTea project provides a harness to build the source code from OpenJDK6 using Free Software build tools, along with additional features such as a PulseAudio sound driver and support for alternative virtual machines.

A new set of releases for the IcedTea6 series is now available, which includes a number of bug fixes for issues reported since the last release. Full details are below.

Please note that, with the imminent release of IcedTea6 1.11, this will be the last release in the 1.8 series. We also generally recommend that users start to investigate Java 1.7 and the 2.0 series of IcedTea releases, as support for the older 1.6 releases will begin to diminish.

What’s New?

New in release 1.10.5 (2012-01-11)

• Backports
  • S7034464: Support transparent large pages on Linux
  • S7037939: NUMA: Disable adaptive resizing if SHM large pages are used
  • S7102369, RH751203: remove java.rmi.server.codebase property parsing from registyimpl
  • S7094468, RH751203: rmiregistry clean up
  • S7103725, RH767129: REGRESSION – 6u29 breaks ssl connectivity using TLS_DH_anon_WITH_AES_128_CBC_SHA
  • S6851973, PR830: ignore incoming channel binding if acceptor does not set one
  • S7091528: javadoc attempts to parse .class files

New in release 1.9.12 (2012-01-11)

• Backports
  • S7102369, RH751203: remove java.rmi.server.codebase property parsing from registyimpl
  • S7094468, RH751203: rmiregistry clean up
  • S7103725, RH767129: REGRESSION – 6u29 breaks ssl connectivity using TLS_DH_anon_WITH_AES_128_CBC_SHA
  • S6851973, PR830: ignore incoming channel binding if acceptor does not set one

New in release 1.8.12 (2012-01-11)

• Backports
  • S7102369, RH751203: remove java.rmi.server.codebase property parsing from registyimpl
  • S7094468, RH751203: rmiregistry clean up
  • S7103725, RH767129: REGRESSION – 6u29 breaks ssl connectivity using TLS_DH_anon_WITH_AES_128_CBC_SHA
  • S6851973, PR830: ignore incoming channel binding if acceptor does not set one

The tarballs can be downloaded from:

• http://icedtea.classpath.org/download/source/icedtea6-1.8.12.tar.gz (sig)
• http://icedtea.classpath.org/download/source/icedtea6-1.9.12.tar.gz (sig)
• http://icedtea.classpath.org/download/source/icedtea6-1.10.5.tar.gz (sig)

SHA256 checksums:

• ddd3eceba02b5511c1c399e0067c6348d2215f49262e9456108dd2da66b937d7 icedtea6-1.8.12.tar.gz
• dfd8c88052aca10ef12ae78ddce883cf2ee308e77624e24127f4b97f19ed733c icedtea6-1.9.12.tar.gz
• 7d0f9e833a42b6af308a34d432431f0528a2efa52d7837aa446d1c4c27161a0c icedtea6-1.10.5.tar.gz

Each tarball is accompanied by a digital signature (available at the above URL + ‘.sig’). This is produced using my public key:

• PGP Key: 248BDC07 (https://keys.indymedia.org/)
• Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07

The following people helped with these releases:

• Deepak Bhole (backport of 7037939, 7034464, 7043564)
• Andrew John Hughes (release management and backports of 7091528, 6851973, 7103725)
• Omair Majid (backport of 7102369)

We would also like to thank the bug reporters and testers!

To get started:

$ tar xzf icedtea6-<ver>.tar.gz
$ cd icedtea6-<ver>

Full build requirements and instructions are in INSTALL:

$ ./configure [--enable-zero --enable-pulse-java --enable-systemtap ...]
$ make

The brand new Tizen SDK got released

Tizen are a new mobile platform with the aim to thrive in a new ecosystem made up of HTML5 and js based applications.

The Tizen SDK includes the Eclipse IDE and an emulator themed after Samsungs new atom-phone reference design. The emulator come pre-installed with a functional Tizen phone system and some sample applications.

Booting up Tizen

The emulator can get started from the Tizen Emulator Manager. I can then connecting to it by running

sdb shell

Under the hood we can find a small Debian GNU/Linux root filsystem, an Xorg server, pulseaudio and many other nice system services just like on regular Linux desktop. This are good because it will enable us to quickly add some new software stacks to Tizen!

OpenJDK on Tizen

After a quick sdb push i had uploaded a pre-built OpenJDK-6 image running the LLVM 3.0 based Shark VM into Tizen and behold: oneslime on Tizen

Thank you Linux foundation for pushing GNU/Linux into mobile phones!

Summary: OpenJDK work fine on Tizen and the Tizen SDK work fine using OpenJDK!

Valgrind 3.7.0 now includes an embedded gdbserver, which is wired to the valgrind innards in the most useful way possible.  What this means is that you can now run valgrind in a special mode (simply pass --vgdb-error=0), then attach to it from gdb, just as if you were attaching to a remote target.  Valgrind will helpfully tell you exactly how to do this.  Then you can debug as usual, and also query valgrind’s internal state as you do so.  Valgrind will also cause the program to stop if it hits some valgrind event, like a use of an uninitialized value.

For example, consider this incorrect program, e.c:

#include 
int main ()
{
  int x;
  x = x > 0 ? x : x + 1;
  return x;
}

After compiling it (calling it /tmp/e), we can start valgrind:

$ valgrind --vgdb-error=0 err
==20836== Memcheck, a memory error detector
==20836== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==20836== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==20836== Command: /tmp/e
==20836==
==20836== (action at startup) vgdb me ...
==20836==
==20836== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==20836==   /path/to/gdb /tmp/e
==20836== and then give GDB the following command
==20836==   target remote | vgdb --pid=20836
==20836== --pid is optional if only one valgrind process is running
==20836==

Now, in Emacs (or another console if you insist) we start gdb on /tmp/e and enter the command above. Valgrind has paused our program at the first instruction. Now we can “continue” to let it run:

Reading symbols from /tmp/e...done.
(gdb) target remote | vgdb --pid=20836
Remote debugging using | vgdb --pid=20836
relaying data between gdb and process 20836
Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug/lib64/ld-2.14.so.debug...done.
done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
[Switching to Thread 20836]
0x0000003a15c016b0 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) c
Continuing.

Now the inferior stops, because we hit a use of an uninitialized value:

Program received signal SIGTRAP, Trace/breakpoint trap.
0x000000000040047c in main () at e.c:5
5	  x = x > 0 ? x : x + 1;
(gdb)

If we look back at the valgrind window, we see:

==20836== Conditional jump or move depends on uninitialised value(s)
==20836==    at 0x40047C: main (e.c:5)

(It would be nice if this showed up in gdb; I’m not sure why it doesn’t.)

Valgrind also provides ways to examine what is happening, via gdb’s monitor command. This is helpfully documented online:

(gdb) monitor help
general valgrind monitor commands:
  help [debug]             : monitor command help. With debug: + debugging commands
[... lots more here ...]

A few improvements are possible; e.g., right now it is not possible to start a new program using valgrind from inside gdb. This would be a nice addition (I think something like “target valgrind“, but other maintainers have other ideas).

I think this is a major step forward for debugging. Thanks to Philippe Waroquiers and Julian Seward for making it happen.

A couple of annoying bugs have been reported since 7.0 was released, so I decided to do an update.

Changes:

• Changed version to 7.0.4335.1.
• FileStore for non-accessible drive should throw exception when trying to create the FileStore, not when accessing the name() or type() properties.
• Graphics2D.clip(null) should only throw NPE for a Component graphics.
• Don't crash when ikvmc -resource: or -externalresource: option doesn't contain an = sign.
• Handle Main-Class manifest value that spans multiple lines. Fix for bug #3461012.
• Informational messages should not be treated as error when -warnaserror is specified. Fix for #3443377.
• Don't enforce pre-1.5 class name rules in ikvmc (since HotSpot doesn't enforce any naming rules for classes loaded by the system (and boot) class loader, by default). Fix for #3443373.
• Fix for #3441959.
• Throwable.addSuppressed() didn't have a proper parameter name.
• Mark getSpace0 with SecuritySafeCritical to avoid getting an exception with .NET 4
• Bug fix. Removed incorrect check for uninitialized objects on backward branch.
• Don't crash when ikvmc -resource: or -externalresource: option doesn't contain an = sign.
• Added AssemblyInformationalVersionAttribute to OpenJDK assemblies (to set the "Product Version"). Part of patch #3458997.
• Include copyright and metadata in IKVM.OpenJDK.Tools.dll. Part of patch #3458997.
• Bug fix. Don't call Finish on unloadable TypeWrapper.
• Bug fix. When constructing a generic class loader we can't use GetWrapperFromType() on the type arguments, because they might refer to a subtype that is currently being loaded.
• Fix. When decoding a NameSigAttribute it is possible that a type does not exist (i.e. is an unloadable) and that results in a warning emitted against the referenced assemblies class loader.
• Suppress annotation custom attributes when enumerating inner classes.
• IKVM.Reflection: Bug fix. FieldInfo.IsAssembly should test for FieldAttributes.Assembly access, not FieldAttributes.Family.

Binaries available here: ikvmbin-7.0.4335.1.zip

Sources: ikvmsrc-7.0.4335.1.zip, openjdk7-b147-stripped.zip

By the end of November 2011 my contract with JP Morgan ended after 17 months. In many ways it was an interesting but difficult time. I could learn a lot of interesting (and not so interesting) things. Unfortunately, not so much technical stuff that I would have liked (I didn’t really expect that), but about how (really) big corporations work (I think they copy from dilbert.com), about software engineering processes and banking stuff. It was quite difficult for me and my family though, I needed to commute from south-west Germany to south-west Switzerland every second week, which was quite a struggle for all of us. I am happy that this is over now.

I took some free time to spend with my family for most of December, and now want to start through with cool new stuff. I am still not 100% sure which way to go. I am currently spending time to work on CacioWeb and want to turn it into a great product for LadyBug. We have some interested customers and could get some funding, so this is an obvious thing to do for the short term. We also have a bunch of other cool ideas in the pipeline. I am not sure if it can provide enough safe income for the long run to feed my family though, which is why I am also currently looking for an employment position in a nice company (if you happen to know a good one – here’s my CV – , let me know!).

To me that’s an exciting start into the new year. It will be interesting to see what will have happened one year from now

The end of 2011 is near.
The Free Java Momentum will be even bigger in 2012.
Have you made your new year’s resolutions yet?
And is attending Free Java @ FOSDEM 2012 on Feb 4 and 5 one of them?
http://wiki.debian.org/Java/DevJam/2012/Fosdem

Or are you even more ambitious and will you submit a talk proposal?
Then please make sure you submit an abstract before the end of the year
to fosdem@developer.classpath.org. Full instructions can be found at:
http://wiki.debian.org/Java/DevJam/2012/Fosdem/CallForParticipation

I’ve started drafting an overview of the current state of our work on Project Jigsaw. Ultimately this will be a fairly long document, but in order to start getting feedback as early possible I’ve published the first part on its own. This initial installment covers design principles, basic definitions, and module declarations; still to come are sections on compilation, packaging, libraries, repositories, the module-system API, and the modularization of the JDK.

The Jigsaw module system is designed to be both approachable and scalable: Approachable by all developers, yet sufficiently scalable to support the modularization of large legacy software systems in general and the JDK in particular. It aims to implement a set of general requirements; its detailed design has been further guided by the following principles:

• Modularity is a language construct — The best way to support modular programming in a standard way in the Java platform is to extend the language itself to support modules. Developers already think about standard kinds of program components such as classes and interfaces in terms of the language. Modules should be just another kind of program component, and like classes and interfaces they should have meaning in all phases of a program’s development.

• Module boundaries should be strongly enforced — A class that is private to a module should be private in exactly the same way that a private field is private to a class. In other words, module boundaries should determine not just the visibility of classes and interfaces but also their accessibility. Without this guarantee it is impossible to construct modular systems capable of running untrusted code securely.

• Static, single-version resolution is usually sufficient — Most applications do not need to add or remove modules dynamically at run time, nor do they need to use multiple versions of the same module simultaneously. The module system should be optimized for common scenarios but also support narrowly-scoped forms of dynamic multi-version resolution motivated by actual use cases such as, e.g., application servers, IDEs, and test harnesses.

There are already plenty of module systems built on top of the Java platform. What’s new about the Jigsaw module system is that it’s designed to be an integral part of the platform. The design assumes the possibility of changing the Java language and the Java virtual machine, thereby enabling both linguistic support for modular programming and secure encapsulation.

For more details see the draft. Please send comments, questions, and suggestions to the jigsaw-dev mailing list. (If you haven’t already subscribed to that list then please do so first, otherwise your message will be discarded as spam.)

This is insane. I’m sitting at a café in Sydney using their hotspot. Went to search for something, and I kept getting strange looking “site not found” pages. Huh? Thy were working a few hours ago. So I started digging.

The café’s upstream ISP is “Optus”, one of the major Australian carriers. To my astonishment I found that Optus’s DNS servers are interfering with Google searches, stealing their DNS lookups and serving results pages on their own (shitty quality) branded search instead! Try https:? No connection; and Google+ wouldn’t load either.

Obviously as soon as realized what’s going on I immediately changed DNS servers to something reliable. Before I did I found a tiny “about this page” link at the bottom of the heinous Optus search results page, where I was told how great this was for me, but how I could opt out of their “default” search engine if I wanted to but was warned this was an “advanced setting”.

Seriously, what do Optus think they’re doing? From a commercial standpoint, do they really think that their captive audience matters to anyone advertising on the web? Of course not, but in the mean time they’re certainly going to alienate customers who just maybe actually do want to use (in this case) Google sites.

There’s a bigger issue, though. Unaltered answers to DNS queries is a backbone of net neutrality. That’s our problem, but once carriers start poisoning nameservers in their own favour it will be but a blink before everyone is doing it to each other and lookups will become worthless. While I’m sure the morons in Marketing who thought that sabotaging DNS queries would be a good idea won’t be worried about the wreckage that will cause for everyone else, such a war wouldn’t be good for any of the companies involved, either. And meanwhile, if they really want everyone to learn how to install an app to “fix” the internet…

Of course, this is only a taste of what we’ll be in for when the communications minister finally gets his compulsory Great Firewall of Australia censorship in place, but one thing at a time. If you’re looking for internet access down here, clearly Optus or anything that uses their network should be blacklisted.

AfC

There appears to be over-reacting and fearism concerning a recent decision to cancel the DLJ project, and subsequently Ubuntu's plan to remove DLJ-based Java packages from their repository.  I'm totally out of the loop of this except for a couple things.  As the former DLJ Project Lead I was still vaguely involved with the management of that project, and recently there was an email exchange between myself, Dalibor and Tom where we decided it would be best to just shut down the DLJ because the OpenJDK had proceeded far enough that the DLJ was simply unnecessary.

Some blog postings on osnews.com and www.omgubuntu.co.uk came to my attention where there are many comments along the lines of "OMG THE SKY IS FALLING AND ORACLE IS EVIL".  Well, sigh. 

There's nothing to worry about here.  It's really very simple.

The DLJ Project was launched at JavaOne 2006 when it looked unlikely that Sun's Java implementation would ever be open sourced, we devised the DLJ Project to provide JDK bundles under a liberal license.  It was meant to help the community easily have a good quality Java implementation on Linux, but then the new CEO declared the creation of the OpenJDK project from the stage of that very same JavaOne.  

Over the course of time the OpenJDK project became really good and it was no longer necessary to maintain the DLJ project.

There's nothing EVIL here .. it's simply that the DLJ project became irrelevant.

Dalibor had a nice post about this a few months ago - http://robilad.livejournal.com/90792.html

Another key feature in the JFreeChart 1.0.14 release is the option to render drop-shadows within plots, aimed at charts that will be rendered on-screen. The effect of this is quite subtle, but noticeable if you compare two charts directly, one with the shadows and one without:

Compare this to the same chart generated without the drop shadow:

I had resisted adding this feature in the past, because it means dropping down to bit-map level operations, and the rest of JFreeChart is based purely on vector primitives...but in the end, there were too many people that wanted this and, like most things in JFreeChart, the developer can configure it however he or she prefers.

Utilising this feature will incur some overhead in memory usage, but is very simple to switch on - simply add the following line near the start of your application (before any charts are created):

ChartFactory.setChartTheme(new StandardChartTheme("JFree/Shadow", true));

There are other more direct ways as well, for example see the setShadowGenerator() method in the XYPlot class.

I have been following the CACAO JVM development on ARM since 2008, back then CACAO was one of the first alternative JVM, to be used instead of Hotspot in combination with the OpenJDK 6 class libraries.

CACAO history dates back to 1997-1998 when CACAO was one of the first JIT compiler to be used instead of SUN’s Java JVM interpreter.

Today CACAO are being used in combination with OpenJDK 6 on architectures like ARM, MIPS and PPC where Oracle have not yet released code for a GPL licensed Hotspot JIT. CACAO are popular, see the Debian OpenJDK-6 popularity contest chart where up to 80% of all the Debian OpenJDK 6 JVM users have picked CACAO to be installed. This trend kept on since the beginning of 2009 up to the summer of 2011.

Carpe diem CACAO JVM!

During the summer of 2011 Oracle released OpenJDK 7 and CACAO users started to abandon the JVM in favour for JamVM, the reason “why?” are that CACAO depends on the HPI API that have been removed from the OpenJDK 7 code base. This means that CACAO currently only work in combination with the “classic” OpenJDK 6. The second black cloud for CACAO JVM on ARM was that all major ARM Linux distributions started to move from “armel” towards the new “armhf” ABI something CACAO do not support. JamVM here provided the ARM Linux distributions and users with a stable and future proof alternative.

If we for a moment forget about the future and focus on today CACAO are in great shape when built from CACAO hg HEAD.

• CACAO are FAST, http://openjdk.gudinna.com/benchmarks/
• CACAO are stable, thanks to Stefan Ring who have been diligent on fixing bugs found in the CACAO JIT codegen.
• CACAO are fresh, the current CACAO hg HEAD contains the rewritten, “still unreleased” C++ version of CACAO its a totally different JVM compared to the last C based release of CACAO 0.99.4.

If you want to experience the CACAO JVM in its finest the do run the latest development version of CACAO in combination with OpenJDK 6, built using the current IcedTea6 head. Run it on ARM “armel”, PPC or MIPS and experience a fast responsive JVM burning brighter than ever before!

My friend and co-worker Sami Wagiaalla has been doing lots of builds of the Eclipse SDK recently. He decided to see where the time was going and wrote up this interesting blog post:

http://wagiaalla.com/2011/11/29/analysing-eclipse-build/

I encourage you to read it if you’re interested in the build of the Eclipse SDK.

In the land of computer programming, newer has almost always meant better. Java was newer than C, and better, right? Python was better than Perl. Duh, Ruby is better than everything, so they’d tell you. But wait, Twitter is written in Scala. Guess that must be the new hotness, eh?

Haskell has been around for quite a while; somehow I had it in my head that it was outdated and only for computer science work. After all, there are always crazy weirdos out there in academia working on obscure research languages — at least, that’s the perspective from industry. After all, we’re the ones getting real work done. All you’re doing is sequencing the human genome. We invented Java 2 Enterprise Edition. Take that, ivory tower.

The newness bias is strong, which is why I was poleaxed to find people I respect like Erik de Castro Lopo and Conrad Parker working hard in, of all things, Haskell. And now they’re encouraging me to program in it, too (surely, cats and dogs are sleeping together this night). On their recommendation I’ve been learning a bit, and much to my surprise, it turns out Haskell is vibrant, improving, and really cutting edge.

The next thing

I get the impression that people are tired of being told that the some cool new thing makes everything else they’ve been doing irrelevant. Yet many professional programmers (and worse, fanboy script kiddies) are always looking to the next big thing, the next cool language. Often the very people you respect about a topic have already moved on to something else (there’s a book deal in it for them if they can write it fast enough).

But still; technology is constantly changing and there’s always pressure to be doing the latest and greatest. I try my best to resist this sort of thing, just in the interest of actually getting anything done. Not always easy, and the opposite trap is to adopt a bunker mentality whereby you defend what you’re doing against all comers. Not much learning going on there either.

There is, however, a difference between the latest new thing and learning something new.

One of the best things about being active in open source is the opportunity to meet people who you can look up to and learn from. I may know a thing or two about operations and crisis and such, but my techie friends and colleagues are my mentors when it comes to software development and computer engineering. One thing they have taught me over the years is the value of setting out deliberately to “stretch” your mind. Specifically, experimenting with a new programming language that is not your day-to-day working environment, but something that will force your to learn new ways of looking at problems. These guys are professionals; they recognize that whatever your working language(s) are, you’re going to keep using them because you get things done there. It’s not about being seduced by the latest cool project that some popular blogger would have you believe is the be-all-and-end-all. Rather, in stretching, you might be able to bring ideas back to your main work and just might improve thereby. I think there is wisdom there.

Should I attempt to learn Haskell?

I’ve had an eye on functional programming for a while now; who hasn’t? Not being from a formal computer science or mathematics background — (“damnit Jim, I’m an engineer, not an english major” when called upon to defend my atrocious spelling) — the whole “omigod, like, everything is function and that’s like, totally cool” mantra isn’t quite as compelling by itself as it might be. But lots of people I respect have been going on about functional programming for a while now, and it seemed a good direction to stretch. So I asked which language should I learn?

My colleagues suggested Haskell for a number of reasons. That cutting edge research was happening there and that increasingly powerful things were being implemented in the compiler and runtime as a result sounded interesting. That Haskell being a pure functional language (I didn’t know yet what that meant but that’s beside the point) would really force me to learn a functional way of doing at things (as opposed to some others where you can do functional things but can easily escape those constraints; pragmatic, perhaps, but since the idea was to learn something new, that made Haskell sound good rather than perceiving this as a limitation). Finally, they claimed that you could express problems concisely (brevity good, though not if it’s so dense that it’s write-only).

Considering a new language (or, within a language, considering various competing frameworks for web applications, graphical user interface, production deployment, etc) my sense is that when we look at such things we are all fairly quick to judge, based on our own private aesthetic. Does it look clean? Can I do things I need to do with this easily? How do the authors conceive of the problem space? (in web programming especially, a given framework will make some things easy and other things nigh on impossible; you need to know what world-view you’re buying into).

I don’t know about you, but elegance by itself and in the abstract is not sufficient. Elegance is probably the most highly valued characteristic of good engineering design, but it must be coupled with practicality. In other words, does the design get the job done? So before I was willing to invest time learning Haskell, I wanted to at least have some idea that I’d be able to use it for something more than just academic curiosity.

Incidentally, I’m not sure the Haskell community does itself many favours by glorifying in how clever you can be in the language; the implied corollary is that you can’t do anything without being exceedingly clever about it. If true, that would be tedious. I get the humour of the commentary that as we gain experience we tend to overcomplicate things, as seen in the many different ways there are to express a factorial function. But I saw that article linked from almost every thread about how clever you can be with Haskell; is that the sort of thing that you want to use as an introduction for newcomers? Given the syntax is so different from what people are used to in mainstream C-derived programming languages, the code there just looks like mush. The fact that there are people who studied mathematics are doing theorem proving in the language is fascinating, but the tone is very elevated as a result. A high bar for a newcomer — even a professional with 25 years programming experience — to face.

It became clear pretty fast that I wouldn’t have the faintest idea what I was looking at, but I still tried to see if I could get a sense of what using Haskell would be like. Search on phrases like “haskell performance”, “haskell in production”, “commercial use of haskell”, “haskell vs scala”, and so on. You get more than enough highly partisan discussion. It’s quick to see people love the language. It’s a little harder to evidence see it being used in anger, but eventually I came across pages like Haskell in Industry and Haskell Weekly News which have lots of interesting links. That pretty much convinced me it’d be worth giving it a go.

A brief introduction

So here I am, struggling away learning Haskell. I guess I’d have to say I’m still a bit dubious, but the wonderful beginner tutorial called Learn You A Haskell For Great Good (No Starch Press) has cute illustrations. :) The other major starting point is Real World Haskell (O’Reilly). You can flip through it online as well, but really, once you get the idea, I think you’ll agree it’s worth having both in hard copy.

Somewhere along the way my investigations landed me on discussion of something called “software transactional memory” as an approach to concurrency. Having been a Java person for quite some years, I’m quite comfortable with multi-threading [and exceptionally tired of the rants from people who insist that you should only write single threaded programs], but I’m also aware that concurrency can be hard to get right and that solving bugs can be nasty. The idea of applying the database notion of transactions to memory access is fascinating. Reading about STM led me to this (short, language agnostic) keynote given at OSCON 2007 by one Simon Peyton-Jones, an engaging speaker and one of the original authors of GHC. Watching the video, I heard him mention that he had done an “introduction to Haskell” earlier in the conference. Huh. Sure enough, linked from here, are his slides and the video they took.

Watching the tutorial implies a non-trivial investment in time, and a bit of care to manually track the slides with him as he is presenting, but viewing it all the way through was a very rewarding experience. By the time I watched this I’d already read Learn You A Haskell and a goodly chunk of Real World Haskell, but if anything that made it even more fascinating; I suppose I was able to concentrate more on what he was saying for the emphasis on why things in Haskell are the way they were.

I was quite looking forward to how he would introduce I/O to an audience of beginners; like every other neophyte I’m grinding through learning what “monads” are and how they enable pure functional programming to coexist with side effects. Peyton-Jones’s discussion of IO turns up towards the end (part 2 at :54:36), when this definition went up on a slide:

IO (a) :: World -> (a, World)

accompanied by this description:

“You can think of it as a function that takes a World to a pair of a and a new World … a rather egocentric functional programmer’s view of things in which your function is center of the universe, and the entire world sort of goes in one side of your function, gets modified a bit by your function, and emerges, in a purely functional way, in a freshly minted world which comes out the other…”

“Oh, so that’s a metaphor?” asked one of his audience.

“Yes. The world does not actually disappear into your laptop. But you can think of it that way if you like.”

Ha. :)

Isolation and reusability

A moment ago I mentioned practicality. The most practical thing going these days is the web problem, i.e. using a language and its toolchain to do web programming. Ok, so what web frameworks are there for Haskell? Turns out there are a few. Two newer ones in particular, Yesod and the Snap Framework. Their raw performance as web servers looks very impressive, but the real question is how does writing web pages & application logic go down? Yesod’s approach, called “Hamlet“, doesn’t do much for me. I can see why type safety across the various pieces making up a web page would be something you’d aspire to, but it ain’t happening (expecting designers to embed their work in a pseudo-but-not-actually HTML language has been tried before. Frequently. And it’s been a bust every time). Snap, on the other hand, has something called “Heist“. Templates are pure HTML and when you need to drop in programmatically generated snippets you do so with a custom tag that gets substituted in at runtime. That’s alright. As for writing said markup from within code there’s a different project called “Blaze” which looks easy enough to use.

Reading a thread about Haskell web programming, I saw explicit acknowledgement on the part of framework authors from all sides that it would be possible to mix and match, at least in theory. If you like Yesod’s web server but would rather to use Snap’s Heist template engine, you could probably do so. You’d be in for all the glue code and knowing what you’re about, but this still raises an interesting point.

A big deal with Haskell — and one of the core premises of programming in a functional language that emphasizes purity and modularity — is that you can rely on code from other libraries not to interfere with your code. It’s more than just “no global variables”; pure functions are self contained, and when there are side effects (as captured in IO and other monads) they are explicitly marked and segregated from pure code. In IT we’ve talked about reusable code for a long time, and we’ve all struggled with it: the sad reality is that in most languages, when you call something you have few guarantees that nothing else is going to happen over and above what you’ve asked for. The notion of a language and its runtime explicitly going out of its way to inhibit this sort of thing is appealing.

Hello web, er world

Grandiose notions aside, I wanted to see if I could write something that felt “clean”, even if I’m not yet proficient in the language. I mentioned above that I liked the look of Snap. So, I roughed out some simple exercises of what using the basic API would be like. The fact that I am brand new at Haskell of course meant it took a lot longer than it should have! That’s ok, I learnt a few things along the way. I’ll probably blog separately about it, but after an essay about elegance and pragmatism, I thought I should close with some code. The program is just a little ditty that echos your HTTP request headers back to you, running there. You can decide for yourself if the source is aesthetically pleasing; ’tis a personal matter. I think it’s ok, though I’m not for a moment saying that it’s “good” style or anything. I will say that with Haskell I’ve already noticed that what looks deceptively simple often takes a lot of futzing to get the types right — but I’ve also noticed that when something does finally compile, it tends to be very close to being done. Huh.

So here I am freely admitting that I was quite wrong about Haskell. It’s been a bit of a struggle getting started, and I’m still a bit sceptical about the syntax, but I think the idea of leveraging Haskell shows promise, especially for server-side work.

AfC

Over the coming weeks, I aim to post a few entries highlighting some of the new features in JFreeChart 1.0.14. I hope also that the examples (there will be source code) will encourage developers to experiment with the multitude of settings in JFreeChart to customise the appearance of their charts. It is a common (and fair) criticism that the default "look" in JFreeChart is dated (some even say ugly but they are not very polite)...but with a few calls to the right API methods, you can radically change the resulting output.

I'll start with the new support for Java's RadialGradientPaint in pie charts, which gives an opportunity for developers to liven up the appearance of these charts with only a small amount of additional effort (you need Java 6 or later for this to work, since RadialGradientPaint does not exist in earlier Java runtimes). You can simply call the existing setSectionPaint() method of the PiePlot class and pass it a RadialGradientPaint instance, as the following example illustrates:

Here is the corresponding source code:

/* -----------------
 * PieChartDemo.java
 * -----------------
 * (C) Copyright 2011, by Object Refinery Limited.
 */

package demo;

import java.awt.BasicStroke;
import java.awt.Color;
import java.awt.Dimension;
import java.awt.Font;
import java.awt.GradientPaint;
import java.awt.Point;
import java.awt.RadialGradientPaint;
import java.awt.geom.Point2D;

import javax.swing.JPanel;

import org.jfree.chart.ChartFactory;
import org.jfree.chart.ChartPanel;
import org.jfree.chart.JFreeChart;
import org.jfree.chart.StandardChartTheme;
import org.jfree.chart.plot.PiePlot;
import org.jfree.chart.title.TextTitle;
import org.jfree.data.general.DefaultPieDataset;
import org.jfree.data.general.PieDataset;
import org.jfree.ui.ApplicationFrame;
import org.jfree.ui.HorizontalAlignment;
import org.jfree.ui.RectangleEdge;
import org.jfree.ui.RectangleInsets;
import org.jfree.ui.RefineryUtilities;

/**
 * A demo for a pie chart using RadialGradientPaint in JFreeChart 1.0.14.
 */
public class PieChartDemo extends ApplicationFrame {

    private static final long serialVersionUID = 1L;

    {
        // set a theme using the new shadow generator feature available in
        // 1.0.14 - for backwards compatibility it is not enabled by default
        ChartFactory.setChartTheme(new StandardChartTheme("JFree/Shadow",
                true));
    }

    /**
     * Default constructor.
     *
     * @param title  the frame title.
     */
    public PieChartDemo(String title) {
        super(title);
        setContentPane(createDemoPanel());
    }

    /**
     * Creates a sample dataset.
     * 
     * Source: http://www.bbc.co.uk/news/business-15489523
     *
     * @return A sample dataset.
     */
    private static PieDataset createDataset() {
        DefaultPieDataset dataset = new DefaultPieDataset();
        dataset.setValue("Samsung", new Double(27.8));
        dataset.setValue("Others", new Double(55.3));
        dataset.setValue("Nokia", new Double(16.8));
        dataset.setValue("Apple", new Double(17.1));
        return dataset;
    }

    /**
     * Creates a chart.
     *
     * @param dataset  the dataset.
     *
     * @return A chart.
     */
    private static JFreeChart createChart(PieDataset dataset) {

        JFreeChart chart = ChartFactory.createPieChart(
            "Smart Phones Manufactured / Q3 2011",  // chart title
            dataset,            // data
            false,              // no legend
            true,               // tooltips
            false               // no URL generation
        );

        // set a custom background for the chart
        chart.setBackgroundPaint(new GradientPaint(new Point(0, 0), 
                new Color(20, 20, 20), new Point(400, 200), Color.DARK_GRAY));

        // customise the title position and font
        TextTitle t = chart.getTitle();
        t.setHorizontalAlignment(HorizontalAlignment.LEFT);
        t.setPaint(new Color(240, 240, 240));
        t.setFont(new Font("Arial", Font.BOLD, 26));

        PiePlot plot = (PiePlot) chart.getPlot();
       
        plot.setBackgroundPaint(null);
        plot.setOutlineVisible(false);

        // use gradients and white borders for the section colours
        plot.setSectionPaint("Others", createGradientPaint(new Color(200, 200, 255), Color.BLUE));
        plot.setSectionPaint("Samsung", createGradientPaint(new Color(255, 200, 200), Color.RED));
        plot.setSectionPaint("Apple", createGradientPaint(new Color(200, 255, 200), Color.GREEN));
        plot.setSectionPaint("Nokia", createGradientPaint(new Color(200, 255, 200), Color.YELLOW));
        plot.setBaseSectionOutlinePaint(Color.WHITE);
        plot.setSectionOutlinesVisible(true);
        plot.setBaseSectionOutlineStroke(new BasicStroke(2.0f));

        // customise the section label appearance
        plot.setLabelFont(new Font("Courier New", Font.BOLD, 20));
        plot.setLabelLinkPaint(Color.WHITE);
        plot.setLabelLinkStroke(new BasicStroke(2.0f));
        plot.setLabelOutlineStroke(null);
        plot.setLabelPaint(Color.WHITE);
        plot.setLabelBackgroundPaint(null);
        
        // add a subtitle giving the data source
        TextTitle source = new TextTitle("Source: http://www.bbc.co.uk/news/business-15489523", 
                new Font("Courier New", Font.PLAIN, 12));
        source.setPaint(Color.WHITE);
        source.setPosition(RectangleEdge.BOTTOM);
        source.setHorizontalAlignment(HorizontalAlignment.RIGHT);
        chart.addSubtitle(source);
        return chart;

    }

    /**
     * A utility method for creating gradient paints.
     * 
     * @param c1  color 1.
     * @param c2  color 2.
     * 
     * @return A radial gradient paint.
     */
    private static RadialGradientPaint createGradientPaint(Color c1, Color c2) {
        Point2D center = new Point2D.Float(0, 0);
        float radius = 200;
        float[] dist = {0.0f, 1.0f};
        return new RadialGradientPaint(center, radius, dist,
                new Color[] {c1, c2});
    }

    /**
     * Creates a panel for the demo (used by SuperDemo.java).
     *
     * @return A panel.
     */
    public static JPanel createDemoPanel() {
        JFreeChart chart = createChart(createDataset());
        chart.setPadding(new RectangleInsets(4, 8, 2, 2));
        ChartPanel panel = new ChartPanel(chart);
        panel.setMouseWheelEnabled(true);
        panel.setPreferredSize(new Dimension(600, 300));
        return panel;
    }

    /**
     * Starting point for the demonstration application.
     *
     * @param args  ignored.
     */
    public static void main(String[] args) {

        // ******************************************************************
        //  More than 150 demo applications are included with the JFreeChart
        //  Developer Guide...for more information, see:
        //
        //  >   http://www.object-refinery.com/jfreechart/guide.html
        //
        // ******************************************************************

        PieChartDemo demo = new PieChartDemo("JFreeChart: Pie Chart Demo 1");
        demo.pack();
        RefineryUtilities.centerFrameOnScreen(demo);
        demo.setVisible(true);
    }

}

What do all the elements in the title have in common? They were all present at the Toronto Eclipse DemoCamp last Wednesday night! Hosted by Red Hat, this was the first public event in our new office and I think it went pretty well. We have more space than we did at our old office and since the event wasn’t in June, the room didn’t get to 35°C

Thanks to all the presenters, especially those who came from far away, some as far as Ottawa!

• Andrew Robinson from Red Hat on Fedora Packager for Eclipse
• Marcelo Paternostro from Oracle on the Oracle Enterprise Pack for Eclipse and Sapphire
• Brian de Alwis from Manumitting Technologies on e4 and CSS
• Igor Feodorenko from Sonatype on m2e
• Peter Krogh from Oracle (and Ottawa) on EclipseLink
• Wayne Beaton from the Eclipse Foundation (and Ottawa) on Orion

This event featured a trivia contest with questions written by the illustrious Kim Moir and a prize of an Eclipse shirt. Marcelo won but it was a tight race between him, Elliott Baron, and Severin Gehwolf. We also had a delicious 10th birthday cake made by one of Sami Wagiaalla‘s friends who’s starting a cake-making business:

Thanks to all who attended, representing individuals, a variety of companies, and a number of academic institutions. As a few of us said at the end of the evening: see you in six months!

The latest OpenJDK6 release B24 is now available, details are at
blogs.oracle.com/openjdk6releases/entry/openjdk_6_b24_available.

-kto

IcedTea-Web 1.0.6 and 1.1.4 have been released. These are security fix only
releases and address a security issue classified as having moderate impact.

What’s new in 1.0.6 and 1.1.4:

• RH742515, CVE-2011-3377: IcedTea-Web: second-level domain subdomains and suffix domain SOP bypass

The following people helped with this release:
Omair Majid

Checksums:
44a770da85fd2e342ab09e065798a07d04601ea51879df4a5e88f804e4f02eba icedtea-web-1.0.6.tar.gz
b17a742af0153b7887cf667a160f8519afad125bc515b0f4783c66e7ee1a7f26 icedtea-web-1.1.4.tar.gz

Download links:
http://icedtea.classpath.org/download/source/icedtea-web-1.0.6.tar.gz
http://icedtea.classpath.org/download/source/icedtea-web-1.1.4.tar.gz

After extracting, it can be built as per instructions here:
http://icedtea.classpath.org/wiki/IcedTea-Web#Building_IcedTea-Web

The IcedTea project provides a harness to build the source code from OpenJDK6 using Free Software build tools, along with additional features such as a PulseAudio sound driver and support for alternative
virtual machines.

A new set of security releases is now available for versions of IcedTea which include the plugin and Web Start support now developed in the IcedTea-Web project:

• IcedTea6 1.8.11
• IcedTea6 1.9.11

Where possible, we recommend using IcedTea-Web in preference to these older versions, in order to obtain the latest bug fixes and features.

All updates contain the following security fixes:

• RH742515, CVE-2011-3377: IcedTea-Web: second-level domain subdomains and suffix domain SOP bypass

Full details of each release can be found below.

What’s New?

New in release 1.9.11 (2011-11-08)

• Security fixes
  • RH742515, CVE-2011-3377: IcedTea-Web: second-level domain subdomains and suffix domain SOP bypass

New in release 1.8.11 (2011-11-08)

• Security fixes
  • RH742515, CVE-2011-3377: IcedTea-Web: second-level domain subdomains and suffix domain SOP bypass

The tarballs can be downloaded from:

• http://icedtea.classpath.org/download/source/icedtea6-1.8.11.tar.gz
• http://icedtea.classpath.org/download/source/icedtea6-1.9.11.tar.gz

SHA256 checksums:

• 6eb418ec0609080a71bda16896124d6e1ac23b2f54af52e05fc22c719e12ca29 icedtea6-1.8.11.tar.gz
• fd3b32f8dd1010fa8b752f0224fb25a8fe102c9f82652f0ded32138fd4ba3714 icedtea6-1.9.11.tar.gz

Each tarball is accompanied by a digital signature (available at the above URL + ‘.sig’). This is produced using my public key. See details below in the signature.

The following people helped with these releases:

• Deepak Bhole (RH742515)
• Andrew John Hughes (release management)
• Omair Majid (additional patch preparation work)

We would also like to thank the bug reporters and testers!

To get started:

$ tar xzf icedtea6-<ver>.tar.gz
$ cd icedtea6-<ver>

Full build requirements and instructions are in INSTALL:

$ ./configure [--enable-zero --enable-pulse-java --enable-systemtap ...]
$ make