Planet Classpath

About a month ago, Fedora 24 has been released. This is an important milestone for Christine and myself, because it includes Shenandoah in its Java VM by default. We consider this our first official release!

If you want to try it out, it’s very simple: pass -XX:+UseShenandoahGC at the cmd line, and your favorite application runs with Shenandoah!

Please report back any issues that you find to the shenandoah-dev mailing list.


We are pleased to announce the release of IcedTea 3.1.0!

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 8 support with the July 2016 security fixes from OpenJDK 8 u101. It also introduces a number of new features:

  • Gtk+3 support has been backported from OpenJDK 9. The particular version to use can be explicitly requested using -Djdk.gtk.version.
  • Headless builds are now supported by passing --enable-headless.
  • Builds on x86_64 can include the Shenandoah ultra-low pause time garbage collector if --with-hotspot-build=shenandoah is passed. The garbage collector is used at runtime by specifying -XX:+UseShenandoahGC
  • Use of the infinality support in fontconfig/FreeType has been forward-ported from IcedTea 2.x.

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 3.1.0 (2016-07-25)

  • Security fixes
  • New features
    • S8145547, PR1061: [AWT/Swing] Conditional support for GTK 3 on Linux
    • PR2821: Support building OpenJDK with –disable-headful
    • PR2931, G478960: Provide Infinality Support via fontconfig
    • PR3079: Provide option to build Shenandoah on x86_64
  • Import of OpenJDK 8 u92 build 14
    • S6869327: Add new C2 flag to keep safepoints in counted loops.
    • S8022865: [TESTBUG] Compressed Oops testing needs to be revised
    • S8029630: Thread id should be displayed as a hex number in error report
    • S8029726: On OS X some dtrace probe names are mismatched with Solaris
    • S8029727: On OS X dtrace probes Call<type>MethodA/Call<type>MethodV are not fired.
    • S8029728: On OS X dtrace probes SetStaticBooleanField are not fired
    • S8038184: XMLSignature throws StringIndexOutOfBoundsException if ID attribute value is empty String
    • S8038349: Signing XML with DSA throws Exception when key is larger than 1024 bits
    • S8041501: ImageIO reader is not capable of reading JPEGs without JFIF header
    • S8041900: [macosx] Java forces the use of discrete GPU
    • S8044363: Remove special build options for unpack200 executable
    • S8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for hotspot ARCH
    • S8046611: Build errors with gcc on sparc/fastdebug
    • S8047763: Recognize sparc64 as a sparc platform
    • S8048232: Fix for 8046471 breaks PPC64 build
    • S8052396: Catch exceptions resulting from missing font cmap
    • S8058563: InstanceKlass::_dependencies list isn’t cleared from empty nmethodBucket entries
    • S8061624: [TESTBUG] Some tests cannot be ran under compact profiles and therefore shall be excluded
    • S8062901: Iterators is spelled incorrectly in the Javadoc for Spliterator
    • S8064330: Remove SHA224 from the default support list if SunMSCAPI enabled
    • S8065579: WB method to start G1 concurrent mark cycle should be introduced
    • S8065986: Compiler fails to NullPointerException when calling super with Object<>()
    • S8066974: Compiler doesn’t infer method’s generic type information in lambda body
    • S8067800: Clarify java.time.chrono.Chronology.isLeapYear for out of range years
    • S8068033: JNI exception pending in jdk/src/share/bin/java.c
    • S8068042: Check jdk/src/share/native/sun/misc/URLClassPath.c for JNI pending
    • S8068162: jvmtiRedefineClasses.cpp: guarantee(false) failed: OLD and/or OBSOLETE method(s) found
    • S8068254: Method reference uses wrong qualifying type
    • S8074696: Remote debugging session hangs for several minutes when calling findBootType
    • S8074935: jdk8 keytool doesn’t validate pem files for RFC 1421 correctness, as jdk7 did
    • S8078423: [TESTBUG] javax/print/PrintSEUmlauts/PrintSEUmlauts.java relies on system locale
    • S8080492: [Parfait] Uninitialised variable in jdk/src/java/desktop/windows/native/libawt/
    • S8080650: Enable stubs to use frame pointers correctly
    • S8122944: perfdata used is seen as too high on sparc zone with jdk1.9 and causes a test failure
    • S8129348: Debugger hangs in trace mode with TRACE_SENDS
    • S8129847: Compiling methods generated by Nashorn triggers high memory usage in C2
    • S8130506: javac AssertionError when invoking MethodHandle.invoke with lambda parameter
    • S8130910: hsperfdata file is created in wrong directory and not cleaned up if /tmp/hsperfdata_<username> has wrong permissions
    • S8131129: Attempt to define a duplicate BMH$Species class
    • S8131665: Bad exception message in HandshakeHash.getFinishedHash
    • S8131782: C1 Class.cast optimization breaks when Class is loaded from static final
    • S8132503: [macosx] Chinese full stop symbol cannot be entered with Pinyin IM on OS X
    • S8133207: ParallelProbes.java test fails after changes for JDK-8080115
    • S8133924: NPE may be thrown when xsltc select a non-existing node after JDK-8062518
    • S8134007: Improve string folding
    • S8134759: jdb: Incorrect stepping inside finally block
    • S8134963: [Newtest] New stress test for changing the coarseness level of G1 remembered set
    • S8136442: Don’t tie Certificate signature algorithms to ciphersuites
    • S8137106: EUDC (End User Defined Characters) are not displayed on Windows with Java 8u60+
    • S8138745: Implement ExitOnOutOfMemory and CrashOnOutOfMemory in HotSpot
    • S8138764: In some cases the usage of TreeLock can be replaced by other synchronization
    • S8139373: [TEST_BUG] java/net/MulticastSocket/MultiDead.java failed with timeout
    • S8139424: SIGSEGV, Problematic frame: # V [libjvm.so+0xd0c0cc] void InstanceKlass::oop_oop_iterate_oop_maps_specialized<true,oopDesc*,MarkAndPushClosure>
    • S8139436: sun.security.mscapi.KeyStore might load incomplete data
    • S8139751: Javac crash with -XDallowStringFolding=false
    • S8139863: [TESTBUG] Need to port tests for JDK-8134903 to 8u-dev
    • S8139985: JNI exception pending in jdk/src/jdk/hprof/agent/share/native/libhprof
    • S8140031: SA: Searching for a value in Threads does not work
    • S8140249: JVM Crashing During startUp If Flight Recording is enabled
    • S8140344: add support for 3 digit update release numbers
    • S8140587: Atomic*FieldUpdaters should use Class.isInstance instead of direct class check
    • S8141260: isReachable crash in windows xp
    • S8143297: Nashorn compilation time reported in nanoseconds
    • S8143397: It looks like InetAddress.isReachable(timeout) works incorrectly
    • S8143855: Bad printf formatting in frame_zero.cpp
    • S8143896: java.lang.Long is implicitly converted to double
    • S8143963: improve ClassLoader::trace_class_path to accept an additional outputStream* arg
    • S8144020: Remove long as an internal numeric type
    • S8144131: ArrayData.getInt implementations do not convert to int32
    • S8144483: One long Safepoint pause directly after each GC log rotation
    • S8144487: PhaseIdealLoop::build_and_optimize() must restore major_progress flag if skip_loop_opts is true
    • S8144885: agent/src/os/linux/libproc.h needs to support Linux/SPARC builds
    • S8144935: C2: safepoint is pruned from a non-counted loop
    • S8144937: [TEST_BUG] testlibrary_tests should be excluded for compact1 and compact2 execution
    • S8145017: Add support for 3 digit hotspot minor version numbers
    • S8145099: Better error message when SA can’t attach to a process
    • S8145442: Add the facility to verify remembered sets for G1
    • S8145466: javac: No line numbers in compilation error
    • S8145539: (coll) AbstractMap.keySet and .values should not be volatile
    • S8145550: Megamorphic invoke should use CompiledFunction variants without any LinkLogic
    • S8145669: apply2call optimized callsite fails after becoming megamorphic
    • S8145722: NullPointerException in javadoc
    • S8145754: PhaseIdealLoop::is_scaled_iv_plus_offset() does not match AddI
    • S8146147: Java linker indexed property getter does not work for computed nashorn string
    • S8146566: OpenJDK build can’t handle commas in LDFLAGS
    • S8146725: Issues with SignatureAndHashAlgorithm.getSupportedAlgorithms
    • S8146979: Backport of 8046471 breaks ppc64 build in jdk8u because 8072383 was badly backported before
    • S8147087: Race when reusing PerRegionTable bitmaps may result in dropped remembered set entries
    • S8147630: Wrong test result pushed to 8u-dev
    • S8147845: Varargs Array functions still leaking longs
    • S8147857: RMIConnector logs attribute names incorrectly
    • S8148353: [linux-sparc] Crash in libawt.so on Linux SPARC
    • S8150791: 8u76 L10n resource file translation update
  • Import of OpenJDK 8 u101 build 13
    • S6483657: MSCAPI provider does not create unique alias names
    • S6675699: need comprehensive fix for unconstrained ConvI2L with narrowed type
    • S8037557: test SessionCacheSizeTests.java timeout
    • S8038837: Add support to jarsigner for specifying timestamp hash algorithm
    • S8081778: Use Intel x64 CPU instructions for RSA acceleration
    • S8130150: Implement BigInteger.montgomeryMultiply intrinsic
    • S8130735: javax.swing.TimerQueue: timer fires late when another timer starts
    • S8143913: MSCAPI keystore should accept Certificate[] in setEntry()
    • S8144313: Test SessionTimeOutTests can be timeout
    • S8146240: Three nashorn files contain “GNU General Public License” header
    • S8146387: Test SSLSession/SessionCacheSizeTests socket accept timed out
    • S8146669: Test SessionTimeOutTests fails intermittently
    • S8146993: Several javax/management/remote/mandatory regression tests fail after JDK-8138811
    • S8147994: [macosx] JScrollPane jitters up/down during trackpad scrolling on MacOS/Aqua
    • S8151522: Disable 8130150 and 8081778 intrinsics by default
    • S8151876: (tz) Support tzdata2016d
    • S8152098: Fix 8151522 caused test compiler/intrinsics/squaretolen/TestSquareToLen.java to fail
    • S8157077: 8u101 L10n resource file updates
  • Backports
    • S6260348, PR3066: GTK+ L&F JTextComponent not respecting desktop caret blink rate
    • S6778087, PR1061: getLocationOnScreen() always returns (0, 0) for mouse wheel events
    • S6961123, PR2972: setWMClass fails to null-terminate WM_CLASS string
    • S8008657, PR3077: JSpinner setComponentOrientation doesn’t affect on text orientation
    • S8014212, PR2866: Robot captures black screen
    • S8029339, PR1061: Custom MultiResolution image support on HiDPI displays
    • S8031145, PR3077: Re-examine closed i18n tests to see it they can be moved to the jdk repository.
    • S8034856, PR3095: gcc warnings compiling src/solaris/native/sun/security/pkcs11
    • S8034857, PR3095: gcc warnings compiling src/solaris/native/sun/management
    • S8035054, PR3095: JarFacade.c should not include ctype.h
    • S8035287, PR3095: gcc warnings compiling various libraries files
    • S8038631, PR3077: Create wrapper for awt.Robot with additional functionality
    • S8039279, PR3077: Move awt tests to openjdk repository
    • S8041561, PR3077: Inconsistent opacity behaviour between JCheckBox and JRadioButton
    • S8041592, PR3077: [TEST_BUG] Move 42 AWT hw/lw mixing tests to jdk
    • S8041915, PR3077: Move 8 awt tests to OpenJDK regression tests tree
    • S8043126, PR3077: move awt automated functional tests from AWT_Events/Lw and AWT_Events/AWT to OpenJDK repository
    • S8043131, PR3077: Move ShapedAndTranslucentWindows and GC functional AWT tests to regression tree
    • S8044157, PR3077: [TEST_BUG] Improve recently submitted AWT_Mixing tests
    • S8044172, PR3077: [TEST_BUG] Move regtests for 4523758 and AltPlusNumberKeyCombinationsTest to jdk
    • S8044429, PR3077: move awt automated tests for AWT_Modality to OpenJDK repository
    • S8044762, PR2960: com/sun/jdi/OptionTest.java test time out
    • S8044765, PR3077: Move functional tests AWT_SystemTray/Automated to openjdk repository
    • S8047180, PR3077: Move functional tests AWT_Headless/Automated to OpenJDK repository
    • S8047367, PR3077: move awt automated tests from AWT_Modality to OpenJDK repository – part 2
    • S8048246, PR3077: Move AWT_DnD/Clipboard/Automated functional tests to OpenJDK
    • S8049226, PR2960: com/sun/jdi/OptionTest.java test times out again
    • S8049617, PR3077: move awt automated tests from AWT_Modality to OpenJDK repository – part 3
    • S8049694, PR3077: Migrate functional AWT_DesktopProperties/Automated tests to OpenJDK
    • S8050885, PR3077: move awt automated tests from AWT_Modality to OpenJDK repository – part 4
    • S8051440, PR3077: move tests about maximizing undecorated to OpenJDK
    • S8052012, PR3077: move awt automated tests from AWT_Modality to OpenJDK repository – part 5
    • S8052408, PR3077: Move AWT_BAT functional tests to OpenJDK (3 of 3)
    • S8053657, PR3077: [TEST_BUG] move some 5 tests related to undecorated Frame/JFrame to JDK
    • S8054143, PR3077: move awt automated tests from AWT_Modality to OpenJDK repository – part 6
    • S8054358, PR3077: move awt automated tests from AWT_Modality to OpenJDK repository – part 7
    • S8054359, PR3077: move awt automated tests from AWT_Modality to OpenJDK repository – part 8
    • S8055360, PR3077: Move the rest part of AWT ShapedAndTranslucent tests to OpenJDK
    • S8055664, PR3077: move 14 tests about setLocationRelativeTo to jdk
    • S8055836, PR3077: move awt tests from AWT_Modality to OpenJDK repository – part 9
    • S8056911, PR3077: Remove internal API usage from ExtendedRobot class
    • S8057694, PR3077: move awt tests from AWT_Modality to OpenJDK repository – part 10
    • S8058959, PR1061: closed/java/awt/event/ComponentEvent/MovedResizedTwiceTest/MovedResizedTwiceTest.java failed automatically
    • S8062606, PR3077: Fix a typo in java.awt.Robot class
    • S8063102, PR3077: Change open awt regression tests to avoid sun.awt.SunToolkit.realSync, part 1
    • S8063104, PR3077: Change open awt regression tests to avoid sun.awt.SunToolkit.realSync, part 2
    • S8063106, PR3077: Change open swing regression tests to avoid sun.awt.SunToolkit.realSync, part 1
    • S8063107, PR3077: Change open swing regression tests to avoid sun.awt.SunToolkit.realSync, part 2
    • S8064573, PR3077: [TEST_BUG] javax/swing/text/AbstractDocument/6968363/Test6968363.java is asocial pressing VK_LEFT and not releasing
    • S8064575, PR3077: [TEST_BUG] javax/swing/JEditorPane/6917744/bug6917744.java 100 times press keys and never releases
    • S8064809, PR3077: [TEST_BUG] javax/swing/JComboBox/4199622/bug4199622.java contains a lot of keyPress and not a single keyRelease
    • S8067441, PR3077: Some tests fails with error: cannot find symbol getSystemMnemonicKeyCodes()
    • S8068228, PR3077: Test closed/java/awt/Mouse/MaximizedFrameTest/MaximizedFrameTest fails with GTKLookAndFeel
    • S8069361, PR1061: SunGraphics2D.getDefaultTransform() does not include scale factor
    • S8073320, PR1061: Windows HiDPI Graphics support
    • S8074807, PR3077: Fix some tests unnecessary using internal API
    • S8076315, PR3077: move 4 manual functional swing tests to regression suite
    • S8078504, PR3094: Zero lacks declaration of VM_Version::initialize()
    • S8129822, PR3077: Define “headful” jtreg keyword
    • S8132123, PR1061: MultiResolutionCachedImage unnecessarily creates base image to get its size
    • S8133539, PR1061: [TEST_BUG] Split java/awt/image/MultiResolutionImageTest.java in two to allow restricted access
    • S8137571, PR1061: Linux HiDPI Graphics support
    • S8142406, PR1061: [TEST] MultiResolution image: need test to cover the case when @2x image is corrupted
    • S8145188, PR2945: No LocalVariableTable generated for the entire JDK
    • S8150258, PR1061: [TEST] HiDPI: create a test for multiresolution menu items icons
    • S8150724, PR1061: [TEST] HiDPI: create a test for multiresolution icons
    • S8150844, PR1061: [hidpi] [macosx] -Dsun.java2d.uiScale should be taken into account for OS X
    • S8151841, PR2882: Build needs additional flags to compile with GCC 6 [plus parts of 8149647 & 8032045]
    • S8155613, PR1061: [PIT] crash in AWT_Desktop/Automated/Exceptions/BasicTest
    • S8156020, PR1061: 8145547 breaks AIX and and uses RTLD_NOLOAD incorrectly
    • S8156128, PR1061: Tests for [AWT/Swing] Conditional support for GTK 3 on Linux
    • S8158260, PR2991, RH1341258: PPC64: unaligned Unsafe.getInt can lead to the generation of illegal instructions
    • S8159244, PR3074: Partially initialized string object created by C2′s string concat optimization may escape
    • S8159690, PR3077: [TESTBUG] Mark headful tests with @key headful.
    • S8160294, PR2882, PR3095: Some client libraries cannot be built with GCC 6
  • Bug fixes
    • PR1958: GTKLookAndFeel does not honor gtk-alternative-button-order
    • PR2822: Feed LIBS & CFLAGS into configure rather than make to avoid re-discovery by OpenJDK configure
    • PR2932: Support ccache in a non-automagic manner
    • PR2933: Support ccache 3.2 and later
    • PR2964: Set system defaults based on OS
    • PR2974, RH1337583: PKCS#10 certificate requests now use CRLF line endings rather than system line endings
    • PR3078: Remove duplicated line dating back to 6788347 and 6894807
    • PR3083, RH1346460: Regression in SSL debug output without an ECC provider
    • PR3089: Remove old memory limits patch
    • PR3090, RH1204159: SystemTap is heavily confused by multiple JDKs
    • PR3095: Fix warnings in URLClassPath.c
    • PR3096: Remove dead –disable-optimizations option
    • PR3105: Use version from hotspot.map to create tarball filename
    • PR3106: Handle both correctly-spelt property “enableCustomValueHandler” introduced by S8079718 and typo version
    • PR3108: Shenandoah patches not included in release tarball
    • PR3110: Update hotspot.map documentation in INSTALL
  • AArch64 port
    • S8145320, PR3078: Create unsafe_arraycopy and generic_arraycopy for AArch64
    • S8148328, PR3078: aarch64: redundant lsr instructions in stub code.
    • S8148783, PR3078: aarch64: SEGV running SpecJBB2013
    • S8148948, PR3078: aarch64: generate_copy_longs calls align() incorrectly
    • S8149080, PR3078: AArch64: Recognise disjoint array copy in stub code
    • S8149365, PR3078: aarch64: memory copy does not prefetch on backwards copy
    • S8149907, PR3078: aarch64: use load/store pair instructions in call_stub
    • S8150038, PR3078: aarch64: make use of CBZ and CBNZ when comparing narrow pointer with zero
    • S8150045, PR3078: arraycopy causes segfaults in SATB during garbage collection
    • S8150082, PR3078: aarch64: optimise small array copy
    • S8150229, PR3078: aarch64: pipeline class for several instructions is not set correctly
    • S8150313, PR3078: aarch64: optimise array copy using SIMD instructions
    • S8150394, PR3078: aarch64: add support for 8.1 LSE CAS instructions
    • S8151340, PR3078: aarch64: prefetch the destination word for write prior to ldxr/stxr loops.
    • S8151502, PR3078: optimize pd_disjoint_words and pd_conjoint_words
    • S8151775, PR3078: aarch64: add support for 8.1 LSE atomic operations
    • S8152537, PR3078: aarch64: Make use of CBZ and CBNZ when comparing unsigned values with zero.
    • S8152840, PR3078: aarch64: improve _unsafe_arraycopy stub routine
    • S8153713, PR3078: aarch64: improve short array clearing using store pair
    • S8153797, PR3078: aarch64: Add Arrays.fill stub code
    • S8154537, PR3078: AArch64: some integer rotate instructions are never emitted
    • S8154739, PR3078: AArch64: TemplateTable::fast_xaccess loads in wrong mode
    • S8155015, PR3078: Aarch64: bad assert in spill generation code
    • S8155100, PR3078: AArch64: Relax alignment requirement for byte_map_base
    • S8155612, PR3078: Aarch64: vector nodes need to support misaligned offset
    • S8155617, PR3078: aarch64: ClearArray does not use DC ZVA
    • S8155653, PR3078: TestVectorUnalignedOffset.java not pushed with 8155612
    • S8156731, PR3078: aarch64: java/util/Arrays/Correct.java fails due to _generic_arraycopy stub routine
    • S8157841, PR3078: aarch64: prefetch ignores cache line size
    • S8157906, PR3078: aarch64: some more integer rotate instructions are never emitted
    • S8158913, PR3078: aarch64: SEGV running Spark terasort
    • S8159052, PR3078: aarch64: optimise unaligned copies in pd_disjoint_words and pd_conjoint_words
    • S8159063, PR3078: aarch64: optimise unaligned array copy long
    • PR3078: Cleanup remaining differences from aarch64/jdk8u tree

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.

  • PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
  • Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222

GnuPG >= 2.1 is required to be able to handle this key.

SHA256 checksums:

  • 694477835af753d59b5f03f4939a6015d7d4a00e5e5bb3d5c9e3e5186d3163e1 icedtea-3.1.0.tar.gz
  • ab2a540812ed7be2b5c6dfe26e4f5c1789aef921468fef6b0ef1322767de3741 icedtea-3.1.0.tar.gz.sig
  • 75616641ad6d8437124c32fed3fadddac67b14bba26757e15f6c2f69149233b4 icedtea-3.1.0.tar.xz
  • 4abef25de9618bc8a9f53b25f676fff80127c766f248b95e9c91861028a9607b icedtea-3.1.0.tar.xz.sig

The checksums can be downloaded from:

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

or:

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

then:

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

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

Happy hacking!

First, the underlying DataBasinKit framework got an important update.
[DBSoap update] now supports setting fields to null. That was quite a major detail missing: you could reset to blank even string fields.
This required me to fiddle a bit to generate the fieldsToNull list. Every field passed with an empty string value is considered to null.

<update xmlns="...">
<sobject xsi:type="sf:Account">
<id>....</id>
<fieldsToNull>AccountNumber</fieldsToNull>
<fieldsToNull>OtherCity</fieldsToNull>
<Name>New Name</Name>
</sobject>
</update>


The Object Inspector, the handy tool which allows you to inspect all field values of a record and knowing immediately their developer name given the Object Salesforce Id, how got update powers!



As the Screenshot (here on MacOS) shows, changed values show in a different color (non-updatable fields show in italics and their Cell is not editable). The total number of fields to be changed is summed up in the status field. Only fields marked as changed are updated when the Update button is pressed, other are left as-is and not overwritten for safety.

Further work has been done in the Inspector and full search filtering is now available!
Just entering a a sting will filter out the relevant rows. Both the Field Name or Developer Name are matched, as well as the content! It is thus super-easy to look for all fields (also fields not at layout) which have a certain Value. All fields false? easy as in the screenshot:



RoboVM 0.0.1 got released this week by Trillian AB.

RoboVM's main focus is to compile Java to native for deployment on mobile devices such as iOS and Android. RoboVM uses a Java to Objective-C bridge built using LLVM. Good news is that the same process work for converting Java applications to native applications on GNU/Linux systems as well!

Mario Zechner the author of libgdx posted this nice picture from inside DDD/GDB of his first HelloWorld compiled to native X86 code running on a GNU/Linux machine.
GNU/Linux machine code generated by RoboVM seen from inside DDD/GDB

http://www.robovm.org/

JogAmp is the home of high performance Java™ libraries for 3D Graphics, Multimedia and Processing.
JOGL, JOCL and JOAL provide cross platform Java™ language bindings to the OpenGL®, OpenCL™, OpenAL and OpenMAX APIs.
Running on Android, Linux, Window, OSX, and Solaris across devices using Java.

Release announcement for JogAmp 2.0.2-rc12

"You're encouraged to stop using the now-ancient 2.0-rc11!"

This 2.0.2-rc12 release include the largest security review in the 10-year history of JOGL

  • Security Fixes

    • Dynamic Linker Usage / Impl.
    • ProcAddressTable field visibility
    • Perform SecurityManager checks where required
    • Validation of property access
    • JAR Manifest tags:
      • Codebase
      • Permissions
      • Sealed
    • Use latest Java7 toolchain
      • Generating Java 1.6 bytecode
      • HTML API doc

https://jogamp.org/wiki/index.php/SW_Tracking_Report_Objectives_for_the_release_2.0.2_of_JOGL
Security fixes are marked in red on the above bug tracking page.
JogAmp send out thanks to the FuzzMyApp security researchers for healthy communication that triggered the security review work.

If you find an issue with the release, please report it to our bug database under the appropriate component. Development discussion takes place inside the JogAmp forum & mailing-list and the #jogamp IRC channel on irc.freenode.net.


Meet us @

JogAmp @ SIGGRAPH 2013

If you’ve been following Infinity and would like to, you know, download some code and try it out… well, now you can!

A jury found that using the declaring lines of code and their structure, sequence, and organization from Java constitutes fair use. Which is a great outcome of a terrible lawsuit Oracle filed some years ago trying to destroy free java. They started by trying to be a patent troll, but when that failed they tried to pervert copyright law to make it illegal to reimplement APIs. Oracle’s behavior is unethical and greedy. Luckily this jury stopped them for now.

screenshot

After more than a year of work, finally a new release of DataBasin and its associated framework. This version features a Framework that can be used in threads and the application itself is capable of having concurrent connection classes to SalesForce.com.

On Windows

On OpenBSD


Countless bug fixes (thanks to the bug reports of my colleagues Diego, Moustapha, Matteo + Matteo).

Major new features are:
  • threadable DataBasinKit framework
  • concurrent, interruptible operations (e.g. select vs. update)
  • handle multiple errors as a result of update
  • filter new lines when writing CSVs
  • countless bugfixes, especially in select-identify corner cases

DataBasinKit allows you native connection to SalesForce.com, allowing your application to integrate SOQL queries (SELECT, UPDATE similar operations), be it on Mac (Cocoa) or NetBSD, FreeBSD, OpenBSD, Linux or Solaris as well as Windows (MinGW).
DataBasin itself allows you to perform standard operations in a quick and agile interface: Extract accounts on Linux without the need of Java. Use the unique select-identify feature.

I am proud that Free Software can connect from a Free Software Operating System to a proprietary system and bridge the two worlds, enabling to do administrative work without being constrained to Java on Windows (read: DataLoader). Thanks to the many developers who continue supporting me in the development and keep these fine Operating Systems and tools alive.

We really need more Free Software for desktop users.

Please consider backing the Krita 2016 Fundraiser to make text and vector art awesome!

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

This release updates our OpenJDK 6 support in the 1.13.x series with the April 2016 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 1.13.11 (2016-05-04)

  • Security fixes
  • Import of OpenJDK6 b38
    • S4459600: java -jar fails to run Main-Class if classname followed by whitespace.
    • S6378099: RFE: Use libfontconfig to create/synthesise a fontconfig.properties
    • S6452854: Provide a flag to print the java configuration
    • S6742159: (launcher) improve the java launching mechanism
    • S6752622: java.awt.Font.getPeer throws “java.lang.InternalError: Not implemented” on Linux
    • S6758881: (launcher) needs to throw NoClassDefFoundError instead of JavaRuntimeException
    • S6856415: Enabling java security manager will make program thrown wrong exception ( main method not found )
    • S6892493: potential memory leaks in 2D font code indentified by parfait.
    • S6925851: Localize JRE into pt_BR (corba)
    • S6968053: (launcher) hide exceptions under certain launcher failures
    • S6977738: Deadlock between java.lang.ClassLoader and java.util.Properties
    • S6981001: (launcher) EnsureJREInstallation is not being called in order
    • S7017734: jdk7 message drop 1 translation integration
    • S7026184: (launcher) Regression: class with unicode name can’t be launched by java.
    • S7104161: test/sun/tools/jinfo/Basic.sh fails on Ubuntu
    • S7125442: jar application located in two bytes character named folder cannot be run with JRE 7 u1/u2
    • S7127906: (launcher) convert the launcher regression tests to java
    • S7141141: Add 3 new test scenarios for testing Main-Class attribute in jar manifest file
    • S7158988: jvm crashes while debugging on x86_32 and x86_64
    • S7189944: (launcher) test/tools/launcher/Arrrrghs.java needs a couple of minor fixes
    • S7193318: C2: remove number of inputs requirement from Node’s new operator
    • S8002116: This JdbReadTwiceTest.sh gets an exit 1
    • S8004007: test/sun/tools/jinfo/Basic.sh fails on when runSA is set to true
    • S8023990: Regression: postscript size increase from 6u18
    • S8027705: com/sun/jdi/JdbMethodExitTest.sh fails when a background thread is generating events.
    • S8028537: PPC64: Updated the JDK regression tests to run on AIX
    • S8036132: Tab characters in test/com/sun/jdi files
    • S8038963: com/sun/jdi tests fail because cygwin’s ps sometimes misses processes
    • S8044419: TEST_BUG: com/sun/jdi/JdbReadTwiceTest.sh fails when run under root
    • S8059661: Test SoftReference and OOM behavior
    • S8067364: Printing to Postscript doesn’t support dieresis
    • S8072753: Nondeterministic wrong answer on arithmetic
    • S8073735: [TEST_BUG] compiler/loopopts/CountedLoopProblem.java got OOME
    • S8074146: [TEST_BUG] jdb has succeded to read an unreadable file
    • S8075584: test for 8067364 depends on hardwired text advance
    • S8134297: NPE in GSSNameElement nameType check
    • S8134650: Xsl transformation gives different results in 8u66
    • S8141229: [Parfait] Null pointer dereference in cmsstrcasecmp of cmserr.c
    • S8143002: [Parfait] JNI exception pending in fontpath.c:1300
    • S8146477: [TEST_BUG] ClientJSSEServerJSSE.java failing again
    • S8146967: [TEST_BUG] javax/security/auth/SubjectDomainCombiner/Optimize.java should use 4-args ProtectionDomain constructor
    • S8147567: InterpreterRuntime::post_field_access not updated for boolean in JDK-8132051
    • S8148446: (tz) Support tzdata2016a
    • S8148475: Missing SA Bytecode updates.
    • S8149170: Better byte behavior for native arguments
    • S8149367: PolicyQualifierInfo/index_Ctor JCk test fails with IOE: Invalid encoding for PolicyQualifierInfo
    • S8150012: Better byte behavior for reflection
    • S8150790: 8u75 L10n resource file translation update
    • S8154210: Zero: Better byte behaviour
    • S8155261: Zero broken since HS23 update
    • S8155699: Resolve issues created by backports in OpenJDK 6 b39
    • S8155746: Sync Windows export list in make/java/jli/Makefile with make/java/jli/mapfile-vers
  • Backports
  • Bug fixes
    • PR2887: Location of ‘stap’ executable is hard-coded
    • PR2890: OpenJDK should check for system cacerts database (e.g. /etc/pki/java/cacerts)
    • PR2952: test/tapset/jstaptest.pl requires Perl
    • PR2953: make dist fails after PR2887 made jstaptest.pl auto-generated

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:

  • PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
  • Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222

GnuPG >= 2.1 is required to be able to handle this key.

SHA256 checksums:

  • f69ab75ccf594931ae5bf5ebc16bce233878d9793516b4abc72f08d7188f5861 icedtea6-1.13.11.tar.gz
  • f12d470c3aefc599388e5f897367c6ca0ef0902f95ba187be12b3adc4b689f1f icedtea6-1.13.11.tar.gz.sig
  • 526ecdf6fec35c10160df305e87cb477f5fe1ea32f02f6c9b1c865a2d28833bf icedtea6-1.13.11.tar.xz
  • 1c01648a7139c8c3b7cd4626652a0509664b797469c234a020a864dead51d2e6 icedtea6-1.13.11.tar.xz.sig

The checksums can be downloaded from:

A 1.13.11 ebuild for Gentoo is available.

The following people helped with these releases:

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

To get started:

$ tar xzf icedtea6-1.13.11.tar.gz

or:

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

then:

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

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

Happy hacking!

Project Jigsaw is an enormous effort, encompassing six JEPs implemented by dozens of engineers over many years. So far we’ve defined a modular structure for the JDK (JEP 200), reorganized the source code according to that structure (JEP 201), and restructured the JDK and JRE run-time images to support modules (JEP 220). The last major component, the module system itself (JSR 376 and JEP 261), was integrated into JDK 9 earlier this week and is now available for testing in early-access build 111.

Breaking changes Like the previous major change, the introduction of modular run-time images, the introduction of the module system might impact you even if you don’t make direct use of it. That’s because the module system is now fully operative at both compile time and run time, at least for the modules comprising the JDK itself. Most of the JDK’s internal APIs are, as a consequence, fully encapsulated and hence, by default, inaccessible to code outside of the JDK.

An existing application that uses only standard Java SE APIs and runs on JDK 8 should just work, as they say, on JDK 9. If, however, your application uses a JDK-internal API, or uses a library or framework that does so, then it’s likely to fail. In many cases you can work around this via the -XaddExports option of the javac and java commands. If, e.g., your application uses the internal sun.security.x509.X500Name class then you can enable access to it via the option

-XaddExports:java.base/sun.security.x509=ALL-UNNAMED

This causes all members of the sun.security.x509 package in the java.base module to be exported to the special unnamed module in which classes from the class path are defined.

A few broadly-used internal APIs that cannot reasonably be implemented outside of the JDK, such as sun.misc.Unsafe, are still accessible for now. As outlined in JEP 260, however, these will be removed in a future release after suitable standard replacements are available.

The encapsulation of JDK-internal APIs is the change you’re most likely to notice when running an existing application. Other relevant but, for the most part, less-noticeable changes are described in the risks-and-assumptions section of JEP 261.

If you have trouble running an existing application on JDK 9 build 111 or later, and you think that’s due to the introduction of the module system but not caused by one of the changes listed in JEPs 260 or 261, then please let us know on the jigsaw-dev mailing list (you’ll need to subscribe first, if you haven’t already), or else submit a bug report via bugs.java.com.

New features If you’d like to start learning about the module system itself, the video of my Devoxx BE 2015 keynote gives a high-level overview and The State of the Module System summarizes the design of the module system proposed for JSR 376. Further details are available in the six Jigsaw JEPs, listed on the main project page, and in videos of other sessions given at JavaOne 2015 and Devoxx BE 2015.

The module-system design will continue to evolve in the JSR for a while yet, based on feedback and experience. The implementation will evolve in parallel in the Project Jigsaw “Jake” forest, and we’ll continue to publish bleeding-edge early-access builds based on that code, separately from the more-stable JDK 9 builds.

I finished getting Excorporate and all its dependencies into GNU ELPA. Excorporate lets Emacs retrieve calendar items from an Exchange server.

Excorporate in GNU ELPA

I had to rewrite the default UI to use Org Mode, because Calfw isn’t entirely copyright-assigned to the FSF yet. The Calfw UI is still there for reference, but as a text file so that GNU ELPA’s build and publishing steps ignore it. Both UI handlers use the same updated APIs from the main excorporate.el library.

Excorporate Org handler

I made sure Excorporate and all its dependencies use only features available since GNU Emacs 24.1. This is pretty good coverage; Emacs 24.1 introduced the packaging system, so if an Emacs version supports packages, it supports Excorporate.

Other than DNS lookups, Excorporate is completely asynchronous, so it won’t block the Emacs main loop. And it is pure Emacs Lisp so it runs on any operating system that Emacs does.

In addition to Org Mode support, release 0.7.0 collects all the suggestions users have made on this blog and adds Exchange 2007 support.

To install: M-x package-install RET excorporate

To get the source code:

git clone git://git.savannah.gnu.org/emacs/elpa.git

To report bugs: M-x report-emacs-bug

I wanted to attent FOSDEM two weeks ago, but couldn’t because I was sick, in bed with fever. I should have done a presentation about Shenandoah. Unfortunately, my backup Andrew Dinn also became sick that weekend, so that presentation simply didn’t happen. I want to summarize some interesting news that I wanted to show there. About Shenandoah’s performance.

When I talked about Shenandoah at FOSDEM 2015, I didn’t really announce any performance numbers, because we would have been embarrassed by them:-) We spent the better part of last year optimizing the heck out of it, especially the barriers in the C2 compiler, and here we are, with some great results.

SPECjvm2015

Ok. This doesn’t really exist. The last SPECjvm release was SPECjvm2008. Unfortunately, SPEC doesn’t seem to care about SPECjvm anymore, which means the last Java version that runs it without any modifications is Java7. We did some small fixes, that allows it to run with Java9 too. This invalidates compliance of the results. But they are still tremendously useful for comparison. So here it comes:

SPECjvm2015

This was run on a 32 core box with 160GB of RAM, giving the JVM 140GB of heap. Exact same JVM and settings with G1 and Shenandoah. No special tuning parameters.

In terms of numbers, we get:

Throughput:   Shenandoah: 374 ops/m  vs. G1: 393 ops/m (95%, min 80%, max 140%)
Pauses:          Shenandoah: avg: 41 ms, max 202 ms                     G1:               avg: 240 ms, max 1126 ms

This means, throughput of Java apps, running with Shenandoah is on average 95% that of G1, depending on the actual application, it’ll range from around 80% to around 140%. However, pause times on such large heaps are significantly better with Shenandoah!

SPECjbb2015

SPECjbb2015 measures throughput of a simulated shop system under response time constraints, or service level agreements (SLAs). It measures ‘max-jops’ which is maximum throughput of the system without SLA, and critical-jops, which is throughput of the system under a restrictive SLA. Here are the numbers, G1 vs. Shenandoah, same machine and JVM settings as above:

SPECjbb2015This basically confirms the results that we got from SPECjvm2008: general throughput in the area of 95% behind G1, but much better pause times, reflected in a much higher score of critical-jops.

Other exciting news is that Shenandoah is now stable enough that we want to encourage everybody who’s interested to try it out. The nice folks at Adopt-OpenJDK have set up a nightly build from where you can grab binaries (Shenandoah JDK8 or Shenandoah JDK9). Enjoy! (And please report back if you encounter any problems!)



EclipseCon NA 2016

It was a great pleasure to have a chance to serve on this year’s EclipseCon Program Committee. As Java SE 8 adoption took place at “record-setting pace” during the past year, I was glad to see the EclipseCon team set their sights ahead, towards JDK 9, with its own track at EclipseCon. If you’d just like to take a peek at the changes being considered, developed and integrated into the JDK 9 Project, you can check out its web site in the OpenJDK community, and try out the Early Access builds.

If you’d like to hear what JDK 9 means for Eclipse, though, then you should come to EclipseCon in March and hear about it first hand from Jay Arthanareeswaran from IBM and Manoj Palat, who will talk about Java 9 support in Eclipse. In their session, they will look at what kind of support JDT provides for developers who would like to use JDK 9 in their projects, discussing planned Eclipse features as well as what modules could mean to different projects and how to best leverage the upcoming module system.

Within the OpenJDK community, Project Jigsaw is where development of the reference implementation of JSR 376 – Java Platform Module System takes place, along with the modularization of the JDK itself and the development of a new run-time image format. That’s a lot of new stuff to digest – fortunately, we’ll have Thomas Schindl at EclipseCon to give us a personal view and overview of what he calls "most likely the biggest change in Java’s history" in the “You, Me and Jigsaw” session.

At this point, you may be wondering if JDK 9 is all about modules. Modularity plays a huge role, but there is a lot more to it – more than 70 JDK Enhancement Proposals have been targeted for the JDK 9 release so far. To walk us through some of Java 9’s other puzzle pieces, we’ll have Erik Costlow from Oracle.

Finally, closing this track on Thursday, Erik will discuss “Preparing your code for JDK 9”. There are some steps you can take already to make your code ready to benefit from the new features planned for JDK 9, such as analyzing your project’s library dependencies for unintentional reliance on JDK-internal APIs.

I hope that you will enjoy this EclipseCon track, and that you will be inspired to start experimenting with JDK 9 and Eclipse.
At JavaOne, I'll be at the


OpenJDK Adoption Group BOF [BOF3377]

Monday, Oct 26, 8:00 p.m. | Hilton—Continental Ballroom 4


See you there!
Today I finally moved out of my lovely Ubuntu 10.04 LTS I was so proud in 2012, sad to read. That there are no longer any updates for it, only half of the problem. Many projects I am interested in started to fail during compilation because the toolchain is getting old. I was not updating because I did not like Unity, say whatever you want about it. I could learn it, of course, I have learned lots of way more sophisticated things (what about building GNU Classpath?). But I do not like the attitude, do not like decisions being made the way they are. Design must follow the user demands. Not in reverse. I gave a try to Gnome 3 as well with Fedora 22, played for some time but was not very impressed either and decided to drop after discovering that while it is possible to install the Gnome 2 - like Mate desktop, it is very difficult to actually switch into it.

My next distribution will be Ubuntu Mate. Value your freedom otherwise you will lose it!

Unexpectedly there were significant problems during updates . While in 2012 Linux installed no problem for me, now both Ubuntu Mate and Fedora 22 have booted in UEFI mode, raising lots of esoteric complains. It took half of the day for me to find where to switch of these UEFI beaties off in my wondercard, and another half to discover that the wondercard does not remember this setting, spontaneously reverting to "UEFI on". I cannot switch into UEFI, I have two other Linux distros on the same machine and do not want to loose. But now seems done.

This month I've released Orson PDF version 1.7, a compact and fast API for creating PDF content in Java through the standard Graphics2D API. This release features:

  • support for transparent images;
  • an implementation of the create() method to better support use against existing Java2D code;
  • addition of the GNU General Public License version 3 as the default license (a commercial license remains available for those that prefer it);
  • various bug fixes;
While Orson PDF has been created to provide PDF export for any Java2D-based code, my own use for it is within JFreeChart and Orson Charts. To provide an example, here is a chart that was exported with Orson PDF being viewed within Acrobat Reader: chartpdf.png

With the new GPLv3 license option, I've now also made the OrsonPDF repo at GitHub public, which will make it easier for other developers to work directly with the source code. You can also use GitHub to report any bugs or other issues.

The original version of this blog entry is published at http://www.object-refinery.com/blog/blog-20151008.html.

I’ve always upgraded my Fedora laptop incrementally using the recommended tools (yum, preupgrade, fedup). For this reason, my initial decision to install i686 Fedora (back when 32-bit compatibility was important) has carried through, and I’ve always used i686 Fedora, even though the CPU supports x86_64.

Recently I wanted to try out Mezzano in a virtual machine, but it is x86_64-only. Obviously, virtualization tools don’t support running an x86_64 guest on an i686 host, so I shelved the experiment.

Then I found a use for Docker (testing Emacs HTTP authentication schemes), and wanted to try it out. But I ran into this surprising limitation: Docker is 64-bit only.

At this point I had two motivators to move to x86_64, but no desire to wipe my system. I discovered an interesting new term, “crossgrading”, when I found these instructions: Cross-grading from i686 to x86_64: it is possible (but unsupported). They were written for Fedora 14, but I decided to try them out on Fedora 22 (after backing up all my data).

Long story short, careful application of dnf download and rpm --force (and an rpm database rebuild) resulted in a still-working x86_64 Fedora 22 system, with no need to wipe the drive. I’m glad Roberto Ragusa took the time to write up those instructions, and I wanted to document that they roughly still apply, eight Fedora versions later.

The first release candidate is finally available. It can be downloaded here or from NuGet.

What's New (relative to IKVM.NET 8.0):

  • Integrated OpenJDK 8u45.
  • Many fixes to late binding support.
  • Added ikvmc support for deterministic output files.
  • Various sun.misc.Unsafe improvements.
  • Many minor bug fixes and performance tweaks.

Changes since previous development snapshot:

  • Assemblies are strong named.
  • Fix for bug #303. ikvmc internal compiler error when trying to get interfaces from type from missing assembly reference.
  • Implemented NIO atomic file move on Windows.

Binaries available here: ikvmbin-8.1.5717.0.zip

Sources: ikvmsrc-8.1.5717.0.zip, openjdk-8u45-b14-stripped.zip

There is a nice profile of me on the Java Magazine of this bimestre, and I am very flattened for this so let me share it right away with you.

There is one question I was expecting though but didn’t come: “When did you start working on Java?”.

So, in order to give some more context, let me play with it and answer my own question here (and without space limits!). I think this is important, because it is about how I started to contribute to OpenJDK, it shows that you can do the same… if you are patient.

JM: When did you start working on Java?

Torre: I started to work in Java around its 1.3 release, and I used it ever since. I did start working on Java quite later though, around the Java 1.5/1.6 era probably. I was working to create an MSN messenger clone in Java on my Linux box, since all my friends where using it (MSN I mean, not Linux unfortunately), including the dreaded emoticons, and no Linux client supported those at the time.

I had all the protocol stuff working, I could handshake and share messages (although I still had to figure out the emoticons part!), but I had a terrible problem. I needed to save user credentials. Well, Java has a fantastic Preferences API, easy enough, right? Except that what I was using wasn’t the proprietary JDK, it was the Free Software version of it: GNU Classpath.

Classpath at the time didn’t have Preferences support, so I was stuck. I think somebody was writing a filesystem based preferences, or perhaps it was in Classpath but not GCJ, which is what everybody was using as a VM with the Classpath library, anyway when I started to look at the problem, I realised it would have been nicer to offer a GConf based Preferences store, and integrate the whole thing into the Gnome desktop (at the time, Gnome was a great desktop, nothing like today’s awfulness).

I was hooked. In fact, I even never finished my MSN messenger! After GConf, all sort of stuff came in, Decimal Formatter, GStreamer Sound backend, various fixes here and here, and this is when I learned a lot of how Swing works internally by following Sven de Marothy, Roman Kennke and David Gilbert work.

When Sun was about to release OpenJDK, I was in that very first group and witnessed the whole thing, a lot of behind the scenes of the creation of this extremely important code contribution. OpenJDK license is “GPL + Classpath exception” for a reason. I remember all the heroes that made Java Free Software.

I guess I was lucky, and the timing was perfect.

However right at the beginning contributing actual code to OpenJDK wasn’t at all easy like in Classpath. There was (is!) lot of process, things took a lot of time for anything but the most trivial changes etc…

But eventually I insisted and me and Roman where the first external guys to have code landing in the JDK, Roman was, I believe, the first independent person to have commit rights (I think that the people that are still today in my team at Red Hat and then also SAP had some changes already in, but at the time we two were the only guys completely external).

It wasn’t easy, I had to challenge ourselves and push a lot, and not give up. I had to challenge Sun, and even more challenge Oracle when it took the lead. But I did it. This is what I mean that everybody can do it, you can develop the skills and then you need to build the trust and then not let it go. I’m not sure what is more complex here, but if you persist it eventually come. And then all of a sudden billions of people will use your code and you are a Java Champion.

So this is how it started.


Final 8.1 development snapshot. Release candidate 0 will be next (after .NET 4.6 RTM).

Changes:

  • Updated HOWTO reference to OpenJDK 8u45.
  • Extract Windows version from kernel32.dll to avoid version lie. Idea stolen from OpenJDK.
  • Moved unused field removal optimization to a later stage in the compilation.
  • Made field removal optimization check more strict to only remove final fields and not remove fields that have annotations.
  • Added support for automatically passing in fields to "native" methods.
  • Various minor clean ups.
  • Added FieldWrapper.IsSerialVersionUID property to properly (and consistently) detect serialVersionUID fields.
  • Improved side effect free static initializer detection.
  • Improved -removeassertions ikvmc optimization to remove more code (esp. allow otherwise empty static initializers to be optimized away).

Binaries available here: ikvmbin-8.1.5666.zip

Just a couple of days ago I found out that some of my favourite musicians decided to join together to release an album, and allowed to preorder it on a crowdfunding website, Music Raiser.

The name of the band is “O.R.k.” and the founders are none but Lef, Colin Edwin, Pat Mastelotto and Carmelo Pipitone.

You probably have heard their names, if not, Colin Edwin is the bassist from Porcupine Tree while Carmelo Pipitone is the gifted guitarist from Marta Sui Tubi, an extremely original Italian band, they probably did the most interesting things in Italian music in the last 15 years or so; Lef, aka Lorenzo Esposito Fornasari, has done so many things that is quite hard to pick just one, but in Metal community he is probably best know for Obake. Finally, Pat Mastelotto is the drummer of King Crimson, and this alone made me jump on my seat!

One of the pre-order bonus was the ability to participate to a Remix Contest, and although I only got the stems yesterday in the late morning I could not resist to at least give it a try, and it’s a great honour for me that they have put my attempt on their Youtube channel:

It’s a weird feeling editing this music, after all, who am I to cut and remix and change the drum part (King Crimson, please forgive me!), how I ever dare to touch the guitars and voice, or rearrange the bass!? :)

But indeed it was a really fun experience, and I hope to be able do this again in the future.

And who knows, maybe they even like how I messed up their art and they decide to put me on their album! Nevertheless, it has been already a great honour for me to be able to see this material in semi-raw form (and a very interesting one!), so this has been already my first prize.

I’m looking forward now to listen the rest of the album!


I'm happy to announce that JFreeSVG version 3.0 has been uploaded to SourceForge. JFreeSVG is a fast and lightweight API for creating SVG content in Java. This release features:

  • new handling for BasicStroke cap, join and miterlimit;
  • a new ZIP option when writing SVG to files;
  • a demo for exporting Swing UIs to SVG;
  • removal of the CanvasGraphics2D implementation (to focus on SVG only);
  • a fix for handling of PathIterator.SEG_CLOSE;
  • a fix for y-coordinate bug in drawImage();
  • a workaround for ClassCastException when exporting Swing UIs on MacOSX with Nimbus L&F.

To ensure that JFreeSVG provides a fully functional Graphics2D implementation, I tested it using the Swingset3 demo with modifications to redirect the screen output directly to JFreeSVG to produce SVG output. I've always liked the way that Swing uses the Java2D API to cleanly separate its rendering from having any direct knowledge of the actual output target. Here is an example:

SVG not supported in your browser!

This turned out to be an effective test, because it uncovered a bug in one of the drawImage() methods that has remained undetected in all previous JFreeSVG releases.

One last thing...the JFreeSVG repo at GitHub is now public, which will make it easier for other developers to tweak the code for experimentation or bug fixes (if you spot a bug though, please report it to me).

If you'd like to give feedback on this post, please comment via the JFreeSVG forum.

In firefox development, it’s normal to do most development tasks via the mach command. Build? Use mach. Update UUIDs? Use mach. Run tests? Use mach. Debug tests? Yes, mach mochitest --debugger gdb.

Now, normally I run gdb inside emacs, of course. But this is hard to do when I’m also using mach to set up the environment and invoke gdb.

This is really an Emacs bug. GUD, the Emacs interface to all kinds of debuggers, is written as its own mode, but there’s no really great reason for this. It would be way cooler to have an adaptive shell mode, where running the debugger in the shell would magically change the shell-ish buffer into a gud-ish buffer. And somebody — probably you! — should work on this.

But anyway this is hard and I am lazy. Well, sort of lazy and when I’m not lazy, also unfocused, since I came up with three other approaches to the basic problem. Trying stuff out and all. And these are even the principled ways, not crazy stuff like screenify.

Oh right, the basic problem.  The basic problem with running gdb from mach is that then you’re just stuck in the terminal. And unless you dig the TUI, which I don’t, terminal gdb is not that great to use.

One of the ideas, in fact the one this post is about, since this post isn’t about the one that I couldn’t get to work, or the one that is also pretty cool but that I’m not ready to talk about, was: hey, can’t I just attach gdb to the test firefox? Well, no, of course not, the test program runs too fast (sometimes) and racing to attach is no fun. What would be great is to be able to pre-attach — tell gdb to attach to the next instance of a given program.

This requires kernel support. Once upon a time there were some gdb and kernel patches (search for “global breakpoints”) to do this, but they were never merged. Though hmm! I can do some fun kernel stuff with SystemTap…

Specifically what I did was write a small SystemTap script to look for a specific exec, then deliver a SIGSTOP to the process. Then the script prints the PID of the process. On the gdb side, there’s a new command written in Python that invokes the SystemTap script, reads the PID, and invokes attach. It’s a bit hacky and a bit weird to use (the SIGSTOP appears in gdb to have been delivered multiple times or something like that). But it works!

It would be better to have this functionality directly in the kernel. Somebody — probably you! — should write this. But meanwhile my hack is available, along with a few other gdb scxripts, in my gdb helpers github repository.

Over the last twelve months or so, one of my projects has been fixing and reviewing fixes of javac lint warnings in the JDK 9 code base (varargs, fallthrough, serial, finally, overrides, deprecation, raw and unchecked) and once a warning category is cleared, making new instances of that category a fatal build error. Ultimately, all the warnings in the jdk repository were resolved and -Xlint:all -Werror is now used in the build.

Being involved in fixing several thousand warnings, I'd like to share some tips for developers who want to undertake an analogous task of cleaning up the technical debt of javac lint warnings in their own code base. First, I recommend tackling the warnings in a way that aligns well with the build system of the project, with a consideration of getting some code protected by the compiler from some warning categories as soon as possible. While the build of the JDK has been re-engineered over the course of the warnings cleanup, to a first approximation the build has been organized around Hg repositories. (At present, in JDK 9 the build is actually arranged around modules. A few years ago, the build was organized around Java packages rather than repositories.) A warnings cleanup isn't really done until introducing new instances of the warning cause a build failure; new warnings are too easy to ignore otherwise. Therefore, for JDK 9, the effort was organized around clearing the whole jdk repository of a warning category and then enabling that warning category in the build as opposed to, say, completely clearing a particular package of all warnings and then moving to the next package.

There are two basic approaches to resolving a warning: suppressing it using the @SuppressWarnings mechanism or actually fixing the code triggering the warning. The first approach is certainly more expedient. While it doesn't directly improve the code base, it can offer an indirect benefit of creating a situation where new warnings can be kept out of the code base by allowing a warning to be turned on in the build sooner. The different warning categories span a range of severity levels and while some warnings are fairly innocuous, others are suspicious enough that I'd recommend always fixing them if a fix is feasible. When resolving warnings in the JDK, generally the non-deprecation warnings categories were fixed while the deprecation warnings were suppressed with a follow-up bug filed. The non-deprecation warnings mostly require Java language expertise to resolve and little area expertise; deprecation warnings are the reverse, often quite deep area expertise is needed to develop and evaluate a true fix.

Tips on addressing specific categories of lint warnings:

[cast]: Warn about use of unnecessary casts.
Since these warnings are generated entirely from the the contents of method bodies, there is no impact to potential callers of the code. Also, the casts analyzed as redundant by javac are easy and safe to remove; fixing cast warnings is essentially a zero-risk change.
[fallthrough]: Warn about falling through from one case of a switch statement to the next.
When such a falling through is not intentional, it can be a very serious bug. All fallthrough switch cases should be examined for correctness. An idiomatic and intentional fallthrough should have two parts: first, the cases in question should be documented in comments explaining that the fallthrough is expected and second, an @SuppressWarnings({"fallthrough"}) annotation should be added to the method containing the switch statement.

See also the discussion of switch statements in Java Puzzlers, Puzzler 23: No Pain, No Gain.

[static]: Warn about accessing a static member using an instance.
This is an unnecessary and misleading coding idiom that should be unconditionally removed. The fix is to simply refer to the static member using the name of the type rather than an instance of the type.

This coding anti-pattern is discussed in Java Puzzlers, Puzzle 48: All I Get Is Static.

[dep-ann]: Warn about items marked as deprecated in JavaDoc but not using the @Deprecated annotation
Since Java SE 5.0, the way to mark an element as deprecated is to modify it with a @Deprecated annotation. While a @deprecated javadoc tag should be used to describe all @Deprecated elements, the javadoc tag is informative only and does not mean the element is treated as deprecated by the compiler.

A element should have an @deprecated javadoc tag in its javadoc if and only if the element is @Deprecated.

Therefore, the fix should be to either remove the @deprecated javadoc tag if the element should not be deprecated or add the @Deprecated annotation if it should be deprecated.

[serial]: Warn about Serializable classes that do not provide a serialVersionUID.
Serialization is a subtle and complex protocol whose compatibility impact on evolving a type should not be underestimated. To check for compatibility between the reader of serial stream data and the writer of the data, besides matching the names of the reader and writer, identification codes of the reader and the writer are also compared and the serial operation fails if the codes don't match. When present, a serialVersionUID field of a class stores the identification code, called a Stream Unique Identifier (SUID) in serialization parlance. When a serialVersionUID field is not present, a particular hashing algorithm is used to compute the SUID instead. The hash algorithm is perturbed by many innocuous changes to a class and can therefore improperly indicate a serial incompatibility when no such incompatibility really exists. To avoid this hazard, a serialVersionUID field should be present on all Serializable classes following the usual cross-version serialization contracts, including Serializable abstract superclasses.

If a Serializable class without a serialVersionUID has already been shipped in a release, running the serialver tool on the type in the shipped release will return the serialVersionUID declaration needed to maintain serial compatibility.

For further discussion, see Effective Java, 2nd Edition, Item 74: Implement Serializable judiciously.

[overrides]: Warn about issues regarding method overrides.
As explained in Effective Java, 2nd Edition, Item 9: Always Override hashCode when you override equals, for objects to behave properly when used in collections, they must have correct equals and hashCode implementations. The invariant checked by javac is more nuanced than the one discussed in Effective Java; javac checks that if a class overrides equals, hashCode has been overriden somewhere in the superclass class chain of the class. It is common for a set of related classes to be able to share a hashCode implementation, say a function of a private field in the root superclass in a set of related types. However, each class will still need to have its own equals method for the usual instanceof check on the argument to equals.
[deprecation]: Warn about use of deprecated items.
Well documented @Deprecated elements suggest a non-deprecated replacement. When using a replacement is not feasible, or no such replacement exists, @SuppressWarnings("deprecation") can be used to acknowledge the situation and remove the warning. A small language change made in JDK 9 makes suppressing deprecation warnings tractable.
[rawtypes]: Warn about use of raw types.
[unchecked]: Warn about unchecked operations.
Both rawtypes and unchecked warnings are linked to the same underlying cause: incomplete generification of APIs and their implementations. Generics shipped in 2004 as part of Java SE 5.0; Java code written and used today should be generics aware! Being generics-aware has two parts, using generics properly in the signature / declaration of a method, constructor, or class and using generics properly in method and constructor bodies. Many uses of generics are straightforward; if you have a list that only contains strings, it should probably be declared as a List<String>. However, some uses of generics can be subtle and are out of scope for this blog entry. However, extensive guides are available with detailed advice. IDEs also provide refactorings for generics; check their documentation for details.

I hope these tips help you make your own Java project warnings-free.

I recently had occasion to scan some papers using a sheet-fed Ricoh printer/scanner/fax/copier. It seems to think that about 6 MB is as big of an email attachment as it can send so it splits up the PDFs into base64-encoded attachments. If you find yourself in a similar situation:

  • save the raw base64 text (if you’re using GMail, “show original” is your friend) and trim the extraneous text.
  • concatenate the multiple pieces together: cat part1 part2 > all.base64.
  • decode the whole thing: cat all.base64 | base64 -d > myscan.pdf.

As part of milling Project Coin in JDK 9, the try-with-resources statement has been improved. If you already have a resource as a final or effectively final variable, you can use that variable in the try-with-resources statement without declaring a new variable in the try-with-resources statement.

For example, given resource declarations like

        // A final resource
        final Resource resource1 = new Resource("resource1");
        // An effectively final resource
        Resource resource2 = new Resource("resource2");

the old way to write the code to manager these resources would be something like:

        // Original try-with-resources statement from JDK 7 or 8
        try (Resource r1 = resource1;
             Resource r2 = resource2) {
            // Use of resource1 and resource 2 through r1 and r2.
        }

while the new way can be just

        // New and improved try-with-resources statement in JDK 9
        try (resource1;
             resource2) {
            // Use of resource1 and resource 2.
        }

An initial pass has been made over the java.base module in JDK 9 to update the JDK libraries to use this new language feature.

You can try out these changes in your own code using a JDK 9 snapshot build. Enjoy!

As I wrote previously, Project Jigsaw is coming into JDK 9 in several large steps. JEP 200 defines the modular structure of the JDK, JEP 201 reorganizes the JDK source code into modular form, and JEP 220 restructures the JDK and JRE run-time images to support modules. The actual module system will be defined in JSR 376, which is just getting under way, and implemented by a corresponding JEP, yet to be submitted.

We implemented the source-code reorganization (JEP 201) last August. This step, by design, had no impact on developers or end users.

Most of the changes for modular run-time images (JEP 220) were integrated late last week and are now available in JDK 9 early-access build 41. This step, in contrast to the source-code reorganization, will have significant impact on developers and end users. All of the details are in the JEP, but here are the highlights:

  • JRE and JDK images now have identical structures. Previously a JDK image embedded the JRE in a jre subdirectory; now a JDK image is simply a run-time image that happens to contain the full set of development tools and other items historically found in the JDK.

  • User-editable configuration files previously located in the lib directory are now in the new conf directory. The files that remain in the lib directory are private implementation details of the run-time system, and should never be opened or modified.

  • The endorsed-standards override mechanism has been removed. Applications that rely upon this mechanism, either by setting the system property java.endorsed.dirs or by placing jar files into the lib/endorsed directory of a JRE, will not work. We expect to provide similar functionality later in JDK 9 in the form of upgradeable modules.

  • The extension mechanism has been removed. Applications that rely upon this mechanism, either by setting the system property java.ext.dirs or by placing jar files into the lib/ext directory of a JRE, will not work. In most cases, jar files that were previously installed as extensions can simply be placed at the front of the class path.

  • The internal files rt.jar, tools.jar, and dt.jar have been removed. The content of these files is now stored in a more efficient format in implementation-private files in the lib directory. Class and resource files previously in tools.jar and dt.jar are now always visible via the bootstrap or application class loaders in a JDK image.

  • A new, built-in NIO file-system provider can be used to access the class and resource files stored in a run-time image. Tools that previously read rt.jar and other internal jar files directly should be updated to use this file system.

We’re aware that these changes will break some applications, in particular IDEs and other development tools which rely upon the internal structure of the JDK. We think that the improvements to performance, security, and maintainability enabled by these changes are, however, more than worth it. We’ve already reached out to the maintainers of the major IDEs to make sure that they know about these changes, and we’re ready to assist as necessary.

If you have trouble running an existing application on JDK 9 build 41 or later and you think it’s due to this restructuring, yet not caused by one of the changes listed above or in JEP 220, then please let us know on the jigsaw-dev mailing list (you’ll need to subscribe first, if you haven’t already), or else submit a bug report via bugs.java.com. Thanks!

For almost a year now I’ve had a Yoga 2 Pro. Despite some people thinking the name is silly and me only using the screen rotation once (on a plane), it’s a nice machine and Fedora 20 running GNOME is great on it. The only non-stock thing to do1 is, in Firefox, open about:config and set layout.css.devPixelsPerPx to 2.

When I bought it, I cheaped out and got the 256 GB disk. I shouldn’t have, so I recently bought a 1 TB mSATA disk to replace it. I also bought an mSATA -> USB3 enclosure to use for dding everything over to the new disk.

For reasons I can’t recall I have my encrypted /home *not* on a logical volume so growing it into the free space on the new disk basically just involved booting from a live USB stick, unlocking the LUKS volume, using gdisk to delete the existing partition and creating a new, larger one starting at the same offset, e2fsck, and resize2fs. If you’re going to do this yourself, you should of course back up your data first.

Physically changing the disk involved removing the 11 T5 bolts on the bottom and the pesky Phillips 00 bolt holding the SSD in place.

[1]

Well, depending upon how old your kernel is, you may also need to rmmod/blacklist ideapad_laptop.