Planet Classpath

After debugging a stack overflow caused by a weird class loader, I decided to make the runtime more robust against this and as a side effect I added the ability to disable eager class loading. This in turn made it easier to test the late binding infrastructure (which is used when a class is not yet available while a method is compiled) and that testing revealed a large number of bugs that have now been fixed.

Changes:

  • Bug fix. When -Xsave is used the modopt types should be attached to unloadable types in inherited method signatures.
  • Bug fix. Don't try to get constructor on generic instantiation containing a TypeBuilder generic parameter.
  • Use the last write time of the input file for resources read from the file system.
  • Enable UniverseOptions.DeterministicOutput for ikvmc (unless -debug option is used).
  • Copy timestamps from source files for generated files that end up in resources.jar.
  • The zip file timestamp is in local time, but for deterministic builds we don't want to depend on system timezone, so we have to store the UTC time.
  • Bug fix. Removed legacy (incorrect) array assignability check that compensated for the lack of ghost array typing. This should have been removed when ghost array tagging was introduced.
  • Bug fix. Verifier should disallow using invokeinterface on private methods.
  • The message of a VM generated java.lang.NoClassDefFoundError exception should be the class name, not the message of the underlying exception.
  • Bug fix. Don't crash if java.lang.invoke.LambdaMetafactory class is not loadable.
  • Added Unsafe.reallocateMemory() and fixed allocateMemory() to do nothing if zero length is allocated.
  • Bug fix. Return background color (instead of foreground color). Fix by Daniel Zatonyi .
  • Bug fix. Dynamically created ghost arrays should get tagged.
  • Bug fix. When catching a dynamically loaded .NET exception type the exception should not be remapped.
  • Bug fix. Bootstrap classes that use .NET types in their signatures should be accessible via MethodHandles.
  • Bug fix. Allow MethodHandle for cli.System.Object methods to work on (Java compatble) arrays to handle a hole in the type system.
  • Bug fix. Handle unloadable types in interface stub signatures.
  • Bug fix. MethodHandle and JNI should be able to set static final fields.
  • Bug fix. If a miranda method signature differs from its base class miranda method (due to unloadable types), we need to emit an override stub.
  • Bug fix. Allow value type default constructor to be invoked using MethodHandle.
  • Bug fix. Allow invokedynamic with unloadable type in signature.
  • Bug fix. Handle late-bound MethodHandle.invokeExact() with unloadable type in signature.
  • Bug fix. Late bound instanceof and castclass should behave the same as regular versions (with respect to type system holes caused by .NET types).
  • Bug fix. MethodHandle interface method lookup should support methods inherited from base interfaces.
  • Bug fix. Late bound delegate signature conversion should use explicitCastArguments instead of asType to handle varargs correctly.
  • Implemented delegate constructor invocation on existing object (to enable MethodHandle to construct a delegate).
  • Bug fix. Handle unloadable return type in native method signature.
  • Bug fix. Handle unloadable types in native method signature in JniProxyBuilder (used when -Xsave is used).
  • Bug fix. Late bound invokespecial should also be handled in local variable analysis.
  • Bug fix. Handle unloadable type in BSM extra arguments.
  • Bug fix. Verifier would incorrectly report a loader constraints violated if a field type was not unloadable, but the field ref type was unloadable.
  • Bug fix. Make sure declaring class is loadable.
  • Bug fix. Try loading unloadable declared classes instead of simply throwing a NoClassDefFoundError.
  • Bug fix. Make sure inner classes are loadable.
  • Bug fix. Disallow invokevirtual MH constant to resolve to interface method and disallow invokeinterface MH constant to resolve to non-public method.
  • Bug fix. Handle unloadable type in MH.invoke() signature.
  • Bug fix. Handle invocation of method on unloadable value type.
  • Bug fix. Handle ghost and value types in override stub signatures.
  • Added a hack to the deprecated Reflection.getCallerClass(int) version to skip LamdbaForm methods to report the right caller when dynamic binding is used.
  • Bug fix. Dynamica caller id should return host class for anonymous classes injected into host class.
  • Avoid infinite recursion if (broken) class loader triggers a load of a class currently being finished.
  • Added environment switch IKVM_DISABLE_EAGER_CLASS_LOADING to enable testing late binding.
  • IKVM.Reflection: Added CoreCLR target.
  • IKVM.Reflection: Fixed ModuleBuilder.DefineManifestResource() to support very large resources.
  • IKVM.Reflection: Added new public API ModuleBuilder.__PEHeaderTimeDateStamp property.
  • IKVM.Reflection: Added UniverseOptions.DeterministicOutput to enable deterministic output (i.e. setting the PE file header time stamp to zero and computing the module version id based on the contents, instead of using a random guid).

Binaries available here: ikvmbin-8.1.5561.zip

I found out that all my debian machines switched to systemd without my consent, with just a standard apt-get ugrading.
I despise that decision.

I did not follow the latest discussion about it, I was left with the impression that it would have been installed only if needed, but evidently I was wrong.

Can you get back? Time to toss Debian? I hoped not, I know of other fellow developers who switched  distribution, but Debian is Debian.

Remove systemd and sysvinit (which is now a transitional package) and put back sysvinit-core back. I had the fear that I bricked my laptops, but it still works. For how long? I don't know.

I'm very very sad about this. If I think of GNU/Linux I think of Debian, it has been with me since 68k times, when potato was cool. Debian made a very bad decision.

Something newer than ol' sysvinit? Something modern, fast, capable of parallelism. Yes.
But something portable, light, secure, which is not a dependency hell, which does one thing. In other words, something in line with the Unix philosophy.

Not the enormous pile of rotting shit which is systemd. When I removed it, I freed almost 13Mbytes from my system. I am relieved, but it shows also how big that pile of crap is.

So, for now, Debian can stay with me, I hope it will be for a long while. Long enough that debian will revert or systemd will go away.
I'm happy to announce a new release of FTP, the file transfer application of the GNUstep Application Project.

It is designed for GNUstep and completely native on the Mac too, with version 0.5 being available as a binary for both for PPC and Intel, as well, of course, as the usual source tarball for Unix.
(Please wait for the GNU.org mirrors to propagate the files or grab the sources from SVN)

There are some new features as well as bug fixes:
  • Creation of local and remote directories
  • Command to refresh the current directory listing, local and remote
  • File renaming, local and remote
  • Drag&Drop for uploading a file from GWorkspace/Finder to remote file panel
  • better handling of local and remote write errors
  • better parsing of File Sizes returned by FTP servers
  • better handling of file adding to the views, so that less "refresh" is needed
  • Bug fixes with multiple selection uploads
  • Code cleanup for better portability (gcc/clang, old and new runtime, Cocoa)

At Fosdem Volker presented a very great session on how to debug OpenJDK (and Hotspot) with gdb. Roman and Andrew (Dinn) did something similar while speaking about Shenandoah. In the next few days I’ll try to upload their slides on the FOSDEM website so that anyone can access that (and hopefully we will have the recordings this time as well).

There are a few things though that I keep forgetting myself and so I thought it would be useful to sum up in a blog post, hopefully general enough for most people as well as future reference for myself!

Suppose you are trying to detect some funny behaviour in your code, and that the crash is in a native library (or perhaps in some native OpenJDK code which is not hotspot).

What you would usually do with Java code is to start your debugger in Eclipse or IntelliJ or whatever, and go step by step until you figure out what’s wrong.

But when dealing with native code the thing gets complex, Eclipse and NetBeans can’t follow by default the native code, IntelliJ doesn’t even support native code at all (at least on Linux). There is an option though, first, you can still use those tools in process attach mode, they have very good debugging interfaces that make it easier to analyse quickly anything, but you can also use gdb directly, likewise in process attach mode.

Let’s see a couple of common cases here:

1. The application crashes, you want gdb launched automagically:

$ java -XX:OnError="gdb - %p" MyApplication

Roman (thanks!) show me this trick back in 2008! Honestly, I didn’t test that recently, but I suppose this still works ;)

2. You want to start a debugging session yourself rather than automatically on crash.

The trick here is to either start the application in debug mode via Eclipse/Whatever or attaching the Java debugger (including jdb if you enjoy suffering!) remotely:

$ java -Dsun.awt.disablegrab=true \
       -Xdebug \
       -Xrunjdwp:transport=dt_socket,server=y,address=1080 \
       MyApplication

This will produce an output like the following:

Listening for transport dt_socket at address: 1080

Blocking the application until the debugger is attached.

At this point, you can set the breakpoints in your IDE and attach to the Java process remotely. The idea is to set the breakpoint right before the native call (tip: If you follow from there stepping with the java debugger, you’ll also see how native libraries are loaded).

Now to connect gdb all you need to to is to get the pid of the java process, with jps for example:

$ jps
30481 Jps
27162 MyApplication <------

And then:

$ gdb -p 27162

Set your breakpoint in the native function of choice. Remember the name mangling, so you need to look up how the methods are actually called in native code, the naming convention is:

Java_{package_and_classname}_{function_name}(JNI arguments)

But you need to double check exactly everything since there may be method overloads that dictate a slightly different convention.

If instead of using gdb from the command line you want to use your IDE the rule to follow is the same really. Afaik both Eclipse and NetBeans allow their native debugger plugins to attach to a process.

All that is needed now is to set your gdb breakpoints and issue a continue in the gdb shell in order to resume the Java process so that it can then hit the breakpoint you just set. From there, stepping in Java code until you enter the native function will magically continue the stepping inside the native function! If you use Eclipse to do both debugging this is even extremely cool since it’s just like following the program inside the same editor!

There’s one last thing to remember (other than possibly the need to set the source location in gdb or installing the OpenJDK debuginfo package for your distribution).

Hotspot uses segfaults for a number of interesting things, like deoptimise, NullPointerException etc.. Apparently, this is faster than doing specific checks and jumping around the code. This is a problem for gdb though, since it will stop every now and then to some random routines you don’t really (usually!) care about:

(gdb) cont
Continuing.
Program received signal SIGSEGV, Segmentation fault.

Irritating, since those are all legitimate segfaults.

To avoid that just do the following in the gdb console (or from the IDE in whatever way this is handled there):

(gdb) handle SIGSEGV nostop noprint pass

Now all the interesting work can be done without interruptions ;)


Last weekend I did a talk on How to start hacking on Valgrind by example at Fosdem which contain some Easy hacks for valgrind. If If you always wanted to hack on Valgrind, but haven’t yet really looked at the code yet, then this might be a nice introduction. Make sure to also read the slides for all the other Valgrind devroom talks. Much thanks to the Fosdem organization for letting the Valgrind hackers meet. It was a great weekend.

I'm looking forward to head out to Utrecht on Thursday, February 12th, to speak on JDK 9 as part of the NetBeans Day Netherlands.

See you there!

I use Exchange at work for calendaring. I also use terminal-mode emacsclient when I’m logged in from another machine. In that scenario I can’t easily open a web browser to use Outlook Web Access. It annoyed me that I couldn’t check my schedule from within a terminal Emacs session. Thus, I did the only sensible thing and implemented full Exchange Web Services API support for Emacs.

Excorporate terminal screenshot

The result is a library called Excorporate that has proof-of-concept Calendar integration to show today’s meetings. It’s all written in Elisp, making it cross-platform. It’s also cross-Emacs; I tested it on Emacs 24.1 through Emacs 24.4, on GNU/Linux and MS-Windows. It works on all Emacs versions that support packages.

The tricky parts were:

  • extending soap-client to support all the XML Schema (XSD) datatypes required by the EWS WSDL file,
  • asynchronous URL retrieval without blocking the Emacs main loop,
  • autodiscovery of Exchange server settings from an email address, and,
  • implementing NTLMv2 authentication in Elisp.

I’m trying to get it into GNU ELPA so that other modes can always count on its core APIs being available from a default Emacs installation. I haven’t put it on GitHub yet, to keep it hidden from the ruthless efficiency of MELPA. I was impressed and appreciative when MELPA bundled slime-volleyball shortly after I released it. But I’d prefer to keep Excorporate in GNU ELPA only for now.

Anyway, I’m publishing this mode in the hope that it’s useful to other Emacs-and-Exchange users.

CORRECTION

Hi all,

I’ve done another small change to the schedule. Basically the “Java 9: Make Way for Modules” and “Beyond Java 9″ presentations have been swapped out, this is the new schedule:

Saturday:
10:30 The State of OpenJDK
11:00 Java 9: Make Way for Modules!

Sunday:
14:00 Beyond Java 9"

The FOSDEM booklet has already been printed, so those changes will not be visible. They have been picked up by the online tool, though:

https://fosdem.org/2015/schedule/track/java/


I'll be speaking on testing OpenJDK in the Java dev room at FOSDEM next weekend. If you don't see me there or at the Adoption Group Q&A, chances are I'll be around the MySQL Community stand.

See you there!

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 January 2015 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.6 (2015-01-23)

  • Security fixes
  • Import of OpenJDK6 b34
    • OJ43: Backport JAX_WS-945; Socket backlog may be limiting lwhs performance
    • OJ44: Add missing TimeZone test cases included in OpenJDK 7 revision 0.
    • OJ45: Fix copyright headers on imported files
    • OJ46: Fix lost Classpath exception
    • OJ47: Remove @Override annotation on interfaces added by 2015/01/20 security fixes.
    • OJ48: Fix substitution error.
    • OJ49: Fix placement of 8023956 fix.
    • OJ50: Fix reference to missing pd_attempt_reserve_memory_at
    • S4873188: Support TLS 1.1
    • S6364329: jstat displays “invalid argument count” with usage
    • S6461635: [TESTBUG] BasicTests.sh test fails intermittently
    • S6507067: TimeZone country/area message error
    • S6545422: [TESTBUG] NativeErrors.java uses wrong path name in exec
    • S6578647: Undefined requesting URL in java.net.Authenticator.getPasswordAuthentication()
    • S6585666: Spanish language names not compliant with CLDR
    • S6587676: Krb5LoginModule failure if useTicketCache=true on Vista
    • S6608572: Currency change for Malta and Cyprus
    • S6610748: Dateformat – AM-PM indicator in Finnish appears to be from English
    • S6627549: ISO 3166 code addition: Saint Barthelemy and Saint Martin
    • S6631048: Problem when writing on output stream of HttpURLConnection
    • S6641309: Wrong Cookie separator used in HttpURLConnection
    • S6641312: Fix krb5 codes indentation problems
    • S6645271: Wrong date format for Croatian (hr) locale
    • S6646611: Incorrect spelling of month name in locale for Belarusian language (“be”, “BY”)
    • S6647452: Remove obfuscation, framework and provider self-verification checking
    • S6653795: C2 intrinsic for Unsafe.getAddress performs pointer sign extension on 32-bit systems
    • S6659779: HttpURLConnections logger should log tunnel requests
    • S6670362: HTTP/SPNEGO should work across realms
    • S6716626: Integrate contributed language and country names for NL
    • S6720866: Slow performance using HttpURLConnection for upload
    • S6726695: HttpURLConnection shoul support ‘Expect: 100-continue’ headers for PUT
    • S6729881: Compiler warning in networking native code
    • S6765491: Krb5LoginModule a little too restrictive, and the doc is not clear.
    • S6776102: sun/util/resources/TimeZone/Bug6317929.java test failed against 6u12b01 and passed against 6u11b03
    • S6786276: Locale.getISOCountries() still contains country code “CS”
    • S6792180: Enhance to reject weak algorithms or conform to crypto recommendations
    • S6811297: Add more logging to HTTP protocol handler
    • S6822460: support self-issued certificate
    • S6830658: Changeset 67e5d3e41b5b breaks the fastdebug build in NativeCreds.c
    • S6835668: Use of /usr/include/linux/ files creates a dependence on kernel-headers
    • S6855297: Windows build breaks after 6811297
    • S6856856: NPE in HTTP protocol handler logging
    • S6868106: Ukrainian currency has wrong format
    • S6870908: reopen bug 4244752: month names in Estonian should be lowercase
    • S6873931: New Turkish currency since 2009
    • S6882594: Remove static dependancy on NTLM authentication
    • S6899503: Security code issue using Verisign root certificate
    • S6910489: Slovenia Locale, wrong firstDayOfWeek number
    • S6911104: Tests do not work with CYGWIN: tools, sun/tools, and com/sun/tools
    • S6914413: abbreviation name for November is not correct in be_BY
    • S6916787: Ukrainian currency name needs to be fixed
    • S6919624: minimalDaysInFirstWeek ressource for hungarian is wrong
    • S6931564: Incorrect display name of Locale for south africa
    • S6931566: NetworkInterface is not working when interface name is more than 15 characters long
    • S6938454: 2 new testcases for bug: Unable to determine generic type in program that compiles under Java 6
    • S6938454: Unable to determine generic type in program that compiles under Java 6
    • S6945604: wrong error message in CardImpl.java
    • S6962617: Testcase changes, cleanup of problem list for jdk_tools targets
    • S6964714: NetworkInterface getInetAddresses enumerates IPv6 addresses if java.net.preferIPvStack property set
    • S6967937: Scope id no longer being set after 6931566
    • S6972374: NetworkInterface.getNetworkInterfaces throws “java.net.SocketException” on Solaris zone
    • S6976117: SSLContext.getInstance(“TLSv1.1″) returns SSLEngines/SSLSockets without TLSv1.1 enabled
    • S7001720: copyright templates not rebranded
    • S7019267: Currency Display Names are not localized into pt_BR.
    • S7020583: Some currency names are missing in some locales
    • S7020960: CurrencyNames_sr_RS.properties is missing.
    • S7022269: clean up fscanf usage in Linux networking native code
    • S7025837: fix plural currency display names in sr_Latn_(BA|ME|RS).properties
    • S7028073: The currency symbol for Peru is wrong
    • S7035555: 4/4 attach/BasicTests.sh needs another tweak for Cygwin
    • S7036025: java.security.AccessControlException when creating JFileChooser in signed applet
    • S7036905: [de] dem – the german mark display name is incorrect
    • S7047033: (smartcardio) Card.disconnect(boolean reset) does not reset when reset is true
    • S7066203: Update currency data to the latest ISO 4217 standard
    • S7077119: remove past transition dates from CurrencyData.properties file
    • S7085757: Currency Data: ISO 4217 Amendment 152
    • S7122142, RH1151372: (ann) Race condition between isAnnotationPresent and getAnnotations
    • S7153184: NullPointerException when calling SSLEngineImpl.getSupportedCipherSuites
    • S7161796, RH1151372: PhaseStringOpts::fetch_static_field tries to fetch field from the Klass instead of the mirror
    • S7171028: dots are missed in the datetime for Slovanian
    • S7174244: NPE in Krb5ProxyImpl.getServerKeys()
    • S7185456: (ann) Optimize Annotation handling in java/sun.reflect.* code for small number of annotations
    • S7189611: Venezuela current Currency should be Bs.F.
    • S7195759: ISO 4217 Amendment 154
    • S7199066: Typo in method name
    • S7201205: Add Makefile configuration option to build with unlimited crypto in OpenJDK.
    • S8005232: (JEP-149) Class Instance size reduction
    • S8006748: getISO3Country() returns wrong value
    • S8013836: getFirstDayOfWeek reports wrong day for pt-BR locale
    • S8015421: NegativeArraySizeException occurs in ChunkedOutputStream() with Integer.MAX_VALUE
    • S8015570: Use long comparison in Rule.getRules().
    • S8021121: ISO 4217 Amendment Number 156
    • S8021372: NetworkInterface.getNetworkInterfaces() returns duplicate hardware address
    • S8022721: TEST_BUG: AnnotationTypeDeadlockTest.java throws java.lang.IllegalStateException: unexpected condition
    • S8023956: Provide a work-around to broken Linux 32 bit “Exec Shield” using CS for NX emulation (crashing with SI_KERNEL)
    • S8025051: Update resource files for TimeZone display names
    • S8026772: test/sun/util/resources/TimeZone/Bug6317929.java failing
    • S8027359: XML parser returns incorrect parsing results
    • S8027370: Support tzdata2013h
    • S8027695: There should be a space before % sign in Swedish locale
    • S8028627: Unsynchronized code path from javax.crypto.Cipher to the WeakHashMap used by JceSecurity to store codebase mappings
    • S8028726: (prefs) Check src/solaris/native/java/util/FileSystemPreferences.c for JNI pending exceptions
    • S8029153: [TESTBUG] test/compiler/7141637/SpreadNullArg.java fails because it expects NullPointerException
    • S8029318: Native Windows ccache still reads DES tickets
    • S8030822: (tz) Support tzdata2013i
    • S8031046: Native Windows ccache might still get unsupported ticket
    • S8032788: ImageIcon constructor throws an NPE and hangs when passed a null String parameter
    • S8032909: XSLT string-length returns incorrect length when string includes complementary chars
    • S8035613: With active Securitymanager JAXBContext.newInstance fails
    • S8037012: (tz) Support tzdata2014a
    • S8038306: (tz) Support tzdata2014b
    • S8040617: [macosx] Large JTable cell results in a OutOfMemoryException
    • S8041990: [macosx] Language specific keys does not work in applets when opened outside the browser
    • S8043012: (tz) Support tzdata2014c
    • S8046343: (smartcardio) CardTerminal.connect(‘direct’) does not work on MacOSX
    • S8049250: Need a flag to invert the Card.disconnect(reset) argument
    • S8049343: (tz) Support tzdata2014g
    • S8050485: super() in a try block in a ctor causes VerifyError
    • S8051012: Regression in verifier for <init> method call from inside of a branch
    • S8051614: smartcardio TCK tests fail due to lack of ‘reset’ permission
    • S8054367: More references for endpoints
    • S8055222: Currency update needed for ISO 4217 Amendment #159
    • S8056211: api/java_awt/Event/InputMethodEvent/serial/index.html#Input[serial2002] failure
    • S8058715: stability issues when being launched as an embedded JVM via JNI
    • S8059206: (tz) Support tzdata2014i
    • S8060474: Resolve more parsing ambiguity
    • S8061826: Part of JDK-8060474 should be reverted
    • S8062561: Test bug8055304 fails if file system default directory has read access
    • S8062807: Exporting RMI objects fails when run under restrictive SecurityManager
    • S8064560: (tz) Support tzdata2014j
  • Backports
    • OJ51, PR2187: Sync patch for 4873188 with 7 version
    • OJ52, PR2185: Application of 6786276 introduces compatibility issue
    • OJ53, PR2181: strict-aliasing warnings issued on PPC32
    • OJ54, PR2182: 6911104 reintroduces test fragment removed in existing 6964018 backport
    • S6730740, PR2186: Fix for 6729881 has apparently broken several 64 bit tests: “Bad address”
    • S7031830, PR2183: bad_record_mac failure on TLSv1.2 enabled connection with SSLEngine
    • S8000897, PR2173, RH1155012: VM crash in CompileBroker
    • S8020190, PR2174, RH1176718: Fatal: Bug in native code: jfieldID must match object
    • S8028623, PR2177, RH1168693: SA: hash codes in SymbolTable mismatching java_lang_String::hash_code for extended characters.
    • S8061785, PR2177: [TEST_BUG] serviceability/sa/jmap-hashcode/Test8028623.java has utf8 character corrupted by earlier merge
  • Bug fixes
    • PR1831: Drop version requirement for LCMS 2
    • PR1832, RH1022017: Report elliptic curves supported by NSS, not the SunEC library
    • PR2033: patches/ecj/jaxws-getdtdtype.patch no longer applies since removal of JAXWS drop
    • PR2062: Unset OS before running OpenJDK build
    • PR2070: Type-punning warnings still evident on RHEL 5
    • PR2082: Cast should use same type as GCDrainStackTargetSize (uintx).
    • PR2096, RH1163501: 2048-bit DH upper bound too small for Fedora infrastructure
    • PR2125: Synchronise elliptic curves in sun.security.ec.NamedCurve with those listed by NSS
    • PR2179: Avoid x86 workaround when running Zero rather than a JIT
    • PR2180: Old autotools dislike $(builddir)/fsg.sh
  • CACAO
    • PR2184: CACAO lacks JVM_FindClassFromCaller introduced by security patch in 1.13.5
  • JamVM
    • PR2190: JamVM lacks JVM_FindClassFromCaller introduced by security patch in 1.13.5

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: rsa4096/248BDC07 (hkp://keys.gnupg.net)
  • Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07

I’m transitioning to the use of a new key for signing releases over the next year. Signatures made with this key are available at:

and the new key is:

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

SHA256 checksums:

  • eb06a1e9a16f6473ffac4072c753e8e0fd1c39ad00016bcbd984534a93189e52 icedtea6-1.13.6.tar.gz
  • 1e62fe97d4a6dfe641373889534741ec5f06d268e2ea14a8f4ff505560e1c3f8 icedtea6-1.13.6.tar.gz.sig
  • 356edb04945690e216f0569e9dc8afd8f55c2a0dfc8816a904e63506220cb523 icedtea6-1.13.6.tar.gz.sig.ec
  • 2090f3a9e4b045073f8fcd147848e3b94b389fa2740b20ded4c5d2398f1b4c99 icedtea6-1.13.6.tar.xz
  • ac02dc6515afcf2aac2d731e56b7aa6c987e98b7c7a9ed214e4e4a08d2b21528 icedtea6-1.13.6.tar.xz.sig
  • 1fa7b55a960cbf3db4000e170c95b3e78413fef45655609de05f55a7c5012347 icedtea6-1.13.6.tar.xz.sig.ec

The checksums can be downloaded from:

A 1.13.5 ebuild for Gentoo is available.

The following people helped with these releases:

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

To get started:

$ tar xzf icedtea6-1.13.6.tar.gz

or:

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

then:

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

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

Happy hacking!

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.

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

This release updates our OpenJDK 7 support in the 2.5.x series with the January 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.5.4 (2015-01-21)

  • Security fixes
  • Backports
    • S6461635: [TESTBUG] BasicTests.sh test fails intermittently
    • S6545422: [TESTBUG] NativeErrors.java uses wrong path name in exec
    • S6653795: C2 intrinsic for Unsafe.getAddress performs pointer sign extension on 32-bit systems
    • S7028073: The currency symbol for Peru is wrong
    • S7047033: (smartcardio) Card.disconnect(boolean reset) does not reset when reset is true
    • S7183753: [TEST] Some colon in the diff for this test
    • S7077119, PR2165, G534118: remove past transition dates from CurrencyData.properties file
    • S7085757: Currency Data: ISO 4217 Amendment 152
    • S7169142: CookieHandler does not work with localhost
    • S7172012, PR2067: Make test-in-build an option (Queens)
    • S7185456: (ann) Optimize Annotation handling in java/sun.reflect.* code for small number of annotations
    • S7195759: ISO 4217 Amendment 154
    • S8000897, RH1155012: VM crash in CompileBroker
    • S8001105: findVirtual of Object[].clone produces internal error
    • S8005232: (JEP-149) Class Instance size reduction
    • S8006748: getISO3Country() returns wrong value
    • S8012026: [macosx] Component.getMousePosition() does not work in an applet on MacOS
    • S8015421: NegativeArraySizeException occurs in ChunkedOutputStream() with Integer.MAX_VALUE
    • S8020190, PR2160, RH1176718: Fatal: Bug in native code: jfieldID must match object
    • S8021121: ISO 4217 Amendment Number 156
    • S8021372: NetworkInterface.getNetworkInterfaces() returns duplicate hardware address
    • S8022721: TEST_BUG: AnnotationTypeDeadlockTest.java throws java.lang.IllegalStateException: unexpected condition
    • S8025051: Update resource files for TimeZone display names
    • S8026792: HOTSPOT: licensee reports a JDK8 build failure after 8005849/8005008 fixes integrated.
    • S8027359: XML parser returns incorrect parsing results
    • S8028623, PR2112, RH1168693: SA: hash codes in SymbolTable mismatching java_lang_String::hash_code for extended characters.
    • S8028627: Unsynchronized code path from javax.crypto.Cipher to the WeakHashMap used by JceSecurity to store codebase mappings
    • S8028726: (prefs) Check src/solaris/native/java/util/FileSystemPreferences.c for JNI pending exceptions
    • S8029153: [TESTBUG] test/compiler/7141637/SpreadNullArg.java fails because it expects NullPointerException
    • S8031046: Native Windows ccache might still get unsupported ticket
    • S8031502: JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter
    • S8032078: [macosx] CPlatformWindow.setWindowState throws RuntimeException, if windowState=ICONIFIED|MAXIMIZED_BOTH
    • S8032669: Mouse release not being delivered to Swing component in 7u45
    • S8032788: ImageIcon constructor throws an NPE and hangs when passed a null String parameter
    • S8032909: XSLT string-length returns incorrect length when string includes complementary chars
    • S8034200: Test java/net/CookieHandler/LocalHostCookie.java fails after fix of JDK-7169142
    • S8036863: Update jdk7 testlibrary to match jdk8 in hotspot
    • S8040168: Set hotspot version to hs24.66 and build to b01 for 7u66
    • S8040617: [macosx] Large JTable cell results in a OutOfMemoryException
    • S8041132: Increment hsx 24.66 build to b02 for 7u66-b09
    • S8041408: Increment hsx 24.55 build to b04 for 7u55-b34
    • S8041572: [macosx] huge native memory leak in AWTWindow.m
    • S8041990: [macosx] Language specific keys does not work in applets when opened outside the browser
    • S8043610: Sorting columns in JFileChooser fails with AppContext NPE
    • S8044603: Increment minor version of HSx for 7u71 and initialize the build number
    • S8046343: (smartcardio) CardTerminal.connect(‘direct’) does not work on MacOSX
    • S8049250: Need a flag to invert the Card.disconnect(reset) argument
    • S8049343: (tz) Support tzdata2014g
    • S8049758: Increment minor version of HSx for 7u75 and initialize the build number
    • S8050485: super() in a try block in a ctor causes VerifyError
    • S8051359: JPopupMenu creation in headless mode with JDK9b23 causes NPE
    • S8051614: smartcardio TCK tests fail due to lack of ‘reset’ permission
    • S8055222: Currency update needed for ISO 4217 Amendment #159
    • S8056211: api/java_awt/Event/InputMethodEvent/serial/index.html#Input[serial2002] failure
    • S8057184: JCK8′s api/javax_swing/JDesktopPane/descriptions.html#getset failed with GTKLookAndFeel on Linux and Solaris
    • S8058715: stability issues when being launched as an embedded JVM via JNI
    • S8059206: (tz) Support tzdata2014i
    • S8060474: Resolve more parsing ambiguity
    • S8061685: Increment hsx 24.75 build to b02 for 7u75-b06
    • S8061785: [TEST_BUG] serviceability/sa/jmap-hashcode/Test8028623.java has utf8 character corrupted by earlier merge
    • S8061826: Part of JDK-8060474 should be reverted
    • S8062561: Test bug8055304 fails if file system default directory has read access
    • S8062807: Exporting RMI objects fails when run under restrictive SecurityManager
    • S8064300: Increment hsx 24.75 build to b03 for 7u75-b06
    • S8064560: (tz) Support tzdata2014j
    • S8065608: 7u75 l10n resource file translation update
    • S8065787: Increment hsx 24.75 build to b04 for 7u75-b10
    • S8066747: Backing out Japanese translation change in awt_ja.properties
    • S8067364, PR2145, RH114622: Printing to Postscript doesn’t support dieresis
  • Bug fixes
    • PR2064: Unset OS before running OpenJDK build
    • PR2069: Type-punning warnings still evident on RHEL 5
    • PR2094, RH1163501: 2048-bit DH upper bound too small for Fedora infrastructure
    • PR2123: SunEC provider crashes when built using system NSS
    • PR2124: Synchronise elliptic curves in sun.security.ec.NamedCurve with those listed by NSS
    • PR2135: Race condition in SunEC provider with system NSS
    • PR2161: RHEL 6 has a version of GIO which meets the version criteria, but has no g_settings_*
  • CACAO
    • PR2032: CACAO lacks JVM_FindClassFromCaller introduced by security patch in 2.5.3
  • JamVM
    • PR2050: JamVM lacks JVM_FindClassFromCaller introduced by security patch in 2.5.3
    • PR2171: JamVM builds with executable stack, causing failures on SELinux & PaX kernels
  • AArch64 port
    • Use the IcedTea7 fork version rather than the one based on HotSpot 25.
    • Add arch-specific processing of tmp1 register needed for d/f2i
    • Add char_array_equals intrinsic
    • Add CNEG and CNEGW to macro assembler.
    • Add frame anchor fences.
    • Add missing instruction synchronization barriers and cache flushes.
    • Add some memory barriers for object creation and runtime calls.
    • Add support for A53 multiply accumulate
    • Add support for AES Intrinsics
    • Add support for pipeline scheduling
    • Add support for String.indexOf intrinsic
    • Added make rules to allow aarch64-x86 hybrid build to progress
    • Added missing aarch64-specific include
    • Added missing aarch64-specific make file
    • Added missing changes for debug code
    • Added missing inline method
    • Added missing shared global UseCRC32Intrinsics
    • Added pd global UseVectoredExceptions
    • Add local method to redirect to AbstractAssembler::relocate
    • Add missing declarations for CRC32 methods
    • Add missing include
    • Add missing special case code for aarch64
    • Add rules to assemble .S files
    • Add support for storing aarch64 call format
    • Add wrapper method to avoid dependency on not yet defined code buffer class
    • Added missing endif
    • Allow for 0×400 aligned offsets for byte_map_base
    • Array load must only read 32 bits
    • A more efficient sequence for C1_MacroAssembler::float_cmp.
    • Backout 8c8b5e62e624 and instead move .S rule from zeroshark.make to rules.make
    • Backout additional changes made in ec6a6772fed6, which revert parts of the PPC/AIX port and IcedTea fixes.
    • Call ICache::invalidate_range() from Relocation::pd_set_data_value().
    • Changed klass oop encode to heap oop encode
    • Changed Method* to methodOop
    • Correct assert to allow for AArch64
    • Correct for difference in include hierarchy
    • Correct typos
    • Corrected error in disassembler code
    • Corrected include
    • Corrected include path
    • Corrected pipeline class for countTrailingZerosL
    • Corrected type
    • Corrected typo
    • Correct includes
    • Correct Method to methdoOopDesc
    • Define uabs(). Use it everywhere an absolute value is wanted.
    • Defn of BIND does not need to use __ macro
    • Delete dead code.
    • Disassembler library should be built as hsdis-aarch64.so
    • Don’t test arraycopy routines when using AArch64 simulator
    • Emit_int64 is renamed
    • Ensure byte_map_base can be loaded using adrp with no need for following ldr
    • Ensure C1 static call stub employs absolute move to allow patching
    • Ensure C2 static calls use correct call adddress in static stub reloc
    • Ensure perm gen size is not rounded down to zero
    • Ensure rmethod is reloaded from stack when interpreter makes non leaf VM call
    • Ensure we pick up hsdis-aarch64.so if BUILTIN_SIM is true
    • Fix couple of mistakes in generate of method handle dispatch
    • Fix cut and paste-o in header
    • Fixed another typo
    • Fixed error in include
    • Fixed hsdis for aarch64 native or simulated
    • Fixed various typos and omissions
    • Fixed various typos, overlooked cases and wrong accessors
    • Fix error introduced into profiling code
    • Fix guarantee failure in synchronizer.cpp
    • Fix more errors introduced into interpreter profile counter increment
    • Fix relocations
    • Fix several small typos
    • Fix some typos
    • Fix thinko in Atomic::xchg_ptr.
    • Fix typo
    • Fix up aarch64-specific patching code
    • Fix up crc32 support
    • Fix various typos
    • Get rid of unnecessary declaration
    • Guess at how to implement C1 deoptimize_trap generator
    • Initial cut of aarch64 code pulled from jdk8 tree
    • Make aarch64-x86 hybrid build use correct paths
    • Make hsdis handle aarch64 native case
    • Make static stubs load methodOop in cpool to avoid problems at GC
    • Miscellaneous bug fixes.
    • Missing change needed to support aarch64 build
    • Modified make files to support aarch64 build
    • Modified shared src to support full aarch64 backport
    • Moved fields which need access from java to top level
    • Need to actually return the adapter code size
    • Need to pass CFLAGS when assembling .S files using CC_COMPILE
    • Need to use class handle not class
    • Provide missing CRC32 methods
    • Reload rcpool register after a VM call in case a permgen GC has moved the cache
    • Relocated aarch64 vtable generate code to conform to jdk7
    • Remove comment to avoid breaking macro
    • Removed aarch64 compiled_IC implementation to conform to jdk7
    • Removed metaspaceShared code to conform to jdk7
    • Removed redundant field use_XOR_for_compressed_class_base
    • Removed some errors in signal handling code
    • Removed undefined metadata case
    • Remove redundant bracket
    • Remove support for volatile load/store rules in ad file
    • Renamed emit_int32 to emit_long and added local emit_long64 in place of missing emit_int64
    • Restored missing open brace
    • Restored several load_heap_oop calls lost in translation
    • Restore working x86 build
    • Reverted aarch64 architecture description (ad) file to conform to jdk7
    • Reverted aarch64 c1_xxx files to conform to jdk7
    • Reverted aarch64 c2 globals to conform to jdk7
    • Reverted aarch64 frame code to conform to jdk7
    • Reverted aarch64 runtime code to conform to jdk7
    • Reverted aarch64 stubs code to conform to jdk7
    • Reverted aarch64 template interpreter code to conform to jdk7
    • Reverted aarch64 vm structs code to conform to jdk7
    • Reverted aarch64 vm version code to conform to jdk7
    • Reverted aarch64 vtable stubs code to conform to jdk7
    • Reverted assembler_aarch64.cpp/hpp to conform to jdk7
    • Reverted bytecodeInterpreter_aarch64 to conform to jdk7
    • Reverted global defs code to conform to jdk7
    • Reverted instr cache code to conform to jdk7
    • Reverted interpreter code to conform to jdk7
    • Reverted interpreter masm code to conform to jdk7
    • Reverted jni code to conform to jdk7
    • Reverted method handles code to conform to jdk7
    • Reverted native instr code to conform to jdk7
    • Reverted os_cpu/linux_aarch64 code to conform to jdk7
    • Reverted reloc info code to conform to jdk7
    • Revert Method:: etc to methodOopDesc:: etc
    • Scripts to build aarch64-x86 hybrid and aarch64 native debug images
    • Some errors revealed when building debug image
    • Temporarily disable running test_gamma
    • Tidy up allocation prefetch
    • Use correct post-increment size in repne_scanw
    • Use membar rules and delete special case volatile rules
    • Use method register to access counter increment field
    • Use movoop in C1 ic_call to keep verifier happy
    • Use os::malloc to allocate the register map.
    • Use the correct return value from the VM resolve call
    • Use TLS for ThreadLocalStorage::thread()
    • Various changes to accommodate inclusion of ppc port in icedtea7
    • Various concurrency fixes.
    • Work around weird compiler issue

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: rsa4096/248BDC07 (hkp://keys.gnupg.net)
  • Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07

I’m transitioning to the use of a new key for signing releases over the next year. Signatures made with this key are available at:

and the new key is:

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

SHA256 checksums:

  • 5301b9a8592af2cf8e3e7a3650e5e1fe744c6d2de7f8ff78080b2eeae86a9800 icedtea-2.5.4.tar.gz
  • 379388e05eeb2076fad256c95e8045f5b83ce18f9aac4f9d3875eafe840cb6e6 icedtea-2.5.4.tar.gz.sig
  • 3d34129aa9c85f7e0cf8a90b8456a750a05951928d32ca00170dcb7b02ef5b05 icedtea-2.5.4.tar.gz.sig.ec
  • 1b50f5c42417c899e0dc831351470557c504c4e648f72cc621be9318c215ffda icedtea-2.5.4.tar.xz
  • c86eeaefb7c7b6e869c24933da07882a2779d045b1d6b05d77f36ac7a089aeb0 icedtea-2.5.4.tar.xz.sig

The checksums can be downloaded from:

A 2.5.4 ebuild for Gentoo is available.

The following people helped with these releases:

  • Andrew Dinn (AArch64 backport)
  • Andrew Hughes (all backports & bug fixes, release management)
  • Robert Lougher (JamVM build fix)
  • Xerxes Rånby (CACAO build fix)
  • Pavel Tisnovsky (executable stack issue with JamVM)

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

To get started:

$ tar xzf icedtea-2.5.4.tar.gz

or:

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

then:

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

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

Happy hacking!

At work I have cause to edit a TWiki that my team uses for internal documentation. I wanted to use Emacs for this task, so that I wouldn’t need to interact with a web browser text area widget. I couldn’t find anything that did that, so I took the closest thing I could find, erin.el, a TWiki markup mode, and added connectivity to it via Emacs’s url package.

The result is a fork of erin.el that supports these new operations:

Log in: M-x erin-log-in
Edit a topic: M-x erin-edit-topic
Commit edits: C-c C-c
Cancel edits: C-c C-k
Log out: M-x erin-log-out

without ever leaving Emacs. Now with EWW to see the resulting pages, there’s no need to leave Emacs at all.

This being a fork, it doesn’t qualify for MELPA, and I can’t get in touch with the original author, so it will stay in limbo as a raw repo, without ever being packaged.

A while after I did this development, emacs-twiki-mode sprang up. It looks like it has some nice advantages, like orgtbl editing. If it used Emacs’s built-in URL handling instead of an external bash script I would probably switch to it. For now my erin.el fork works well enough for me. I do wish there were one monster Emacs mode that would handle all Wiki server implementations, including connectivity; a sort of Gnus for Wikis. Oh well.

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!

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

What's New (relative to rc 0):

  • Fixed build error when using Java 8u25 or newer.
  • Bug fix. Unsafe.compareAndSwapObject should resolve field before passing it to MakeTypedReference.
  • Implemented OperatingSystemMXBean.getFreePhysicalMemorySize and OperatingSystemMXBean.getTotalPhysicalMemorySize.

Binaries available here: ikvmbin-8.0.5449.1.zip

Sources: ikvmsrc-8.0.5449.1.zip, openjdk-8-b132-stripped.zip

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.

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

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

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

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

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

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

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

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

)

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

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

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

(add-hook 'find-file-hook #'tromey-maybe-enable-bug-url-mode)
(add-hook 'log-view-mode-hook #'tromey-maybe-enable-bug-url-mode)
(add-hook 'diff-mode-hook #'tromey-maybe-enable-bug-url-mode)

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

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

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

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

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

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

Here’s the example from the docs:

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

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

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

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

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

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

jfreechart-1.0.19.png

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

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

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

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

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

Overview

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

What's New?

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

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

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

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

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

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

General Use

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

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

jlatexmath_example.png

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

Summary

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

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

Peter Miller

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

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

AfC

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

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

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

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

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

Comments, questions, and suggestions are welcome on the jigsaw-dev mailing list. (If you haven’t already subscribed to that list then please do so first, otherwise your message will be discarded as spam.)

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

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

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

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

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

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

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

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

Here’s one to start us off:

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

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

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

AfC

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

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

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

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

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

A demo is available on the Chrome Web Store.