Planet Classpath

We are pleased to announce the Call for Participation in the FOSDEM 2015 Free Java DevRoom!

This marks the 12th year that the Free Java DevRoom has been a part of FOSDEM, and also marks 20 years of Java!

This year FOSDEM Free Java DevRoom will be 31 January & 1 February 2015 in Brussels, Belgium, with usual additional events and meetings on Friday, Saturday and Sunday; please, refer to the FOSDEM website for the schedule of the whole event:

https://fosdem.org/2015/

The Free Java DevRoom has become unique in that it has attracted hackers from very different Free Software Java projects, giving the opportunity to bring together companies of various sizes, different project communities, mainstream core Java developers, alternative Java language implementations and runtimes, and everything that form the Free Java  Universe, everybody participating to share their knowledge in an atmosphere of cooperation and friendly competition.

It has been a long journey so far, exciting and fun, and hard at times.

But together we have made it, and Java today more than ever can count on a dynamic and vibrant Community, innovation due to participation, and a user base that is continually growing.

We won’t sit and rest on the paved road we built, though! We are eager to contribute to the next “20 years of excellence”, and we want you to be part of it!

As always, check out our wiki for more details on the conference:

http://wiki.debian.org/Java/DevJam/2015/Fosdem

And join the Free Java DevoRoom mailing list [java-devroom at lists.fosdem.org]:

https://lists.fosdem.org/listinfo/java-devroom

IMPORTANT

Fosdem organisers have expressed the desire to record everything, and we will do our best to record the sessions by default. If you wish to NOT be recorded please write clearly so in the proposal.

Please submit one (or more) 25 minute talk proposal(s) by the 1st of December 2014, 23.59 CET on the mailing list.

We will also select a small number of 45 minutes talk. If you wish to submit a 45 minutes talk please state this in the  proposal, all proposals will be considered to be of 25 minute by default otherwise.

A template for submitting a talk can be found at:

http://wiki.debian.org/Java/DevJam/2015/Fosdem/CallForParticipation

Tracks will be announced around 10th of December on the mailing list.

Please join us!

The Free Java DevRoom Organizing Committee


This week I received a very welcomed news, I have just been accepted as Java Champion!

Java Champions are a group of passionate Java technology and community leaders who are dedicated to the Java platform and the Community surrounding it, it’s not a big group in terms of people being part of it (although it’s growing fast), which makes it feel even more exclusive. I’m proud to be part of it, and I hope to be up to the task and serve this new responsibility with all the deserved passion!

Java_Champions_clr


I'll be back again at EclipseCon Europe in Ludwigsburg, Germany on October 28th to speak Tuesday afternoon at 3 PM, and enjoy Simon Ritter's Lambda tutorial on Tuesday morning at 9 AM.

As usual, if there is something around OpenJDK you'd like to chat about, let me know on Twitter (or send me an e-mail), and we'll find some space and time.

See you there!
This year's JavaOne featured a new press release from Oracle mentioning OpenJDK. Here are the relevant excerpts:

Since its launch, Java SE 8 has seen record adoption, and the OpenJDK Community continues to thrive with contributions from Oracle as well as from other companies, researchers, and individual developers.

Oracle has begun work on the JDK 9 Project in the OpenJDK Community. New features will focus on modularity, performance, stability, and portability.

The OpenJDK Community continues to host the development of both the Java SE Platform Specification and its Reference Implementation, the JDK, fueled by contributions from Oracle and new and existing organizations and individuals. New participants in OpenJDK include:
* The FreeBSD Foundation, which will be collaborating with Oracle and others on producing OpenJDK binaries targeted to FreeBSD users via the FreeBSD Ports Collection
* The Digital Energy Business of the General Electric Company, which recently joined the OpenJDK Community and will be collaborating with Oracle and others on improving stability and performance of multilanguage virtual machine support via the invokeDynamic (JSR 292) API
* Microsoft Open Technologies, Inc., which will be contributing its expertise in networking, performance, and integration to the community.
The OpenJDK Community hosts many new projects that will continue to move the Java SE platform forward. These include Valhalla, which is exploring advanced language and JVM features; Panama, which aims to improve the connections between Java and native code; and smaller efforts such as Annotations Pipeline 2.0, Javadoc.next, Device I/O, and Memory Model Update.


Taken from the Oracle press release titled Oracle Highlights Continued Java SE Momentum and Innovation at JavaOne 2014.

The IcedTea project provides a harness to build the source code from OpenJDK using Free Software build tools, along with additional features such as the ability to build against system libraries and support for alternative virtual machines and architectures beyond those supported by OpenJDK.

This release updates our OpenJDK 7 support in the 2.5.x series with the Octobner 2014 security fixes.

If you find an issue with the release, please report it to our bug database under the appropriate component. Development discussion takes place on the distro-pkg-dev OpenJDK mailing list and patches are always welcome.

Note that alternate virtual machines (e.g. CACAO, JamVM) will be broken by this release, until such a time as they introduce support for JVM_FindClassFromCaller, a new virtual machine interface function added by S8015256

Full details of the release can be found below.

What’s New?

New in release 2.5.3 (2014-10-14)

  • Security fixes
  • Backports
    • S4963723: Implement SHA-224
    • S7044060: Need to support NSA Suite B Cryptography algorithms
    • S7122142: (ann) Race condition between isAnnotationPresent and getAnnotations
    • S7160837: DigestOutputStream does not turn off digest calculation when “close()” is called
    • S8006935: Need to take care of long secret keys in HMAC/PRF compuation
    • S8012637: Adjust CipherInputStream class to work in AEAD/GCM mode
    • S8028192: Use of PKCS11-NSS provider in FIPS mode broken
    • S8038000: java.awt.image.RasterFormatException: Incorrect scanline stride
    • S8039396: NPE when writing a class descriptor object to a custom ObjectOutputStream
    • S8042603: ‘SafepointPollOffset’ was not declared in static member function ‘static bool Arguments::check_vm_args_consistency()’
    • S8042850: Extra unused entries in ICU ScriptCodes enum
    • S8052162: REGRESSION: sun/java2d/cmm/ColorConvertOp tests fail since 7u71 b01
    • S8053963: (dc) Use DatagramChannel.receive() instead of read() in connect()
    • S8055176: 7u71 l10n resource file translation update
  • Bug fixes
    • PR1988: C++ Interpreter should no longer be used on ppc64
    • PR1989: Make jdk_generic_profile.sh handle missing programs better and be more verbose
    • PR1992, RH735336: Support retrieving proxy settings on GNOME 3.12.2
    • PR2000: Synchronise HEAD tarball paths with release branch paths
    • PR2002: Fix references to hotspot.map following PR2000
    • PR2003: –disable-system-gtk option broken by refactoring in PR1736
    • PR2009: Checksum of policy JAR files changes on every build
    • PR2014: Use version from hotspot.map to create tarball filename
    • PR2015: Update hotspot.map documentation in INSTALL
    • PR2025: LCMS_CFLAGS & LCMS_LIBS should not be used unless SYSTEM_LCMS is enabled
    • RH1015432: java-1.7.0-openjdk: Fails on PPC with StackOverflowError (revised comprehensive fix)
  • CACAO
  • AArch64 port
    • AArch64 C2 instruct for smull
    • Add frame anchor fences.
    • Add MacroAssembler::maybe_isb()
    • Add missing instruction synchronization barriers and cache flushes.
    • Add support for a few simple intrinsics
    • Add support for builtin crc32 instructions
    • Add support for Neon implementation of CRC32
    • All address constants are 48 bits in size.
    • array load must only read 32 bits
    • Define uabs(). Use it everywhere an absolute value is wanted.
    • Fast string comparison
    • Fast String.equals()
    • Fix register usage in generate_verify_oop().
    • Fix thinko in Atomic::xchg_ptr.
    • Fix typo in fsqrts
    • Improve C1 performance improvements in ic_cache checks
    • Performance improvement and ease of use changes pulled from upstream
    • Remove obsolete C1 patching code.
    • Replace hotspot jtreg test suite with tests from jdk7u
    • S8024648: 7141246 breaks Zero port
    • Save intermediate state before removing C1 patching code.
    • Unwind native AArch64 frames.
    • Use 2- and 3-instruction immediate form of movoop and mov_metadata in C2-generated code.
    • Various concurrency fixes.

The tarballs can be downloaded from:

We provide both gzip and xz tarballs, so that those who are able to make use of the smaller tarball produced by xz may do so.

The tarballs are accompanied by digital signatures available at:

These are produced using my public key. See details below.

SHA256 checksums:

  • 44df11ac8e5ace7194e7372ef169909e0dab31d6b2f6bbae9a9c33af2cc54540 icedtea-2.5.3.tar.gz
  • ac7c1ae97eef2d1c650ab7a21091f71e83a984f37a12c802c0f319f1438b0101 icedtea-2.5.3.tar.gz.sig
  • f4f2922cfec262496e935f81c1d39af66a789f69aa12d1ceee51bcca8934f1f0 icedtea-2.5.3.tar.xz
  • ed9b9cbc1237bfbf619e2cccfddf1002901371e94177a8becd85036be1ccf29a icedtea-2.5.3.tar.xz.sig

The checksums can be downloaded from:

A 2.5.3 ebuild for Gentoo is available.

The following people helped with these releases:

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

To get started:

$ tar xzf icedtea-2.5.3.tar.gz

or:

$ tar x -I xz -f icedtea-2.5.3.tar.xz

then:

$ mkdir icedtea-build
$ cd icedtea-build
$ ../icedtea-2.5.3/configure
$ make

Full build requirements and instructions are available in the INSTALL file.

Happy hacking!

The IcedTea project provides a harness to build the source code from OpenJDK using Free Software build tools, along with additional features such as a PulseAudio sound driver, the ability to build against system libraries and support for alternative virtual machines and architectures beyond those supported by OpenJDK.

This release updates our OpenJDK 6 support in the 1.13.x series with the October 2014 security fixes.

If you find an issue with the release, please report it to our bug database under the appropriate component. Development discussion takes place on the distro-pkg-dev OpenJDK mailing list and patches are always welcome.

Note that alternate virtual machines (e.g. CACAO, JamVM) will be broken by this release, until such a time as they introduce support for JVM_FindClassFromCaller, a new virtual machine interface function added by S8015256.

Full details of the release can be found below.

What’s New?

New in release 1.13.5 (2014-10-14)

  • Security fixes
  • Import of OpenJDK6 b33
    • OJ37: OpenJDK6-b32 cannot be built on Windows
    • OJ39: Handle fonts with the non-canonical processing flag set
    • OJ41: OpenJDK6 should be compatible with Windows SDK 7.1
    • OJ42: Remove @Override annotation on interfaces added by 2014/10/14 security fixes.
    • S6967684: httpserver using a non thread-safe SimpleDateFormat
    • S7033534: Two tests fail just against jdk7 b136
    • S7160837: DigestOutputStream does not turn off digest calculation when “close()” is called
    • S7172149: ArrayIndexOutOfBoundsException from Signature.verify
    • S8010213: Some api/javax_net/SocketFactory tests fail in 7u25 nightly build
    • S8012637: Adjust CipherInputStream class to work in AEAD/GCM mode
    • S8028192: Use of PKCS11-NSS provider in FIPS mode broken
    • S8038000: java.awt.image.RasterFormatException: Incorrect scanline stride
    • S8039396: NPE when writing a class descriptor object to a custom ObjectOutputStream
    • S8042603: ‘SafepointPollOffset’ was not declared in static member function ‘static bool Arguments::check_vm_args_consistency()’
    • S8042850: Extra unused entries in ICU ScriptCodes enum
    • S8052162: REGRESSION: sun/java2d/cmm/ColorConvertOp tests fail since 7u71 b01
    • S8053963: (dc) Use DatagramChannel.receive() instead of read() in connect()
  • Backports
    • S4963723: Implement SHA-224
    • S6578658: Request for raw RSA (NONEwithRSA) Signature support in SunMSCAPI
    • S6753664: Support SHA256 (and higher) in SunMSCAPI
    • S7033170: Cipher.getMaxAllowedKeyLength(String) throws NoSuchAlgorithmException
    • S7044060: Need to support NSA Suite B Cryptography algorithms
    • S7106773: 512 bits RSA key cannot work with SHA384 and SHA512
    • S7180907: Jarsigner -verify fails if rsa file used sha-256 with authenticated attributes
    • S8006935: Need to take care of long secret keys in HMAC/PRF compuation
    • S8017173, PR1688: XMLCipher with RSA_OAEP Key Transport algorithm can’t be instantiated
    • S8049480: Current versions of Java can’t verify jars signed and timestamped with Java 9
  • Bug fixes
    • PR1904: [REGRESSION] Bug reports now lack IcedTea version & distribution packaging information
    • PR1967: Move to new OpenJDK bug URL format

The tarballs can be downloaded from:

We provide both gzip and xz tarballs, so that those who are able to make use of the smaller tarball produced by xz may do so.

The tarballs are accompanied by digital signatures available at:

These are produced using my public key. See details below.

SHA256 checksums:

  • 7bc21b8fa532c44279591372a77a76ae5976f54ae02ea8bdcd3dd7740511f1cb icedtea6-1.13.5.tar.gz
  • daf5b5132e73091af7bdf1040ae234773fa62c4ee8600a4abfdb7b2db205ce3a icedtea6-1.13.5.tar.gz.sig
  • 3579852895dcce8dcb0277b221c5b27d57baf7e642e9cbb92c1b67d9af9e2cbb icedtea6-1.13.5.tar.xz
  • 8b5de1b8c814d9743c7531ad58e0cb1de1c40e56c7f2315ae01c45c36faa20f1 icedtea6-1.13.5.tar.xz.sig

The checksums can be downloaded from:

A 1.13.5 ebuild for Gentoo is available.

The following people helped with these releases:

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

To get started:

$ tar xzf icedtea6-1.13.5.tar.gz

or:

$ tar x -I xz -f icedtea6-1.13.5.tar.xz

then:

$ mkdir icedtea-build
$ cd icedtea-build
$ ../icedtea6-1.13.5/configure
$ make

Full build requirements and instructions are available in the INSTALL file.

Happy hacking!

Did you want to use GNUMail on NetBSD and were not even able to compile it? Do you run 64bit and had problems with GNUMail ?

I am pleased to announce a new, maintenance release of Pantomime.

Due to the inactivity of CollaborationWorld and Ludovic, we(*) decided to import the sources in gnustep-nonfsf at gna.org.



The download is at:
http://download.gna.org/gnustep-nonfsf/Pantomime-1.2.2.tar.gz

This release contains updates and some important, long-needed fixes:
* new res_init code for NetBSD which allows finally, after years, to run GNUMail on NetBSD!
* enhanced portability to FreeBSD and OpenBSD
* improved packaging hints in the makefiles
* port to MacOS reinstantiated (10.3/10.4 tested)
* extended 64bit fixes, including NSInteger/NSUInteger transitions were appropriate
* enhanced crash catching, so that debugging is eased in the future
* memory leaks fixed

I started hacking on firefox recently. And, of course, I’ve configured emacs a bit to make hacking on it more pleasant.

The first thing I did was create a .dir-locals.el file with some customizations. Most of the tree has local variable settings in the source files — but some are missing and it is useful to set some globally. (Whether they are universally correct is another matter…)

Also, I like to use bug-reference-url-mode. What this does is automatically highlight references to bugs in the source code. That is, if you see “bug #1050501″, it will be buttonized and you can click (or C-RET) and open the bug in the browser. (The default regexp doesn’t capture quite enough references so my settings hack this too; but I filed an Emacs bug for it.)

I put my .dir-locals.el just above my git checkout, so I don’t end up deleting it by mistake. It should probably just go directly in-tree, but I haven’t tried to do that yet. Here’s that code:

(
 ;; Generic settings.
 (nil .
      ;; See C-h f bug-reference-prog-mode, e.g, for using this.
      ((bug-reference-url-format . "https://bugzilla.mozilla.org/show_bug.cgi?id=%s")
       (bug-reference-bug-regexp . "\\([Bb]ug ?#?\\|[Pp]atch ?#\\|RFE ?#\\|PR [a-z-+]+/\\)\\([0-9]+\\(?:#[0-9]+\\)?\\)")))

 ;; The built-in javascript mode.
 (js-mode .
     ((indent-tabs-mode . nil)
      (js-indent-level . 2)))

 (c++-mode .
	   ((indent-tabs-mode . nil)
	    (c-basic-offset . 2)))

 (idl-mode .
	   ((indent-tabs-mode . nil)
	    (c-basic-offset . 2)))

)

In programming modes I enable bug-reference-prog-mode. This enables highlighting only in comments and strings. This would easily be done from prog-mode-hook, but I made my choice of minor modes depend on the major mode via find-file-hook.

I’ve also found that it is nice to enable this minor mode in diff-mode and log-view-mode. This way you get bug references in diffs and when viewing git logs. The code ends up like:

(defun tromey-maybe-enable-bug-url-mode ()
  (and (boundp 'bug-reference-url-format)
       (stringp bug-reference-url-format)
       (if (or (derived-mode-p 'prog-mode)
	       (eq major-mode 'tcl-mode)	;emacs 23 bug
	       (eq major-mode 'makefile-mode)) ;emacs 23 bug
	   (bug-reference-prog-mode t)
	 (bug-reference-mode t))))

(add-hook 'find-file-hook #'tromey-maybe-enable-bug-url-mode)
(add-hook 'log-view-mode-hook #'tromey-maybe-enable-bug-url-mode)
(add-hook 'diff-mode-hook #'tromey-maybe-enable-bug-url-mode)
In the past weeks, quite some polish was added in windows support.

First, there was a bug affecting Popup Menus and contextual menus that affected only certain computers. It was fixed.




Then the controls were not properly initialized. Native file-dialogs, for example, as well as upcoming print dialogs (work in progress by Gregory) did not fit the theme properly. On XP, Window 7 and Windows 8 they should follow the native look, instead they always got the "Win 95" look creating a strange mix.

The fix requires initializing Windows' controls. I put the initialization code inside the WinUX theme loading. If it will not prove safe, then it needs to be moved into NSApplication. Furthermore, an XML resource file to enable the correct loading.




I really does look nice, doesn't it?

I’ve been working on an odd Emacs package recently — not ready for release — which has turned into more than the usual morass of prefixed names and double hyphens.

So, I took another look at Nic Ferrier’s namespace proposal.

Suddenly it didn’t seem all that hard to implement something along these lines, and after a bit of poking around I wrote emacs-module.

The basic idea is to continue to follow the Emacs approach of prefixing symbol names — but not to require you to actually write out the full names of everything.  Instead, the module system intercepts load and friends to rewrite symbol names as lisp is loaded.

The symbol renaming is done in a simple way, following existing Emacs conventions.  This gives the nice result that existing code doesn’t need to be updated to use the module system directly.  That is, the module system recognizes name prefixes as “implicit” modules, based purely on the module name.

I’d say this is still a proof-of-concept.  I haven’t tried hairier cases, like defclass, and at least declare-function does not work but should.

Here’s the example from the docs:

(define-module testmodule :export (somevar))
(defvar somevar nil)
(defvar private nil)
(provide 'testmodule)

This defines the public variable testmodule-somevar and the “private” function testmodule--private.

Thanks to Jonathan Lin and Spencer Hui some of the talks that were presented at the recent “bootcamp” are appearing on Air Mozilla and more will do so as we get them ready. They’re all in Air Mozilla’s engineering channel: https://air.mozilla.org/channels/engineering/

Thanks to everybody who commented on the JamVM 2.0.0 release, and apologies it's taken so long to approve them - I was expecting to get an email when I had an unmoderated comment but I haven't received any.

To answer the query regarding Nashorn.  Yes, JamVM 2.0.0 can run Nashorn.  It was one of the things I tested the JSR 292 implementation against.  However, I can't say I ran any particularly large scripts with it (it's not something I have a lot of experience with).  I'd be pleased to hear any experiences (good or bad) you have.

So now 2.0.0 is out of the way I hope to do much more frequent releases.  I've just started to look at OpenJDK 9.  I was slightly dismayed to discover it wouldn't even start up (java -version), but it turned out to be not a lot of work to fix (2 evenings).  Next is the jtreg tests...

JFreeChart version 1.0.19 has been uploaded to SourceForge and the Maven Central Repository. This release contains additional rendering hints to improve output quality across a range of targets, plus some important fixes for the recently added JavaFX support.

jfreechart-1.0.19.png

In the download we've also included a preview of JSFreeChart, a 2D charting framework written in JavaScript that is conceptually similar to JFreeChart but runs directly in browsers. This is being developed in collaboration with KNIME.com AG, creators of the open source KNIME Analytics Platform.

I'm pleased to announce a new release of JamVM.  JamVM 2.0.0 is the first release of JamVM with support for OpenJDK (in addition to GNU Classpath). Although IcedTea already includes JamVM with OpenJDK support, this has been based on periodic snapshots of the development tree.

JamVM 2.0.0 supports OpenJDK 6, 7 and 8 (the latest). With OpenJDK 7 and 8 this includes full support for JSR 292 (invokedynamic). JamVM 2.0.0 with OpenJDK 8 also includes full support for Lambda expressions (JSR 335), type annotations (JSR 308) and method parameter reflection.

In addition to OpenJDK support, JamVM 2.0.0 also includes many bug-fixes, performance improvements and improved compatibility (from running the OpenJDK jtreg tests).

The full release notes can be found here (changes are categorised into those affecting OpenJDK, GNU Classpath and both), and the release package can be downloaded from the file area.

Overview

We've just released FXGraphics2D version 1.1, a Java2D to JavaFX bridge, a small and fast library that takes Java2D API calls and maps them to a JavaFX Canvas node. We developed this library to add JavaFX support to our charting libraries (JFreeChart and Orson Charts) but, as you'll see later in this post, FXGraphics2D is a standalone library that can be used by other Java code as well.

What's New?

First, we've added detection for the KEY_STROKE_CONTROL rendering hint, which provides sharper looking output particularly for horizontal and vertical lines. Compare the axis and grid lines in the following two charts (based on one of the JFreeChart demos). The first chart has the stroke normalisation applied (the axis and gridlines are sharp and well defined):

The second chart has no stroke normalisation and you can see that the axis lines are blurred (and, in some cases, the grid lines also):

A clipping issue that was affecting a subset of charts (combined plots) in JFreeChart has been fixed.

We addressed an issue with glyph positioning when using TextLayout rendering, first reported by Christoph Nahr in relation to our other Graphics2D implementations, JFreeSVG and Orson PDF.

We addressed a memory leak that was reported for the demo applications (it is important that each repaint for the Canvas is preceded with a call to clearRect() to clear an internal queue of drawing commands that JavaFX uses).

Finally, we've included Maven build support and you can now find FXGraphics2D on the Central Repository.

General Use

FXGraphics2D includes demos that use JFreeChart and Orson Charts to generate the graphical content that is rendered by the FXGraphics2D code. However, it is important to realise that FXGraphics2D is a standalone API and can be used with any Java code that uses the Java2D drawing API, so it enables a lot of existing Java2D code to be retained for use in JavaFX applications.

To illustrate, here is a screenshot of a small demo application that renders equations using JLaTeXMath and FXGraphics2D:

jlatexmath_example.png

You can see the source code and some discussion about this example at Stack Overflow.

Summary

FXGraphics2D 1.1 is a general purpose graphics utility that extends the reach of Java2D code to include JavaFX applications. This latest release improves the quality of the library following community feedback.

Sad to receive news this morning that a long time friend and colleague, Peter Miller, had passed.

Peter Miller

“After fighting cancer for many years, finally lost”. No, not lost; if there was ever anyone who fought the battle of life and won it was be Peter. Even knowing he was at his last days he was unbowed. Visiting him last week he proudly showed us the woodworking plans and cut lists for some cabinets he was making for his wife MT. He had created the diagrams himself, writing C++ code to call manually drive a drawing library, outputting postscript. Let’s see you do architectural drawing without a CAD program. The date on the printout was two weeks ago.

“The world is a less interesting place today,” wrote another friend. No. Peter firmly believed that interest comes from within. The world is there to be explored, I can hear him saying. He taught us to go forth, wonder, and understand. And so we should.

AfC

For a while now a number of Mozillians have been discussing the need for some sort of technical training on Gecko and other Mozilla codebases. A few months ago, Vlad and I and a few others came up with a plan to try out a “bootcamp”-like event. We initially thought we’d have non-core developers learn from more senior developers for 4 days and had a few goals:

  • teach people not developing Mozilla code daily about the development process
  • expose Mozillians to areas with which they’re not familiar
  • foster shared ownership of areas of code and tools
  • teach people where to look in the code when they encounter a bug and to more accurately file a bug (“teach someone how to fish”)

While working towards this we realized that there isn’t as much shared ownership as there could be within Mozilla codebases so we focused on 2 engineering teams teaching other engineers. The JavaScript and Graphics teams agreed to be mentors and we solicited participants from a few paid Mozillians to try this out. We intentionally limited the audience and hand-picked them for this first “beta” since we had no idea how it would go.

The event took place over 4 days in Toronto in early June. We ended up with 5 or 6 mentors (the Graphics team having a strong employee presence in Toronto helped with pulling in experts here and there) and 9 attendees from a variety of engineering teams (Firefox OS, Desktop, and Platform).

The week’s schedule was fairly loose to accommodate questions and make it more of a conversational atmosphere. We planned sessions in an order to give a high level overview followed by deeper dives. We also made sessions about complementary Gecko components happen in a logical order (ex. layout then graphics). You can see details about the schedule we settled upon here: https://etherpad.mozilla.org/bootcamp1plans.

We collaboratively took notes and recorded everything on video. We’re still in the process of creating usable short videos out of the raw feeds we recorded. Text notes were captured on this etherpad which had some real-time clarifications made by people not physically present (Ms2ger and others) which was great.

The week taught us a few things, some obvious, some not so obvious:

  • people really want time for learning. This was noted more than once and positive comments I received made me realize it could have been held in the rain and people would have been happy
  • having a few days set aside for professional development was very much appreciated so paid Mozillians incorporating this into their goals should be encouraged
  • people really want the opportunity to learn from and ask questions of more seasoned Mozilla hackers
  • hosting this in a MozSpace ensured reliable facilities, flexibility in terms of space, and the availability of others to give ad hoc talks and answer questions when necessary. It also allowed others who weren’t official attendees to listen in for a session or two. Having it in the office also let us use the existing video recording setup and let us lean on the ever-amazing Jonathan Lin for audio and video help. I think you could do this outside a MozSpace but you’d need to plan a bit more for A/V and wifi, etc.
  • background noise (HVAC, server fans, etc.) is very frustrating for conversations and audio recording (but we already knew this)
  • this type of event is unsuitable for brand new {employees|contributors} since it’s way too much information. It would be more applicable after someone’s been involved for a while (6 months, 1 year?).

In terms of lessons for the future, a few things come to mind:

  • interactive exercises were very well received (thanks, kats!) and cemented people’s learning as expected
  • we should perhaps define homework to be done in advance and strongly encourage completion of it; videos of previous talks may be good material
  • scheduling around 2 months in advance seemed to be best to balance “I have no idea what I’ll be doing then” and “I’m already busy that week”
  • keeping the ratio of attendees to “instructors” to around 2 or 3 to 1 worked well for interactivity and ensuring the right people were present who could answer questions
  • although very difficult, attempting to schedule around major deadlines is useful (this week didn’t work for a few of the Firefox OS teams)
  • having people wear lapel microphones instead of a hand-held one makes for much better and more natural audio
  • building a schedule, mentors, and attendee list based on common topics of interest would be an interesting experiment instead of the somewhat mixed bag of topics we had this time
  • using whiteboards and live coding/demos instead of “slides” worked very well

Vlad and I think we should do this again. He proposed chaining organizers so each organizer sets one up and helps the next person do it. Are you interested in being the next organizer?

I’m very interested in hearing other people’s thoughts about this so if you have any, leave a comment or email me or find me on IRC or send me a postcard c/o the Toronto office (that would be awesome).

Yesterday's JDK 7u65 and 8u11 updates changed method overriding yet again and, of course, it is still broken.

Take this example:

package pkg1;

public class A {
  { foo(); }
  void foo() { System.out.println("A.foo"); }
}

package pkg2;

public class B extends pkg1.A {
  { foo(); }
  void foo() { System.out.println("B.foo"); }
}

package pkg1;

public class C extends pkg2.B {
  { foo(); }
  void foo() { System.out.println("C.foo"); }
}

package pkg2;

public class D extends pkg1.C {
  { foo(); }
  void foo() { System.out.println("D.foo"); }
}

public class test {
  public static void main(String[] args) {
    new pkg2.D();
  }
}

Running this with JDK 8u5 yields:

D.foo
D.foo
D.foo
D.foo

Which is, of course, wrong. In yesterday's updates they tried to fix this, but only partially succeeded:

D.foo
D.foo
C.foo
D.foo

The sensible output would be:

C.foo
D.foo
C.foo
D.foo

In Februari I reported two Java vulnerabilities to Oracle. Yesterday they released the update that fixed them, so here are the descriptions of the two issues.

@java.lang.invoke.LambdaForm.Compiled

Internally, the JDK uses the LambdaForm.Compiled annotation to mark methods that should be skipped in a security stack walk. In JDK 7 it was possible to apply this annotation to untrusted code. Here's an example:

import java.lang.annotation.*;

@Retention(RetentionPolicy.RUNTIME)
@interface java_lang_invoke_LambdaForm$Compiled { }

class test {
  @java_lang_invoke_LambdaForm$Compiled
  public static void main(String[] args) throws Throwable {
    System.out.println(Class.forName("sun.misc.Unsafe"));
  }
}

If you compile and run this with JDK 1.7.0_60 with a security manager, you get the appropriate AccessControlException. However, if you edit test.class to replace java_lang_invoke_LambdaForm with java/lang/invoke/LambdaForm and run it again, you see that the main method is now skipped in the security check and hence is allowed to access a privileged class.

The fix can be seen here.

MaxArityBug

This example demonstrates that the JDK 1.7.0_60 LambdaForm method handle implementation has a type safety bug when dealing with method signatures with the maximum number of parameters.

Project Jigsaw has, for the last several years, been in an exploratory phase in which we’ve designed and prototyped one particular approach to addressing a draft set of requirements.

It’s now time to switch gears and focus on creating a production-quality design and implementation suitable for JDK 9 and thence Java SE 9, as previously proposed.

To begin this phase I’ve drafted a new document to collect goals and requirements. It reflects a new emphasis on security, as motivated by recent experience, it takes into account lessons learned from the prototype, and it’s written at a broader and more abstract level than the previous document so as not to over-constrain the solution space. This document will be one of the starting points of the upcoming Java Platform Module System JSR.

Jigsaw as a whole will bring enormous changes to the JDK; it would be unwise to wait until it’s completely finished before merging any of it. Our intent, therefore, is to proceed in large steps, each of which will have a corresponding JEP. The first three JEPs will propose a specific modular structure for the JDK, reorganize the JDK source code (but not binaries) along those lines, and then later modularize the binary images.

A fourth JEP will introduce the module system itself, which will be aligned with the module-system JSR. It may seem odd that the module system JEP comes last, but the earlier JEPs need make only minimal assumptions about its capabilities, hence work on them can proceed in parallel with work on the module-system JEP and JSR.

Comments, questions, and suggestions are welcome on 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.)

There’s an interesting spectrum of events in the technical space. Conferences are the mainstay obviously; usually very intense and high-calibre thanks to the hard work of papers committees and of course the presenters themselves. You become invigorated hearing the experiences and results of other people, sharing ideas in the hallway, and of course the opportunity to vehemently explain why vi is better than emacs over drinks in the bar later is essential to the progress of science.

For a given community, though, conferences are relatively infrequent; often only once a year for a given country (linux.conf.au, Australia’s annual Linux conference, say) and sometimes only once a year globally (ICFP, the international functional programming conference with numerous collocated symposiums and events taking advantage of the fact it’s the one event everyone turns up at is a notable example in computing).

More locally, those in major cities are able to organize monthly meetups, networking events, user groups, and the like. Which are fun; lovely to see friends and continue to build relationships with people you’d otherwise only see once a year.

Finally there are hackfests, often on the order of a weekend in duration. The tend to draw people in from a wide area, and sometimes are in an unusual milieu; Peter Miller’s CodeCon camping and hacking weekends are infamous in the Sydney Linux community; rent a small quiet generator, find a state forest, set up tents and hack on whatever code you want to for a few days. Blissful.

The local monthly events are the most common, though. Typically two or three people offer to give presentations to an audience of 30-50 people. And while hearing talks on a range of topics is invaluable, the fact that so many smart people are in the room passively seems a lost opportunity.

For a while now I’ve been musing whether perhaps there is something between meetups and hackfests. Wouldn’t it be cool to get a bunch of people together, put a problem on the board, and then for an hour go around the room and have a debate about whether the problem is even the right question to be asking, and different approaches to tackling the issue? Something short, relatively focused, and pragmatic; rather than being a presentation of results a consideration of approaches. If we do it in a bit of rotation, each time one person being tasked with framing the question, then over time participants each have the benefit of bringing the collective firepower of the group to bear on one of the problems they’re working.

Needs a name. Seminar? No, that’s what university departments do. Symposium? Too grand. Something more informal, impromptu, but organized. You know, like a jazz jam session. Ah, there we go: gonna call these sessions.

It might be nice to complement the monthly functional programming meetup (fp-syd) that happens in Sydney with something a little more interactive and Haskell focused. And as I’m looking to improve the depth of experience with Haskell in the Engineering group at Anchor, this seemed like a nice fit. So we’re holding the first of the Haskell Sessions tomorrow 2pm, at Anchor’s office in Sydney.

Here’s one to start us off:

Industrial code has to interact with the outside world, often on external dependencies such as databases, network services, or even filesystem operations. We’re used to the ability to separate pure code from that with side-effects, but what abstractions can we use to isolate the dependent code from the rest of the program logic?

I know we’re not the first ones to blunder in to this; I’ve heard plenty of people discussing it. So I’m going to hand around a single page with the type signatures of the functions involved at various points, freshly sharpen some whiteboard markers, and we’ll see what ideas come to light!

If you’re interested in coming, drop me a line.

AfC

Another company is refusing to issue a Java RIA code signing certificate for individual. Even if they openly declare they do in they website. Even after I provided the notary-confirmed copies of all documents they requested and they have had two phone interviews with me. Seems really the end of the project. Dalibor, are you reading this?

I wrote a quick fuzzer for libiberty’s demangler this morning. Here’s how to get and use it:

$ mkdir workdir
$ cd workdir
$ git clone git@github.com:gbenson/binutils-gdb.git src
  ...
$ cd src
$ git co demangler
$ cd ..
$ mkdir build
$ cd build
$ CFLAGS="-g -O0" ../src/configure --with-separate-debug-dir=/usr/lib/debug
  ...
$ make
  ...
$ ../src/fuzzer.sh 
  ...
+ /home/gary/workdir/build/fuzzer
../src/fuzzer.sh: line 12: 22482 Segmentation fault      (core dumped) $fuzzer
# copy the executable and PID from the two lines above
$ gdb -batch /home/gary/workdir/build/fuzzer core.22482 -ex "bt"
...
Core was generated by `/home/gary/workdir/build/fuzzer'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000000000040d5f2 in op_is_new_cast (op=0x7ffffac19930) at libiberty/cp-demangle.c:3064
3064	  const char *code = op->u.s_operator.op->code;
#0  0x000000000040d5f2 in op_is_new_cast (op=0x7ffffac19930) at libiberty/cp-demangle.c:3064
#1  0x000000000040dc6f in d_expression_1 (di=0x7ffffac19c90) at libiberty/cp-demangle.c:3232
#2  0x000000000040dfbc in d_expression (di=0x7ffffac19c90) at libiberty/cp-demangle.c:3315
#3  0x000000000040cff6 in d_array_type (di=0x7ffffac19c90) at libiberty/cp-demangle.c:2821
#4  0x000000000040c260 in cplus_demangle_type (di=0x7ffffac19c90) at libiberty/cp-demangle.c:2330
#5  0x000000000040cd70 in d_parmlist (di=0x7ffffac19c90) at libiberty/cp-demangle.c:2718
#6  0x000000000040ceb8 in d_bare_function_type (di=0x7ffffac19c90, has_return_type=0) at libiberty/cp-demangle.c:2772
#7  0x000000000040a9b2 in d_encoding (di=0x7ffffac19c90, top_level=1) at libiberty/cp-demangle.c:1287
#8  0x000000000040a6be in cplus_demangle_mangled_name (di=0x7ffffac19c90, top_level=1) at libiberty/cp-demangle.c:1164
#9  0x0000000000413131 in d_demangle_callback (mangled=0x7ffffac19ea0 "_Z1-Av23*;cG~Wo2Vu", options=259, callback=0x40ed11 , opaque=0x7ffffac19d70)
    at libiberty/cp-demangle.c:5862
#10 0x0000000000413267 in d_demangle (mangled=0x7ffffac19ea0 "_Z1-Av23*;cG~Wo2Vu", options=259, palc=0x7ffffac19dd8) at libiberty/cp-demangle.c:5913
#11 0x00000000004132d6 in cplus_demangle_v3 (mangled=0x7ffffac19ea0 "_Z1-Av23*;cG~Wo2Vu", options=259) at libiberty/cp-demangle.c:6070
#12 0x0000000000401a87 in cplus_demangle (mangled=0x7ffffac19ea0 "_Z1-Av23*;cG~Wo2Vu", options=259) at libiberty/cplus-dem.c:858
#13 0x0000000000400ea0 in main (argc=1, argv=0x7ffffac1a0a8) at /home/gary/workdir/src/fuzzer.c:26

The symbol that crashed it is one frame up from the bottom of the backtrace.

It was pretty easy to write a new graphical backend for Jainja using the Pepper Plugin API. So it's possible to write Java graphical user interfaces on NaCl now !

A demo is available on the Chrome Web Store.


Bradley M. Kuhn wrote an analysis on the recent Appeals Court Decision in Oracle v. Google. Pointing out who the real winners are and that it will now take years before we will have more clarity:

The case is remanded, so a new jury will first sit down and consider the fair use question. If that jury finds fair use and thus no infringement, Oracle’s next appeal will be quite weak, and the Appeals Court likely won’t reexamine the question in any detail. In that outcome, very little has changed overall: we’ll have certainty that API’s aren’t copyrightable, as long as any textual copying that occurs during reimplementation is easily called fair use. By contrast, if the new jury rejects Google’s fair use defense, I suspect Google will have to appeal all the way to SCOTUS. It’s thus going to be at least two years before anything definitive is decided, and the big winners will be wealthy litigation attorneys — as usual.

You will want to read the whole thing to know why from a copyleft perspective this decision will give that strange feeling of simultaneous annoyance and contentment.

Java browser plugin has been here for a very long time, and for many years it was available on lots of machines. Yet, there were relatively few reports about somebody successfully using any security holes ever discovered.

We are currently under heavy rain of reports about Java applet security exploits on the wild. Some of these are, most likely, true.

How this could be? If some security bug (or fundamental platform weakness whatsoever) already existed for more than a decade, why nobody used if for exploit before? Why intruders spend so much of they time writing exploits of the now rather legacy platform? Where were they using this time before, instead of attacking the platform that at that time was significantly more widespread and relevant?

Jainja is a JVM (Java Virtual Machine) written in Java. Focus is set on portability, not on performances. Jainja supports Java 1.5 features.

This release adds support for Minix, Haiku and Dart.

So Jainja currently works on Linux, Windows, xBSD, Minix, Haiku, Java SE, Android, GWT, and Dart

More infos

 

Two years, seven months, and eighteen days after the release of JDK 7, production-ready builds of JDK 8 are now available for download!

Thanks! A major new release of a software system as large as the JDK is the direct work of many hundreds of developers, with indirect contributions from thousands more. By way of thanks I’d like to mention the major contributors here specifically:

Many smaller—but no less important—contributions were made via the JEP Process and in other ways by many other developers, including (but not limited to!) the following: Niclas Adlertz, Lance Andersen, Sundar Athijegannathan, Jaroslav Bachorik, Joel Borggrén-Franck, Andrew Brygin, Brian Burkhalter, Rickard Bäckman, Sergey Bylokhov, Suchen Chien, Brent Christian, Iris Clark, Sean Coffey, John Coomes, John Cuthbertson, Joe Darcy, Dan Daugherty, Mike Duigou, Xue-Lei Fan, Michael Fang, Robert Field, Daniel Fuchs, Mikael Gerdin, Jennifer Godinez, Zhengyu Gu, Kurchi Hazra, Chris Hegarty, Erik Helin, David Holmes, Vladimir Ivanov, Henry Jen, Yuka Kamiya, Karen Kinnear, Vladimir Kozlov, Marcus Lagergren, Jan Lahoda, Staffan Larsen, Doug Lea, Sergey Malenkov, Stuart Marks, Eric McCorkle, Keith McGuigan, Rob McKenna, Michael McMahon, Morris Meyer, Sean Mullan, Alejandro Murillo, Kelly O’Hair, Frederic Parain, Bhavesh Patel, Petr Pchelko, Oleg Pekhovskiy, Valerie Peng, Anthony Petrov, Pavel Porvatov, Tony Printezis, Joe Provino, Yumin Qi, Phil Race, Tom Rodriguez, Leonid Romanov, Vicente Romero, John Rose, Bengt Rutisson, Vinnie Ryan, Abhijit Saha, Dmitry Samersoff, Paul Sandoz, Naoto Sato, Thomas Schatzl, Alexander Scherbatiy, Harold Seigel, Konstantin Shefov, Xueming Shen, Serguei Spitsyn, Kumar Srinivasan, Lana Steuck, Attila Szegedi, Christian Thalinger, Igor Veresov, Hannes Wallnöfer, Joe Wang, Max Wang, Roland Westrelin, Brad Wetmore, Jesper Wilhelmsson, Hinkmond Wong, Dan Xu, Jiangli Zhou, and Alexander Zuev.

More than code Contributions of reviews, tests, and test results are just as important as contributions of code. Oracle’s internal quality and performance teams did their usual thorough job, and feedback from the wider Java community was equally valuable.

Over 400 of the more than 8,000 bug and enhancement issues addressed in JDK 8 were reported externally. These reports came in throughout the release cycle, enabled by our regular posting of weekly builds, but naturally the rate increased after we posted the Developer Preview build in September. The following early testers who submitted significant bug reports deserve special mention:

Valuable reports continued to come in after we posted the first Release Candidate build in early February. Of the small number of bugs fixed after that build, two were reported externally: A serious signature bug in the lambdafication of the Comparator API, and a nasty correctness bug in the implementation of default methods.

Launch! I’ll host the official Java 8 Launch Webcast at 17:00 UTC next Tuesday, 25 March. Join me for an open question-and-answer session with panel of key Java 8 architects, and to hear from a number of other special guests, by signing up here.

The JogAmp community held a Ji Gong freedom talk that reminded people to exercise the 4 freedoms granted by the free software licenses in front of the free java developer room audience. The talk also proposed and showcased technical enhancements for High Availability JVM Technology on All Platforms.
Slides from the Ji Gong talk can be obtained at: https://jogamp.org/doc/fosdem2014/

During the same week JogAmp released version 2.1.4 of its high performance java opengl audio & media processing librarys.
This release includes some new highlights:
* Android OpenCL test apk’s. This enable you to compile and test an OpenCL JOCL application on desktop and then deploy on Android without using any OpenCL SDK for the phone, the JOCL binding will locate and bind the OpenCL drivers at runtime.
* Enable use of custom mouse pointers and window icons using the NEWT window and input toolkit.
* Multi window support on the Raspberry Pi including mouse-pointer use directly from console!
Complete list of bugs resolved for this 2.1.4 release can be found at:
https://jogamp.org/wiki/index.php/SW_Tracking_Report_Objectives_for_the_release_2.1.4

JiGong-Panorama-extracted-from-video Panorama-of-JiGong-JogAmp-talk-audience-at-FOSDEM-2014-Free-Java-Devroom 14020010 14020025 14020026 14020034 14020069 JamVM-OpenJDK8-FOSDEM-2014-panorama 14020032 14020027

Last weekend I’ve been talking about the Shenandoah GC at FOSDEM 2014. I announced the availability of the Shenandoah source code and project pages. Until Shenandoah becomes a proper OpenJDK project, it will be hosted on IcedTea servers. We currently have:

We also filed a JEP for Shenandoah, here you can find the announcement and discussion on hotspot-gc-dev.

If you are interested in the slides that I prsented at FOSDEM, you can find them here.

Implementation-wise we’re making good progress. Concurrent evacuation is working well and support for the C1 compiler is almost done.