GNU Classpath

I finally created a github repository for ikdasm. A couple of weeks ago I fixed some ildasm compatibility issues and changed pinvokeimpl and marshalas handling to use the IKVM.Reflection specific APIs instead of decoding the ... [More] pseudo custom attributes (I also used the new IKVM.Reflection feature to disable generating pseudo custom attributes). I added external module support and fixed some other small issues. The primary purpose of ikdasm is to make sure that the IKVM.Reflection API is complete. I believe it now exposes all relevant Managed PE file features. The secondary feature is to test IKVM.Reflection and to make this easy ikdasm replicates (almost) all ildasm quirks to enable comparing the output files. I disassembled a large number of files (including C++/CLI and Managed C++ files) and compared the results. Only a small subset of ildasm functionality has been cloned. There is no GUI and most command line options are also not implemented. Pull requests are welcome. [Less]

Still more changes to better support what I'll start calling "mixed mode" (i.e. ikvmc compiled assemblies that use dynamically loaded classes or use dynamic binding to classes in another assembly). Another change ... [More] is that runtime stub class generation is now based on the ikvmstub class file writer, instead of the very old code that was reflection based. This means that stubs can now acurately be generated even when some of the types involved are not available. Changes: Refactored assembly class loading. Added ikvm.runtime.EnumerationWrapper to expose an IEnumerable as a java.util.Enumeration. Removed the old runtime Java stub class generator and replaced it with the ikvmstub core. Allow dynamic class loading from boot class "path" and referenced assemblies. Regression fix. The previous custom assembly class loader construction rewrite introduced a bug. Bug fix. MethodHandle should be able to call dynamic only methods. Bug fix. MethodHandle to Object.clone/finalize should be special cased. Reimplemented dynamic binding on top of MethodHandles. Binaries available here: ikvmbin-7.3.4804.zip [Less]

A little while ago, the OpenJDK twitter feed reached 7000 followers, about five months after reaching 6000 last autumn.Thanks for following along on the journey towards JDK 8.

I'll be speaking at Java User Group Mannheim in Mannheim, Germany on Thursday, February 28th about Java SE 8.See you there!

As part of Project Lambda, after discussion with the JSR 335 expert group, we decided to add a FunctionalInterface annotation type to the platform. To a first approximation, functional interfaces are those interface types which define only a ... [More] single method and are therefore usable in lambda expressions. (There are some tricky details in the definition of a functional interface relating to generics and also some details about excluding from consideration methods defined on java.lang.Object.) The new annotation type allows a library designer to clearly indicate the property of intending an interface type to be used with lambda expressions along with an implied commitment to keep that property true in the future. However, the compiler will allow any interface type meeting the structural properties of a functional interface to be used for a lambda expression regardless of whether or not the interface has a @FunctionalInterface annotation. They types being added in the java.util.function package are by design functional interfaces and can be annotated with @FunctionalInterface from early days. However, many existing Java SE types are also functional interfaces and we want to identify and annotate those appropriately too. To find those candidate interfaces to be annotated, I ran an annotation processor over the code, using the same methodology as used to find Closeable candidates during JDK 7. A significant number of candidates were found throughout the JDK. After suitable discussion and review, the first batch of core libraries changes have been pushed. Analogous discussions have been started in the 2D, awt, and swing areas. For guidance in retrofitting @FunctionalInterface to an existing candidate type, if the type is routinely instantiated using an anonymous class, it is a good candidate for being annotated with @FunctionalInterface. [Less]

The IcedTea project provides a harness to build the source code from OpenJDK using Free Software build tools, along with additional features such as a PulseAudio sound driver and support for alternative virtual machines. A new set of security ... [More] releases are now available for the OpenJDK 7 series: 2.1.6, 2.2.6 & 2.3.7. These contain the following security fixes: S8004937, CVE-2013-1484: Improve proxy construction S8006439, CVE-2013-1485: Improve MethodHandles coverage S8006446, CVE-2013-1486: Restrict MBeanServer access S8006777, CVE-2013-0169: Improve TLS handling of invalid messages S8007688: Blacklist known bad certificate In addition, IcedTea includes the usual IcedTea patches to allow builds against system libraries and to support more estoric architectures. If you find an issue with one of these releases, 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 releases can be found below. What’s New? New in release 2.3.7 (2013-02-20) Security fixes S8004937, CVE-2013-1484: Improve proxy construction S8006439, CVE-2013-1485: Improve MethodHandles coverage S8006446, CVE-2013-1486: Restrict MBeanServer access S8006777, CVE-2013-0169: Improve TLS handling of invalid messages S8007688: Blacklist known bad certificate Backports S8007393: Possible race condition after JDK-6664509 S8007611: logging behavior in applet changed Bug fixes PR1303: Support building with giflib 5 New in release 2.2.6 (2013-02-20) Security fixes S8004937, CVE-2013-1484: Improve proxy construction S8006439, CVE-2013-1485: Improve MethodHandles coverage S8006446, CVE-2013-1486: Restrict MBeanServer access S8006777, CVE-2013-0169: Improve TLS handling of invalid messages S8007688: Blacklist known bad certificate Backports S8007393: Possible race condition after JDK-6664509 S8007611: logging behavior in applet changed Bug fixes PR1303: Support building with giflib 5 New in release 2.1.6 (2013-02-20) Security fixes S8004937, CVE-2013-1484: Improve proxy construction S8006439, CVE-2013-1485: Improve MethodHandles coverage S8006446, CVE-2013-1486: Restrict MBeanServer access S8006777, CVE-2013-0169: Improve TLS handling of invalid messages S8007688: Blacklist known bad certificate Backports S7123519: problems with certification path S8007393: Possible race condition after JDK-6664509 S8007611: logging behavior in applet changed Bug fixes PR1303: Support building with giflib 5 The tarballs can be downloaded from: http://icedtea.classpath.org/download/source/icedtea-2.1.6.tar.gz (sig) http://icedtea.classpath.org/download/source/icedtea-2.2.6.tar.gz (sig) http://icedtea.classpath.org/download/source/icedtea-2.3.7.tar.gz (sig) SHA256 checksums: e6a65923acb29b87b9f8492adc6f00152b489441e788b64e2869301cc7fa29ba icedtea-2.1.6.tar.gz 90adf40e725d7a301c3e23efdb75fcb992b0e645d8be0250cd4d058d85488f33 icedtea-2.2.6.tar.gz 378f67f6f84bfb6c705f600b47b68a61b18d67648dd7eaf8498b152587695940 icedtea-2.3.7.tar.gz Each tarball is accompanied by a digital signature available at the above ‘sig’ link. This is produced using my public key. See details below. PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 The following people helped with these releases: Elliott Baron (production of reproducer for S8006439) Severin Gehwolf (production of reproducer for S8006777) Andrew John Hughes (application of security fixes & backports, creation & testing of bug fixes, reproducer testing, release management) We would also like to thank the bug reporters and testers! To get started: $ tar xzf icedtea-${version}.tar.gz where ${version} is the version of IcedTea being used. Full build requirements and instructions are in INSTALL: $ mkdir icedtea-build $ cd icedtea-build $ ../icedtea-${version}/configure [--enable-zero --enable-pulse-java --enable-systemtap ...] $ make Happy hacking! [Less]

A quick update because the previous snapshot had a bug that caused ikvmc to be completely broken on the CLR x86 JIT. Changes: Changed build to explicitly exclude the classes that are ... [More] already defined in map.xml. Changed ikvmc to add uncompilable classes loaded from the file system to classes.jar. Changed ikvmc to copy zip file comment. Changed ikvmc to emit a warning if a remapped type duplicates a loaded class. Removed CallerID optimization special casing since we can now call internal members from dynamic assemblies. Added some version information to the Internal Compiler Error message. Added some version information to runtime critical failure. Fixed AttributeHelper to have a deterministic class constructor. Bug fix. Disallow invalid class names in AssemblyClassLoader.loadClass(). Removed the special casing of generic type definition loading as we've since exposed the generic type definitions to Java. Some beginnings of class loading refactoring. Binaries available here: ikvmbin-7.3.4799.zip [Less]

I’ve got an ugly piece of Haskell code: 213 baselineContextSSL :: IO SSLContext 214 baselineContextSSL = do 215 ctx <- SSL.context -- a completely blank context 216 contextSetDefaultCiphers ctx 217 #if defined __MACOSX__ 218 ... [More] contextSetVerificationMode ctx VerifyNone 219 #elif defined __WIN32__ 220 contextSetVerificationMode ctx VerifyNone 221 #else 222 contextSetCADirectory ctx "/etc/ssl/certs" 223 contextSetVerificationMode ctx $ 224 VerifyPeer True True Nothing 225 #endif 226 return ctx this being necessary because the non-free operating systems don’t store their X.509 certificates in a place that openssl can reliably discover them. This sounds eminently solvable at lower levels, but that’s not really my immediate problem; after all, this sort of thing is what #ifdefs are for. The problem is needing to get an appropriate symbol based on what OS you’re using defined. I naively assumed there would be __LINUX__ and __MACOSX__ and __WIN32__ macros already defined by GHC because, well, that’s just the sort of wishful thinking that powers the universe. When I asked the haskell-cafe mailing list for suggestions, Krzysztof Skrzętnicki said that I could use in my project’s .cabal file. Nice, but problematic because you’re not always building using Cabal; you might be working in ghci, you might be using a proper Makefile to build your code, etc. Then Henk-Jan van Tuyl pointed out that you can get at the Cabal logic care of Distribution.System. Hey, that’s cool! But that would imply depending on and linking the Cabal library into your production binary. That’s bad enough, but the even bigger objection is that binaries aren’t portable, so what’s the point of having a binary that — at runtime! — asks what operating system it’s on? No; I’d rather find that out at build time and then let the C pre-processor include only the relevant code. This feels simple and an appropriate use of CPP; even the symbol names look just about like what I would have expected (stackoverflow said so, must be true). Just need to get the right symbol defined at build time. But how? Build Types Running cabal install one sees all kinds of packages building and I’d definitely noticed some interesting things happen; some packages fire off what is obviously an autoconf generated ./configure script; others seem to use ghci or runghc to dynamically interpret a small Haskell program. So it’s obviously do-able, but as is often the case with Haskell it’s not immediately apparent where to get started. Lots of libraries available on Hackage come with a top-level Setup.hs. Whenever I’d looked in one all I’d seen is: 1 import Distribution.Simple 2 main = defaultMain which rather rapidly gave me the impression that this was a legacy of older modules, since running: $ cabal configure $ cabal build $ cabal install on a project without a Setup.hs apparently just Does The Right Thing™. It turns out there’s a reason for this. In a project’s .cabal file, there’s a field build-type that everyone seems to define, and of course we’re told to just set this to “Simple”: 27 build-type: Simple what else would it be? Well, the answer to that is that “Simple” is not the default; “Custom” is (really? weird). And a custom build is one where Cabal will compile and invoke Setup.hs when cabal configure is called. Ahh. When you look in the documentation of the Cabal library (note, this is different from the cabal-install package which makes the cabal executable we end up running) Distribution.Simple indeed has defaultMain but it has friends. The interesting one is defaultMainWithHooks which takes this monster as its argument; sure enough, there are pre-conf, post-conf, pre-build, post-build, and so on; each one is a function which you can easily override. 20 main :: IO () 21 main = defaultMainWithHooks $ simpleUserHooks { 22 postConf = configure 23 } 24 25 configure :: Args -> ConfigFlags -> PackageDescription -> LocalBuildInfo -> IO () 26 configure _ _ _ _ = do 27 ... yeay for functions as first class objects. From there it was a simple matter to write some code in my configure function to call Distribution.Simple’s buildOS and write out a config.h file with the necessary #define I wanted: 1 #define __LINUX__ Include Paths We’re not quite done yet. As soon as you want to #include something, you have to start caring about include paths. It would appear the compiler, by default, looks in the same directory as the file it is compiling. Fair enough, but I don’t really want to put config.h somewhere deep in the src/Network/Http/ tree; I want to put it in the project’s top level directory, commonly known as ., also known as “where I’m editing and running everything from”. So you have to add a -I"." option to ghc invocations in your Makefiles, your .cabal file needs to be told in its way: 61 library 62 include-dirs: . and as for ghci, it turns out you can put a .ghci in your sources: 1 :set -XOverloadedStrings 2 :set +m 3 :set -isrc:tests 4 :set -I. and if you put that in your project root directory, running ghci there will work without having to specify all that tedious nonsense on the command line. The final catch is that you have to be very specific about where you put the #include directive in your source file. Put it at the top? Won’t work. After the pragmas? You’d think. Following the module statement? Nope. It would appear that it strictly has to go after the imports and before any real code. Line 65: 47 import Data.Monoid (Monoid (..), (<>)) 48 import qualified Data.Text as T 49 import qualified Data.Text.Encoding as T 50 import Data.Typeable (Typeable) 51 import GHC.Exts 52 import GHC.Word (Word8 (..)) 53 import Network.URI (URI (..), URIAuth (..), parseURI) 64 65 #include "config.h" 66 67 type URL = ByteString 68 69 -- 70 -- | Given a URL, work out whether it is normal or secure, and then 71 -- open the connection to the webserver including setting the 72 -- appropriate default port if one was not specified in the URL. This 73 -- is what powers the convenience API, but you may find it useful in 74 -- composing your own similar functions. 75 -- 76 establishConnection :: URL -> IO (Connection) 77 establishConnection r' = do 78 ... You get the idea. Choices Several people wrote to discourage this practice, arguing that conditional code is the wrong approach to portability. I disagree, but you may well have a simple piece of code being run dynamically that would do well enough just making the choice at runtime; I’d be more comfortable with that if the OS algebraic data type was in base somewhere; linking Cabal in seems rather heavy. Others tried to say that needing to do this at all is openssl‘s fault and that I should be using something else. Perhaps, and I don’t doubt that we’ll give tls a try at some point. But for now, openssl is battle-tested crypto and the HsOpenSSL package is a nice language binding and heavily used in production. Meanwhile I think I’ve come up with a nice technique for defining things to drive conditional compilation. You can see the complete Setup.hs I wrote here; it figures out which platform you’re on and writes the .h file accordingly. If you have need to do simple portability conditionals, you might give it a try. AfC [Less]

The IcedTea project provides a harness to build the source code from OpenJDK using Free Software build tools, along with additional features such as a PulseAudio sound driver and support for alternative virtual machines. A new set of security ... [More] releases are now available for the OpenJDK 6 series: 1.11.8 & 1.12.3. These contain the following security fixes: S8006446, CVE-2013-1486: Restrict MBeanServer access S8006777, CVE-2013-0169: Improve TLS handling of invalid messages S8007688: Blacklist known bad certificate Full details of each release can be found below. What’s New? New in release 1.11.8 (2013-02-19) Security fixes S8006446, CVE-2013-1486: Restrict MBeanServer access S8006777, CVE-2013-0169: Improve TLS handling of invalid messages S8007688: Blacklist known bad certificate Backports S7123519: problems with certification path S8007393: Possible race condition after JDK-6664509 S8007611: logging behavior in applet changed Bug fixes PR1319: Support GIF lib v5. New in release 1.12.3 (2013-02-19) Security fixes S8006446, CVE-2013-1486: Restrict MBeanServer access S8006777, CVE-2013-0169: Improve TLS handling of invalid messages S8007688: Blacklist known bad certificate Backports S8007393: Possible race condition after JDK-6664509 S8007611: logging behavior in applet changed Bug fixes PR1319: Support GIF lib v5. The tarballs can be downloaded from: http://icedtea.classpath.org/download/source/icedtea6-1.11.8.tar.gz (sig) http://icedtea.classpath.org/download/source/icedtea6-1.12.3.tar.gz (sig) SHA256 checksums: 62620b5544d5e1df7508d7c777fb78532c75eec43b99c8c7d1a3c84f352c1ea3 icedtea6-1.11.8.tar.gz db9dc14fa537fb22616fcd9e5b80758aa7baa66e0b6f8adfe3d5e80414574b4c icedtea6-1.12.3.tar.gz The tarballs are accompanied by digital signatures available at the above ‘sig’ link. This is produced using my public key. See details below. PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 The following people helped with these releases: Severin Gehwolf (production of reproducer for 8006777) Andrew John Hughes (application of security fixes & backports, creation & testing of bug fixes, reproducer testing, release management) We would also like to thank the bug reporters and testers! To get started: $ tar xzf icedtea-${version}.tar.gz $ cd icedtea-${version} where ${version} is the version you’ve downloaded. Full build requirements and instructions are in INSTALL: $ ./configure [--enable-zero --enable-pulse-java --enable-systemtap ...] $ make Happy hacking! [Less]

Lot's of changes in just a week. The most interesting one being that ikvmc and the runtime now work together to project all the classes that were in the original jars compiled by ikvmc are now visible in the same (virtual) jars at ... [More] runtime. To avoid making the generated assemblies much bigger, this is implemented by having ikvmc generate a compressed file called --ikvm-classes--/ in the resources jar that contains the names of the classes compiled from this jar. This typically adds about 0.5% size overhead. At runtime when that jar is read in by java.util.zip.ZipFile it expands the list of class names to create virtual ZipEntries. Only when a virtual class resource is accessed is the class stub generated. Changes: Fixed ikvmc to give a proper error message if it fails to write to the output file. If a class can't be statically compiled due to a missing base class/interface, include it as a resource. Modified the assembly class loader to try to load classes from resources. Made dynamic binding to unloadable types the default (for ikvmc). Added -static option to ikvmc to disable dynamic binding. Unified all ikvmc filename validation. Implemented StandardGlyphVector.getGlyphOutline(). Bug fix. When looking for a method to override we should handle internal access methods. Fixed some runtime memory model issues (for non-x86 architectures). Bug fix. Custom attribute annotation should skip indexer properties. Bug fix. The available() method of the InputStream returned by ZipFile.getInputStream() was based on ZipEntry passed in, instead of the actual one. Fixed ikvmc to suppress "class not found" warning for a classes that fails to compile for any reason (because we've already given a warning about it). Bug fix. Don't look for main method in excluded classes. Unified the handling of resources and classes in ikvmc. Include all uncompilable .class files (from jars) into the resource jars. Project stub classes into the jar the classes originated from. Fixed ikvmc to prefer the last jar entry if there are duplicate entries. This mirrors the behavior of Java and dynamic mode. Fixed ikvmc to compare extensions case sensitive to find .class files. Fixed ikvmc to use the jar entry name, instead of the class name to load classes. Removed exclude.lst left over from ancient times. Removed META-INF/mailcap.default and META-INF/mimetypes.default resources that are no longer in resources.jar. Changed ikvmc -recurse: option to give a fatal error if it matches no files. Binaries available here: ikvmbin-7.3.4796.zip [Less]