GNU Classpath

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 ... [More] , 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... [Less]

The default mode line looks like this: At least, it looks sort of like this if you ignore the lamenesses in the screenshot. If you’re like me you probably don’t remember what all these things mean, at least not without looking them up.  What’s that ... [More] “U”?  Why the “:” or why three hyphens? At a local Emacs meetup with Damon Haley and Greg Pfeil, Greg mentioned that he’d done some experiments on using unicode characters in his mode-line.  I decided to give it a try. I took a good look at the above.  I rarely use any of it — I normally don’t care about the coding system or the line ending style.  I can’t remember the last time I had a buffer that was both read-only and modified.  The VC information, when it appears, is generally too verbose and doesn’t show me the one thing I need to know (see below).  And, though I do like to see the name of the major mode, I don’t really need to see most minor mode names; furthermore I like to have a bit of extra space so that I can use other modes that display information that I do want to see in the mode line. What’s that VC thing?  Well, ordinarily you may see something like Git-master in the mode line. But, usually I already know the version control system being used — or even if I don’t know, I probably don’t care if I am using VC. By default the branch name is in there too. This can be quite long and seems to get stale when I switch branches; and anyway because I do a lot of work via vc-dir, I don’t really need this in every buffer anyway. However, what is missing is that the mode-line won’t tell me if a buffer should be registered with version control but is not.  This is a pretty common source of errors. So, first the code to deal with the VC state.  We need a bit more code than you might think, because the information we need isn’t already computed, and my tries to compute it while updating the mode line caused weird behavior.  Our rule for “should be registered” is “a VC back end claims this file, but the file isn’t actually registered”: (defvar tromey-vc-mode nil) (make-variable-buffer-local 'tromey-vc-mode) (require 'vc) (defun tromey-vc-command-hook (&rest args)   (let ((file-name (buffer-file-name)))     (setq tromey-vc-mode (and file-name                   (not (vc-registered file-name))                   (ignore-errors                 (vc-responsible-backend file-name)))))) (add-hook 'vc-post-command-functions #'tromey-vc-command-hook) (add-hook 'find-file-hook #'tromey-vc-command-hook) (defun tromey-vc-info ()   (if tromey-vc-mode       (propertize (string #x26c3 32) 'face 'error)     " ")) We’ll use that final function in the mode line. Note the odd character in there — my choice was U+26C3 (BLACK DRAUGHTS KING), since I thought it looked disk-drive-like — but you can easily replace it with something else. (Also note the weirdness of using string rather than a string constant. This is just for WordPress’ benefit as its editor kept mangling the actual character.) To deal with minor modes, I used diminish. This made it easy to remove any display of some modes that I don’t care to know about, and replace the name of some others with a single character: (require 'diminish) (diminish 'abbrev-mode) (diminish 'projectile-mode) (diminish 'eldoc-mode) (diminish 'flyspell-mode (string 32 #x2708)) (diminish 'auto-fill-function (string 32 #xa7)) (diminish 'isearch-mode (string 32 #x279c)) Here flyspell is U+2708 (AIRPLANE), auto-fill is U+00A7 (SECTION SIGN), and isearch is U+279C (HEAVY ROUND-TIPPED RIGHTWARDS ARROW).  Haha, Unicode names. I wanted to try out which-func-mode, now that I had extra space on the mode line, so: (setq which-func-unknown "") (which-function-mode) Finally, we can use all the above and remove some other things from the mode line at the same time: (setq-default mode-line-format '("%e" (:eval (if (buffer-modified-p) (propertize (string #x21a7) 'face 'error) " ")) (:eval (tromey-vc-info)) " " mode-line-buffer-identification " " mode-line-position " " mode-line-modes mode-line-misc-info)) The “modified” character in there is U+21A7 (DOWNWARDS ARROW FROM BAR). Here’s how it looks normally (another badly cropped screenshot): Here’s how it looks when the file is not registered with the version control system: And here’s how it looks when the file is also modified: Occasionally I run into some other minor mode I want to diminish, but this is easily done by editing it into my .emacs and evaluating it for immediate effect. [Less]

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 ... [More] 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! [Less]

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 ... [More] JavaFX support. 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. [Less]

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 ... [More] 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. [Less]

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 ... [More] 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. [Less]

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 ... [More] (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: 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. [Less]

Sad to receive news this morning that a long time friend and colleague, Peter Miller, had passed. “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. ... [More] 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 [Less]

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 ... [More] 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 S8029755, CVE-2014-4209: Enhance subject class S8030763: Validate global memory allocation S8031340, CVE-2014-4264: Better TLS/EC management S8031346, CVE-2014-4244: Enhance RSA key handling S8031540: Introduce document horizon S8032536: JVM resolves wrong method in some unusual cases S8033055: Issues in 2d S8033301, CVE-2014-4266: Build more informative InfoBuilder S8034267: Probabilistic native crash S8034272: Do not cram data into CRAM arrays S8034985, CVE-2014-2483: Better form for Lambda Forms S8035004, CVE-2014-4252: Provider provides less service S8035009, CVE-2014-4218: Make Proxy representations consistent S8035119, CVE-2014-4219: Fix exceptions to bytecode verification S8035699, CVE-2014-4268: File choosers should be choosier S8035788. CVE-2014-4221: Provide more consistency for lookups S8035793, CVE-2014-4223: Maximum arity maxed out S8036571: (process) Process process arguments carefully S8036800: Attribute OOM to correct part of code S8037046: Validate libraries to be loaded S8037076, CVE-2014-2490: Check constant pool constants S8037157: Verify <init> call S8037162, CVE-2014-4263: More robust DH exchanges S8037167, CVE-2014-4216: Better method signature resolution S8039520, CVE-2014-4262: More atomicity of atomic updates 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: http://icedtea.classpath.org/download/source/icedtea-2.4.8.tar.gz http://icedtea.classpath.org/download/source/icedtea-2.4.8.tar.xz 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: http://icedtea.classpath.org/download/source/icedtea-2.4.8.tar.gz.sig http://icedtea.classpath.org/download/source/icedtea-2.4.8.tar.xz.sig These are produced using my public key. See details below. PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 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: http://icedtea.classpath.org/download/source/icedtea-2.4.8.sha256 A 2.4.8 ebuild for Gentoo is available. The following people helped with these releases: Andrew Hughes (all backports & bug fixes, release management) 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! [Less]

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 ... [More] 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). [Less]