Planet Classpath

We are pleased to announce the release of IcedTea 2.5.2, “Back in the Groovy”!

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 with a number of regression fixes found in the previous 2.5.1 release. Mostly notably, it includes a backport of a regression fix. With the previous release, a number of Java tools and applications, including Groovy, were broken. This release should resolve these issues.

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.

Full details of the release can be found below.

What’s New?

New in release 2.5.2 (2014-08-29)

  • Backports
    • S8049480: Current versions of Java can’t verify jars signed and timestamped with Java 9
    • S8051012, LP1360392: Regression in verifier for <init> method call from inside of a branch
  • Bug fixes
    • PR1903: [REGRESSION] Bug reports now lack IcedTea version & distribution packaging information
    • PR1948: Only try and symlink debuginfo if STRIP_POLICY is other than no_strip
    • PR1948: Fix indenting
    • PR1966: Move to new OpenJDK bug URL format
    • RH1015432: java-1.7.0-openjdk: Fails on PPC with StackOverflowError (revised fix for PPC32)
  • PPC & AIX port
    • Adapt AIX port to 5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion
    • Adapt aix to 8022507
    • Fix aix after 8022507: SIGSEGV at ParMarkBitMap::verify_clear()
    • S8050942: PPC64: implement template interpreter for ppc64le
    • S8050972: Concurrency problem in PcDesc cache

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:

  • 6e36b5922d6a30b28a3387c60cf698461f12ae6471c9deab9c30763cb3505988 icedtea-2.5.2.tar.gz
  • 77ebbd7b0c5e5878c779d04342013f9fd7e4c3ad12fa8388e556cbbe74fcce68 icedtea-2.5.2.tar.gz.sig
  • 171e1ac6a549a9b15fec30fa308c777d0ac7498cc96058c4a2bcb0b0d0b45bf0 icedtea-2.5.2.tar.xz
  • 985835869ccb2e6841ed41edf69b1d9f6aec1b3e5b4154009ca2561bbd8c01a8 icedtea-2.5.2.tar.xz.sig

The checksums can be downloaded from:

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.2.tar.gz

or:

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

then:

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

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

Happy hacking!

Ages and ages I wrote about letting Emacs code access the notification area.  I have more to say about it now, but first I want to bore you with some rambling thoughts and some history.

The “notification area” is also called the “status icon area” or the “systray” — it is a spot that holds some icons that are under control of various applications.

I was a fan of the notification area since it first showed up in Gnome.  I recognized it instantly as the thing I wanted that I hadn’t realized I wanted.

Now, as you know, the notification area has fallen on hard times.  It’s been removed in Gnome 3… I searched a bit for the rationale for this deletion, which as far as I can tell is just that some applications abused it, whatever that means; or that it was used inconsistently, which I think the web has conclusively proven is fine by users.  Coming from the Emacs perspective, where one can customize the somewhat-equivalent of the status area (see those recent posts on diminishing minor-mode lighters in the mode line…), and where a certain amount of per-mode idiosyncrasy is the norm, these seem like an inadequate reasons.

However, the reason doesn’t really matter.  I love the notification area!  When I moved more of my daily desktop use back into Emacs (the tides are strong but slow, and take years to come in or go out), I hooked Emacs up to it, and made it a part of my basic configuration.

It’s indispensable now.  What I particularly like about it is that it is both noticeable and unobtrusive — the former because I can have the icons blink on important events, and the latter because the icons don’t move around or obscure other windows.

Ok!  You should use it!  And I totally plan to tell you how, but first some boring history.

My original post relied on a hacked version of the Gnome zenity utility.  This turned out to be a real pain over time.  I had to rebuild it periodically, adding hacks (once removing chunks), etc.  Sharing it with others was hard.  And, for whatever reason, the patches in Gnome bugzilla were completely ignored.  Bah.

A bit later I wrote a big patch to Emacs to put all this into the core.  That patch was rejected, more or less.  Bah two.

Then even later I flirted with KDE for a bit.  Yes.  KDE had the nice idea to expose the notification area via dbus, and Emacs could talk dbus… so I did the obvious thing in elisp.  However the KDE notification area was pretty buggy and in the end I had to abandon it as well.

So, it was back to zenity… until this week, during my funemployment.  I rewrote my hacks in Python.  This was so easy I wish I’d done it years and years ago.

I’m not sure what the moral of this story is.  Maybe that my obsession is your gain.  Or maybe that I have trouble letting go.

Anyway, the result is here, on github, or in marmalade.  You’ll need Python and the new (introspection-based) Python Gtk interfaces.  This of course is no trouble to install.  The package includes the base status icon API, plus basic UIs for ERC and EMMS.  Try it out and let me know what you think.

While streamlining my mode line, I wrote another little mode-line feature that I thought of ages ago — using the background of the mode-line to indicate the current position in the buffer. I didn’t like this enough to use it, but I thought I’d post it since it was a fun hack.

First, make sure the current mode line is kept:

(defvar tromey-real-mode-line-format mode-line-format)

Now, make a little function that format the mode line using the standard rules and then applies a property depending on the current position in the buffer:

(defun tromey-compute-mode-line ()
  (let* ((width (frame-width))
     (line (substring 
        (concat (format-mode-line tromey-real-mode-line-format)
            (make-string width ? ))
        0 width)))
    ;; Quote "%"s.
    (setq line
      (mapconcat (lambda (c)
               (if (eq c ?%)
               "%%"
             ;; It's absurd that we must wrap this.
             (make-string 1 c)))
             line ""))

    (let ((start (window-start))
      (end (or (window-end) (point))))
      (add-face-text-property (round (* (/ (float start)
                       (point-max))
                    (length line)))
                  (round (* (/ (float end)
                       (point-max))
                    (length line)))
                  'region nil line))
    line))

We have to do this funny wrapping and “%”-quoting business here because the :eval form returns a mode line format — not just text — and because the otherwise appealing :propertize form doesn’t allow computations.

Also, I’ve never understood why mapconcat can’t handle a character result from the map function.  Anybody?

Now set this to be the mode line:

(setq-default mode-line-format '((:eval (tromey-compute-mode-line))))

The function above changes the background of the mode line corresponding to the current window’s start and end positions.  So, for example, here we are in the middle of a buffer that is bigger than the window:

Screenshot - 08222014 - 12:52:19 PM

I left this on for a bit but found it too distracting.  If you like it, use it. You might like to remove the mode-line-position stuff from the mode line, as it seems redundant with the visual display.

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...

The JavaOne 2014 content catalog is now live. As in the previous years, I took the opportunity to look for the talks and BOFs with OpenJDK in their title, or abstract, and pull them together in a list:

  • CON5177 - Banking on OpenJDK: How Goldman Sachs Is Using and Contributing to OpenJDK
    With OpenJDK you can gain a deeper understanding of the Java platform as well as improve it to suit your needs. OpenJDK has indeed made an positive impact on software development. This session discusses how and why Goldman Sachs got involved with the OpenJDK project and its experiences in working with the OpenJDK community and contributing patches. It provides examples of how the company uses the OpenJDK source code and builds for performance tuning and optimization.

  • BOF2890 - The OpenJDK Harfbuzz Integration Project
    Harfbuzz is rapidly becoming the new standard OpenType complex text layout library for open source projects. Java 2D in JDK 9 aims to use it to replace the long-standing use of the ICU library, giving JDK 9 a modern, up-to-date library with better script and font support. An OpenJDK project has been approved for this. This BOF is a forum where the project’s developers can interact with interested Java developers and solicit ideas and feedback.

  • UGF9755 - The OpenJDK Project: Your Java. Our Java.
    Millions of lines of code, written in dozens of different languages, ported to a long list of platforms. The numbers of the OpenJDK Project are impressive. But even more impressive is the community growing around it. With each new release of Java, OpenJDK gets more participation and collaboration, and that pushes trust and adoption. OpenJDK is making Java more exciting and more trustworthy and promoting faster changes to Java and wider adoption of new features. The panel in this session brings together community participants of OpenJDK sharing the experiences, joys, and frustrations of being part of a huge, contradicting project. Come hear their war stories, and learn why you should care and how this can help you, your career, and all of us.

  • CON3008 - Sumatra OpenJDK Project Update: Parallelize Yourself with the Stream API
    The Sumatra Project aims to enable execution of a suitable portion of Java applications on GPUs. GPUs can offer huge performance gains for some workloads, but it used to require special setup for the application to execute on the GPU. The project is leveraging the parallel execution features in the Stream API to make the offload of Java methods to a GPU as simple and transparent as possible. This session presents an overview of the project, which intends to fully integrate GPU execution into the JDK; shows its current features; and shows how the OpenJDK Graal compiler is being used to produce the GPU code. It also demonstrates how to use lambdas and the Stream API that will enable application code to be transparently offloaded to the GPU.

  • BOF4884 - OpenJDK Adoption: Learn How You and Your JUG Can Contribute to Java’s Future
    Many of us know about the OpenJDK and the fact that it is now the open source reference implementation for the JDK, but do we know what goes on behind the scenes? You have hopefully also seen an OpenJDK hackday being run by your local JUG, or perhaps an OpenJDK hackergarten event at a recent conference, but do you wonder how these things are organized? Perhaps most importantly, do you want to get involved yourself or help your JUG get involved? If so, this is the panel for you! Attend this session for a lively discussion of all things OpenJDK, and please be sure to bring lots of questions.

  • BOF3312 - The Sumatra OpenJDK Project: What Can I Offload to the GPU?
    The Sumatra Project is enabling execution of Java on GPUs, using the JDK 8 Stream API and its parallel() directive. If you are interested in the details of what can be offloaded to the GPU, this BOF is for you. It explores a few areas in more depth: what kinds of Stream API patterns we can currently offload, how Sumatra devices with coherent access to system memory can allocate objects on the Java heap, and how Sumatra devices with coherent access to system memory can throw exceptions and support GC safe points. Attendees will be able to give feedback to Sumatra developers on what Java patterns they find important for Sumatra to support.

  • UGF9754 - Adopting Java: Create Java’s Future. Now.
    Java technology evolves through a public, community effort. It starts with the wide experimentation done in and around Java; takes shape in the fast-paced open source development of the OpenJDK project; and gets buy-in, adoption, and competition through the standardization efforts of the JCP. Instead of waiting for the future to happen, developers are getting involved and creating the future. Now. And you too can be part of the change. This panel discussion addresses the increasing community involvement related to Java. Come learn about the Adopt programs (Adopt the OpenJDK and Adopt a JSR) run by Java User Groups around the world. Learn about the open source experiments happening around Java. Find your passion. Change Java. Change the world.

  • CON5396 - Adapt DIO APIs to Your Board or Hardware
    This session demonstrates how to extend Java’s Device I/O APIs to support custom devices and configurations. The Device I/O project aims to provide a Java-level API for accessing peripheral devices on embedded platforms. Take a closer look at the OpenJDK Device I/O Project with an eye toward learning how to customize the setup for your own hardware. Learn how to use the service provider interface to provide implementations for new devices and new implementations for existing ones.

  • CON1913 - Java Concurrency Under the Hood
    This session features an overview of hardware memory models and then goes on to how it relates to the Java world. A fun live demo follows, with lots of digging through OpenJDK sources and showing how volatiles and synchronized blocks are implemented.

  • CON5394 -
    Introduction to Java DIO APIs
    This presentation is an introduction to the OpenJDK Device I/O project, which aims to provide a Java-level API for accessing peripheral devices on embedded platforms. You can access low-level devices by writing only Java. The session includes a short tutorial showing how to use the API to communicate with different peripheral devices.

  • BOF3108 - Troubleshooting with Serviceability and the New Runtime Monitoring Tool HeapStats
    OpenJDK has very useful serviceability tools for troubleshooting—such as serviceability agents, JVMTI, jstat, and jdb—but you need to learn how to choose and use those tools differently in various trouble scenarios and prepare before your application goes live. This session’s presenters learned this via a lot of troubleshooting with OpenJDK and developed HeapStats, which attaches a hotspot virtual machine to gather detailed Java runtime information continuously for after-the-fact analysis. This session presents an overview, compares the technology behind serviceability tools and HeapStats, and describes how these tools have helped them in some real troubleshooting use cases.

  • TUT3419 - Understanding JIT Compilation with JITWatch
    This tutorial explores the JIT compilation subsystem of Java and how to use JITWatch, an open source tool that can analyze JIT compilation logs from both Oracle and OpenJDK and help track down performance problems related to JIT compilation, such as important methods that are not being compiled.

  • CON5216 - Shenandoah: An Open Source Garbage Collector (JEP 189) with an Ultralow Pause Time
    Back in the Lisp machine days, hitting a GC pause meant that it was time to go get a cup of coffee. JVMs do better by using parallel (multiple threads working together) and concurrent (GC threads working while the mutator is running) techniques, but they can still cause unacceptably long pause times with today’s large heaps. This session discusses a new GC algorithm being developed at Red Hat for OpenJDK. Shenandoah is the first open source GC algorithm for OpenJDK that does marking and evacuation concurrently with running Java threads. Performing evacuation concurrently makes it possible to hit much stricter response time goals.

  • CON2662 - Diagnosing Performance Issues with Thermostat
    Debugging performance problem can be a daunting task, especially when you are short on time and lack proper tools that will integrate seamlessly into your workflow. Thermostat was designed to answer all questions related to performance measurement. It takes advantage of all the performance metrics and serviceability features of OpenJDK to provide a holistic view of the system. In this session, attendees will get a chance to see Thermostat in action as it is used to analyze programs, gather data, and debug issues affecting performance and functionality.

  • BOF3297 - Meet the Oracle Java and JavaFX Client Teams
    This BOF is an excellent opportunity to meet development engineers from the Oracle JavaFX, AWT/Swing, and Java 2D teams. It’s expected to be a lively discussion about the development process, progress over the past year, and future plans for the Java UI. Likely topics include the roadmap and features for JDK 8 update releases, plans and priorities for JDK 9, and involvement in OpenJDK and OpenJFX projects.

  • CON5150 - Safety Not Guaranteed: sun.misc.Unsafe and the Quest for Safe Alternatives
    Java is designed to be a safe platform. For a set of advanced developers innovating on the Java platform and pushing it to new limits, that safety comes with an unacceptable cost: either they cannot do what they need to do or cannot do it fast enough. In such cases, those advanced developers sacrifice safety and reach for a very sharp tool, an unsupported class within OpenJDK named “sun.misc.Unsafe,” where safety is not guaranteed. However, there is a problem. Unsafe is probably going away. Learn more in this session.

  • BOF4004 - How to Make Your JUG and Java More Awesome
    Bring your questions about how to increase participation within your JUG and also how to magnify the impact of your JUG’s contributions. This session looks at how you can quickly get a critical mass of projects in a JUG that also help improve the core Java ecosystem. These can include OpenJDK hackdays, support for Java Specification Requests (JSRs), Java talks, and speaking at workshops or unconferences. The presentation covers how you can improve participation in JUGs, be they small or large or even if your community members aren’t all located in the same city.

  • CON6275 - JDK 8 for Mobile iOS and Android Devices
    JDK 8 has introduced a new Compact Profiles feature that allows for three subsets of Java SE 8 APIs that are compliant with the JDK 8 spec. Compact Profiles will enable the creation of JDK 8 Java runtimes that will be able to support configurations that previously were possible only with a subset of JDK 1.5. This session describes the contents of Compact Profiles, how to build them, and details of the Oracle-provided OpenJDK and binary implementations for embedded and mobile. The presentation describes Compact Profiles use cases such as the embedded, iOS, and Android mobile platforms and application store packaging.

  • BOF6563 - What’s New in Java SE Embedded
    This session explores how Java SE Embedded 8 brings new technologies from Java SE 8 into the hands of embedded systems developers. It explains a key feature of SE 8—compact profiles—and how developers use them for reduced footprint deployments. It also looks at additional features of Java SE Embedded 8 such as footprint reduction via the “minimal VM,” plus general performance and serviceability improvements. Take a drive down the accelerated roadmap for Java SE Embedded 8 updates, and see the new features supported or planned, including customized class data sharing, new platform support, crypto acceleration, and more performance and footprint improvements. The presentation also discusses the OpenJDK API projects to bring enhanced device and wireless APIs to the Java SE Embedded platform.

  • BOF1704 - Community First: Bringing Java to the Community
    This hands-on session discusses how user groups can best address the needs of their members. You are encouraged to attend if you're a user group leader or a user group member. Topics include
    • vJUG – Virtual content for the community and how this can best be delivered to you
    • Adopt OpenJDK – Are you using this? Do you know about it? How can you as a group better make use of it?
    • Adopt a JSR – Are you using this? Do you know about it? How can you as a group better make use of it?
    • What are you missing out on? How can user group leaders better help?

  • CON3979 - Going Native: Bringing FFI to the JVM
    Write once, run anywhere has served us well over the years, but eventually everyone needs to use code that doesn’t run on the JVM. There are native libraries out there for crypto, graphics, data stores, computation, user interfaces, and much more, but they’ve been hard or impossible to use from JVM-based code. Until now. The Java Native Runtime (JNR) is a high-speed foreign function interface (FFI) for calling native code from Java without ever writing a line of C. Based on the success of JNR, JDK Enhancement Proposal (JEP) 191 will bring FFI to OpenJDK as an internal API. And hopefully a JSR for Java 9 will tightly integrate and standardize an FFI API. Learn more in this session. This talk will explore current and future FFI options, and show you how to help.



That's a total of 21 sessions, up from 14 last year. I believe that means this year's JavaOne is featuring the most sessions mentioning OpenJDK at a JavaOne, ever.

With presentations, tutorials and BOFs involving a diverse roster of speakers from AMD, Deutsche Bank, Digital Inspiration, Goldman Sachs, IBM, jClarity, NTT, OpenCredo, Oracle, Red Hat, SouJava and Zero Turnaround, JavaOne is the best place this year to learn about OpenJDK.

See you there!

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

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 7 support in the 2.4.x series with the July 2014 security fixes.

Please note that this will be the *FINAL* release in the 2.4.x series. Users are encouraged to upgrade to the 2.5.x series as soon as possible. There will NOT be a 2.4.x update for 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.

Full details of the release can be found below.

What’s New?

New in release 2.4.8 (2014-07-23)

  • Security fixes
  • Backports
    • S5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion
    • S6571600: JNI use results in UnsatisfiedLinkError looking for libmawt.so
    • S7131153: GetDC called way too many times – causes bad performance.
    • S7190349: [macosx] Text (Label) is incorrectly drawn with a rotated g2d
    • S8001108: an attempt to use “<init>” as a method name should elicit NoSuchMethodException
    • S8001109: arity mismatch on a call to spreader method handle should elicit IllegalArgumentException
    • S8008118: (process) Possible null pointer dereference in jdk/src/solaris/native/java/lang/UNIXProcess_md.c
    • S8013611: Modal dialog fails to obtain keyboard focus
    • S8013809: deadlock in SSLSocketImpl between between write and close
    • S8013836: getFirstDayOfWeek reports wrong day for pt-BR locale
    • S8014460: Need to check for non-empty EXT_LIBS_PATH before using it
    • S8019853: Break logging and AWT circular dependency
    • S8019990: IM candidate window appears on the South-East corner of the display.
    • S8020191: System.getProperty(“os.name”) returns “Windows NT (unknown)” on Windows 8.1
    • S8022452: Hotspot needs to know about Windows 8.1 and Windows Server 2012 R2
    • S8023990: Regression: postscript size increase from 6u18
    • S8024283: 10 nashorn tests fail with similar stack trace InternalError with cause being NoClassDefFoundError
    • S8024616: JSR292: lazily initialize core NamedFunctions used for bootstrapping
    • S8024648: 7141246 & 8016131 break Zero port (AArch64 only)
    • S8024830: SEGV in org.apache.lucene.codecs.compressing.CompressingTermVectorsReader.get
    • S8025588: [macosx] Frozen AppKit thread in 7u40
    • S8026404: Logging in Applet can trigger ACE: access denied (“java.lang.RuntimePermission” “modifyThreadGroup”)
    • S8026705: [TEST_BUG] java/beans/Introspector/TestTypeResolver.java failed
    • S8027196: Increment minor version of HSx for 7u55 and initialize the build number
    • S8027212: java/nio/channels/Selector/SelectAfterRead.java fails intermittently
    • S8028285: RMI Thread can no longer call out to AWT
    • S8029177: [Parfait] warnings from b117 for jdk.src.share.native.com.sun.java.util.jar: JNI exception pending
    • S8030655: Regression: 14_01 Security fix 8024306 causes test failures
    • S8030813: Signed applet fails to load when CRLs are stored in an LDAP directory
    • S8030822: (tz) Support tzdata2013i
    • S8031050: (thread) Change Thread initialization so that thread name is set before invoking SecurityManager
    • S8031075: [Regression] focus disappears with shift+tab on dialog having one focus component
    • S8031462: Fonts with morx tables are broken with latest ICU fixes
    • S8032585: JSR292: IllegalAccessError when attempting to invoke protected method from different package
    • S8032740: Need to create SE Embedded Source Bundles in 7 Release
    • S8033278: Missed access checks for Lookup.unreflect* after 8032585
    • S8034772: JDK-8028795 brought a specification change to 7u55 release and caused JCK7 signature test failure
    • S8035283: Second phase of branch shortening doesn’t account for loop alignment
    • S8035613: With active Securitymanager JAXBContext.newInstance fails
    • S8035618: Four api/org_omg/CORBA TCK tests fail under plugin only
    • S8036147: Increment hsx 24.55 build to b02 for 7u55-b11
    • S8036786: Update jdk7 testlibrary to match jdk8
    • S8036837: Increment hsx 24.55 build to b03 for 7u55-b12
    • S8037012: (tz) Support tzdata2014a
    • S8038306: (tz) Support tzdata2014b
    • S8038392: Generating prelink cache breaks JAVA ‘jinfo’ utility normal behavior
    • S8042264: 7u65 l10n resource file translation update 1
    • S8042582: Test java/awt/KeyboardFocusmanager/ChangeKFMTest/ChangeKFMTest.html fails on Windows x64
    • S8042590: Running form URL throws NPE
    • S8042789: org.omg.CORBA.ORBSingletonClass loading no longer uses context class loader
    • S8043012: (tz) Support tzdata2014c
  • Bug fixes
    • Fix accidental reversion of PR1188 for armel
    • PR1781: NSS PKCS11 provider fails to handle multipart AES encryption
    • PR1830: Drop version requirement for LCMS 2
    • PR1833, RH1022017: Report elliptic curves supported by NSS, not the SunEC library
    • RH905128: [CRASH] OpenJDK-1.7.0 while using NSS security provider and kerberos
  • AArch64 port
    • AArch64 C2 instruct for smull
    • Add a constructor as a conversion from Register – RegSet. Use it.
    • Add RegSet::operator+=.
    • Add support for a few simple intrinsics
    • Add support for builtin crc32 instructions
    • Add support for CRC32 intrinsic
    • Add support for Neon implementation of CRC32
    • All address constants are 48 bits in size.
    • C1: Fix offset overflow when profiling.
    • Common frame handling for C1/C2 which correctly handle all frame sizes
    • Correct costs for operations with shifts.
    • Correct OptoAssembly for prologs and epilogs.
    • Delete useless instruction.
    • Don’t use any form of _call_VM_leaf when we’re calling a stub.
    • Fast string comparison
    • Fast String.equals()
    • Fix a tonne of bogus comments.
    • Fix biased locking and enable as default
    • Fix instruction size from 8 to 4
    • Fix opto assembly for shifts.
    • Fix register misuse in verify_method_data_pointer
    • Fix register usage in generate_verify_oop().
    • Implement various locked memory operations.
    • Improve C1 performance improvements in ic_cache checks
    • Improve code generation for pop(), as suggested by Edward Nevill.
    • Improvements to safepoint polling
    • Make code entry alignment 64 for C2
    • Minor optimisation for divide by 2
    • New cost model for instruction selection.
    • Offsets in lookupswitch instructions should be signed.
    • Optimise addressing of card table byte map base
    • Optimise C2 entry point verification
    • Optimise long divide by 2
    • Performance improvement and ease of use changes pulled from upstream
    • Preserve callee save FP registers around call to java code
    • Remove obsolete C1 patching code.
    • Remove special-case handling of division arguments. AArch64 doesn’t need it.
    • Remove unnecessary memory barriers around CAS operations
    • Restore sp from sender sp, r13 in crc32 code
    • Restrict default ReservedCodeCacheSize to 128M
    • Rewrite CAS operations to be more conservative
    • Save intermediate state before removing C1 patching code.
    • Tidy up register usage in push/pop instructions.
    • Tidy up stack frame handling.
    • Use 2- and 3-instruction immediate form of movoop and mov_metadata in C2-generated code.
    • Use an explicit set of registers rather than a bitmap for psh and pop operations.
    • Use explicit barrier instructions in C1.
    • Use gcc __clear_cache instead of doing it ourselves

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:

  • 5bb6ece0ca8f2022056a2e455330c5324d1c110b278dbf5af5e9d48babebcd40 icedtea-2.4.8.tar.gz
  • 59b280c9d342db45c3f810bfdf002806f14faabac1c7fd5c6d2c28cecd13f9d2 icedtea-2.4.8.tar.gz.sig
  • 3fa64e2e92b08fb69eaec72a85ee3322efb1cfacc65e15b5b7fdef4abbdd17a2 icedtea-2.4.8.tar.xz
  • 60c060fa3e438f338128f616f7b8d23ff15d5642e8d1547bb7e026121e7affc8 icedtea-2.4.8.tar.xz.sig

The checksums can be downloaded from:

A 2.4.8 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.4.8.tar.gz

or:

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

then:

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

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

Happy hacking!

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.)

DataBasin, the clean-room impelmentation of a data extraction tool for SalesForce.com available for GNUstep and Mac just made a big leap forward!

If you have ever done a SELECT in salesforce.com, you might have noticed that the results are not ordered and that semi-joined fields ("." notation) are handled strange because a whole object is returned.

DataBasin extracts the  columns of the CSV file by checking the first row of the dataset and recursing on the field names of salesforce's response. The effects in DataBasin are the following:
  • The field order is not preserved
  • If a sub-object is queried, all those fields are grouped together in that object
  • If more than one field is queried on a sub-object and on certain record this object is missing, the number of columns between records is inconsistent: salesforce.com doesn't return the whole object and DataBasin iterates record after record in the sub-object, but if it it is totally missing, only one empty column will be written, not as many as needed
  • Capitalization of the column names doesn't get preserved (compared to the above issues, something really minor)

I added a new option available in write out fields in the order of the query.

This feature implies a more complex under the hood. For each record gotten in the response, the field names are reconstructed as before (e.g. by recursing inside sub-objects) and put in a Dictionary.

The original SOQL query is parsed and the field names extracted, then these names are used as keys for each record dictionary and written out.
  • Order preserved, also with sub-objects
  • Fields preserved and empty values are written even if whole sub-objects are missing
  • Case is preserved
This approach looks fine and comes with a relatively small performance penalty, however it is delicate because during parsing of the query, many naming subtleties of Salesforce.com needs to be inferred, that is, DataBasin tries to infer how the name in the Response will be:
  • field aliases
  • aggregate names with no alias, which are called progressively Expr0, Expr1
  • idiosyncrasies with aggregate functions. A field in a sub-objects is called Object__c.Field__c when in a regular query, but when used in an aggregate query, only Field__c is used, disregarding the join-depth
  • COUNT() vs.COUNT(Id)
I hope I have not missed any! in any case, enjoy!



This feature is available now both in Select and Select-Identify, since it is a problem of the CSV Write backend and enhances DataBasin operation usability greatly, bringing it on par with DataLoader.
Since DataLoader performces similar transformation and sometimes produces wrong results, I left this feature as optional with the flag "Write fields in query order".

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.

I have an ol' OmniBook 800CT. A small, interesting computer, for its time, extremely advanced!
Small form factor, but still a very nice keyboard, something unmatched on modern netbooks. The unique pop-out mouse. The series started out with 386 processor, b&w display and ROM expansions.
The 800CT is one of the latest models: same form factor, SCSI connector, but color screen (800x600) and a hefty Pentium 133Mhz!
But only 32 MB of ram (the kernel report 31 of real mem, 24 avail mem)

Original 5.4 kernel: 9.2M
Custom kernel: 5.0 M

This shrinkage is quite hefty! almost 50%! More than raw disk usage, this new kernel boots faster and leaves  more free memory. Enough more that X11 is now almost usable

How can this be achieved? essentially by removing unused kernel options. If you remove drivers which you know you don't need because you don't have the hardware (and won't use it, e.g. you know you won't plug-in a certain card in the future) then you configure it out, it won't be built and it won't get in your kernel.
On an old laptop with no expansion except the ports and the PCMCIA port it has, this is relatively easy.

To build your custom kernel, follow the OpenBSD FAQ.

The main theory is to take the kernel configuration file, skim over it line by line it and see if you have the hardware, which you know by checking your dmesg. Dmesg shows which devices and drivers were loaded.Remember that you do not modify GENERIC, but a copy of it.

You can automate this with a tool called dmassage: it will parse your GENERIC configuration and produce an optimal tuned version, however it will not work out of the box.
Why? there are drivers which do not compile if other drivers are not present.

I'm unsure if this is really a bug, in my opinion it is at least "unclean" code, however since mostly this kind of extreme driver-picking is not done, it is not fatal and probably won't be fixed.

 If you remove all drivers at once, you won't easily find out one which one breaks, so my suggestion is to remove them in sets. One by-one is surely too tedious, since for each you need to make a build.
  1. remove X drivers
  2. build, if it works, copy the configuration file as a backup
  3. test the kernel, optionally, by booting it
  4. continue removal

Thus, in case of breakage, you can narrow it down to a less options.

If your mahcine doesn't have a certain bus, you may remove all drievrs attached to each. But proceed from the leaves, not the trunk: gradually remove the peripheral drivers before removing the bus support.

In my case, I found that an unremovable driver is:
et*    at pci?                # Agere/LSI ET1310


Remember that you are running an unsupported kernel, if you want support for a problem, better try it with the original kernel, of which you should anyway for safety retain a backup copy during the iterative building process.

Addition:

In X11, which needs to be set to 800x600 8-bit mode, I had to uncomment these lines:
    #Option "progLcdModeRegs" "true"
#Option "progLcdModeStretch" "true"

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

 
I'll be joining my colleagues in the Oracle office in Hamburg to chat about development and other roles within a large IT company as part of the Girls' Day in Germany.

Fiorenza Sofia :)

On 19th of March the most wonderful and happiest event in my life happened, my daughter was born :) at 17:16, in Karlsruhe.

Just in time for Fathers’ day, which happens exactly on 19th of March in Italy (not in Germany, so I can celebrate twice ;)

Everybody said that being a father is a life changing event. While I started to understand it already from those past 9 months, I don’t think I really got prepared to fully appreciate what it really means. In fact, Roman told me that you have 9 months to prepare and inevitably get unprepared to this appointment!

Indeed, and it is really beyond description, but I feel so proud and happy, and scared, all the feelings are mixed up… but above all, I feel full of love, it is so wonderful to look at her smiling (and she does smile a lot!), a warm sense of calm and peace and happiness goes all around, the air is pregnated with it! Everyone should experience this feeling at least once, the World would be so much a better place, I think.

Anyway, it’s time to go and look at her now, she grows so fast and I don’t want to miss not even a minute of her life!


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.

Tomorrow marks 2 years I’m at Red Hat, and it has been so far a very exciting journey, for one of the most interesting and awesome company around. I’m glad I’m here!

Only problem is that I started on 29th of February, and tomorrow is actually 1sth of March… so I need to wait two years more before I can celebrate even the first year… ouch ;) But at least I’ll be able to do a very awesome party by  then!


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.