GNU Classpath

Putting together the list of JavaOne talks I'm interested in attending, I noticed there is a virtual mini-track on annotation processing and related technology this year, with a combination of bofs, sessions, and a hands-on-lab: Monday ... [More] Multidevice Content Display and a Smart Use of Annotation Processing, Dimitri BAELI and Gilles Di Guglielmo Tuesday Advanced Annotation Processing with JSR 269, Jaroslav Tulach Build Your Own Type System for Fun and Profit, Werner Dietl and Michael Ernst Wednesday Annotations and Annotation Processing: What’s New in JDK 8?, Joel Borggrén-Franck Thursday Hack into Your Compiler!, Jaroslav Tulach Writing Annotation Processors to Aid Your Development Process, Ian Robertson As the lead engineer on bot apt (rest in peace) in JDK 5 and JSR 269 in JDK 6, I'd be heartened to see greater adoption and use of annotation processing by Java developers. [Less]

I have posted a preview of an experimental new utility to detect issues in javadoc comments. For more details, see my announcement to the compiler-dev mailing list.

System.Reflection.Emit is a great .NET feature, especially if you consider that it shipped as part of .NET 1.0, but the design of System.Reflection.Emit leaves something to be desired. One of the crazy features ... [More] is ConstructorBuilder. On the System.Reflection side, ConstructorInfo isn't all that helpful, but it is not as actively harmful as ConstructorBuilder. The reason for this is that ConstructorInfo and MethodInfo both extend MethodBase, so most common APIs are available through MethodBase. ConstructorBuilder and MethodBuilder share no common Builder base class (because they extend ConstructorInfo and MethodInfo), this causes a lot of code duplication and type testing/downcasting. A long time ago I found out that you can mostly avoid ConstructorBuilder, since it is possible to use TypeBuilder.DefineMethod() to define constructors. Recently I finally got around to taking advantage of this and completely removing ConstructorBuiler from the IKVM.NET runtime and compiler. The thing that pushed me over the edge was this experiment. In .NET 2.0 there is no ConstructorBuilder equivalent to MethodBuilder.CreateMethodBody(). So if I'm ever going to experiment with method level JIT it is nice to be able to use this more efficient method of installing the stub. There is one problem with using MethodBuilder for constructors. If you define a custom attribute and want to apply that custom attribute while it is still unbaked, you need a ConstructorBuilder for the custom attribute constructor, because CustomAttributeBuilder requires it. Luckily, in dynamic mode IKVM doesn't need to do this and in static mode I use IKVM.Reflection so I added MethodInfo.__AsConstructorInfo() to wrap the MethodInfo in a ConstructorInfo. I considered adding MethodInfo support to CustomAttributeBuilder, but that turned out to be much more complicated, so I went with the easy approach of reusing the existing wrapping strategy. The result of this refactoring is the removal of a bunch of duplicate code and a lot of downcasting. It also saves a small bit of memory, because the ConstructorBuilder wrappers are not needed anymore. [Less]

I'm pleased to announce the OpenJDK bug database migration project has reached a significant milestone: the JDK has switched from the legacy Sun "bugtraq" system to a new internal JIRA instance as the system of record for our bug tracking. This ... [More] completes the initial phase of the previously described plan of getting OpenJDK onto an externally visible and writable bug tracker. The identities contained in the current system include recognized OpenJDK contributors. The bug migration effort to date has been sizable in multiple dimensions. There are around 140,000 distinct issues imported into the JDK project of the JIRA instance, nearly 165,000 if backport issues to track multiple-release information are included. Separately, the Code Tools OpenJDK project has its own JIRA project populated with several thousands existing bugs. Once the OpenJDK JIRA instance is externalized, approved OpenJDK projects will be able to request the creation of a JIRA project for issue tracking. There are many differences in the schema used to model bugs between the legacy bug system and the schema for the new JIRA projects. We've favored simplifications to the existing system where possible and, after much discussion, we've settled on five main states for the OpenJDK JIRA projects: New Open In progress Resolved Closed The Open and In-progress states can have a substate Understanding field set to track whether the issues has its "Cause Known" or "Fix understood". In the closed state, a Verification field can indicate whether a fix has been verified, unverified, or if the fix has failed. At the moment, there will be very little externally visible difference between JIRA for OpenJDK and the legacy system it replaces. One difference is that bug numbers for newly filed issues in the JIRA JDK project will be 8000000 and above. If you are working with JDK Hg repositories, update any local copies of jcheck to the latest version which recognizes this expanded bug range. (The bug numbers of existing issues have been preserved on the import into JIRA). Relatively soon, we plan for the pages published on bugs.sun.com to be generated from information in JIRA rather than in the legacy system. When this occurs, there will be some differences in the page display and the terminology used will be revised to reflect JIRA usage, such as referring to the "component/subcomponent" of an issue rather than its "category". The exact timing of this transition will be announced when it is known. We don't currently have a firm timeline for externalization of the JIRA system. Updates will be provided as they become available. However, that is unlikely to happen before JavaOne next week! [Less]

The 0.46 version is the last version based on Java 6 and as mentioned previously would be supported longer than a typical release. Based on user feedback I decided to post an update that fixes a number of bugs that have been found ... [More] since the previous release. Changes (relative to 0.46 Update 1): Updated version to 0.46.0.3. Bug fix. java.lang.Package was not populated from manifest for ikvmc compiled assemblies. Bug fix. When writing a direct ByteBuffer to a non-blocking socket and the write fails because there is no kernel buffer available, we should not advance the ByteBuffer position. Bug fix. When adding certificates to virtual cacerts file make sure that the aliases are unique. Bug fix. If a finally/fault handler contains reachable code before the handler's start index, the handler should branch to the handler start index. Bug fix. After emitting a finally/fault handler block, we should emit the block leave stubs (even though you can't leave the block, they also emit the backward branch stubs). Bug fix. If a Java class extends a remapped .NET type (cli.System.Object or cli.System.Exception), we should correctly report the base class. Bug fix. If we encounter a jsr or ret instruction, we should throw a VerifyError (instead of NotImplementedException). Bug fix. If an exception block ends with an astore, we need to propagate the local variable type after the astore to the exception handler. Disable AppDomain.ProcessExit hook to run shutdown hooks when running on Mono to workaround https://bugzilla.xamarin.com/show_bug.cgi?id=5650 Bug fix. Custom attribute properties that don't have a public getter and setter should not be exposed as annotation properties. Bug fix. Non-public property getter/setter methods should be ignored when we create properties to hide properties inherited from shadow types. This fixes a build break with .NET 4.5 beta which introduces a protected setter for Exception.HResult. Bug fix. The $Method inner class for delegates should also be loadable for generic delegates. Thanks to Michael Bayne for reporting this. Bug fix. When constructing a generic class loader we can't use GetWrapperFromType() on the type arguments, because they might refer to a subtype that is currently being loaded. Replaced non-ascii character (micro) with ascii 'u' in Win32PrintService.java. IKVM.Reflection: Bug fix. Resource Directory Entries must be sorted and names are case-insensitive. Binaries available here: ikvmbin-0.46.0.3.zip Sources: ikvmsrc-0.46.0.3.zip, openjdk6-b22-stripped.zip [Less]

I recently proposed to defer Project Jigsaw from Java 8 to Java 9. Feedback on the proposal was about evenly divided as to whether Java 8 should be delayed for Jigsaw, Jigsaw should be deferred to Java 9, or some other, usually less-realistic, option ... [More] should be taken. The ultimate decision rested, of course, with the Java SE 8 (JSR 337) Expert Group. After due consideration, a strong majority of the EG agreed to my proposal. In light of this decision we can still make progress in Java 8 toward the convergence of the higher-end Java ME Platforms with Java SE. I previously suggested that we consider defining a small number of Profiles which would allow compact configurations of the SE Platform to be built and deployed. JEP 161 lays out a specific initial proposal for such Profiles. There is also much useful work to be done in Java 8 toward the fully-modular platform in Java 9. Alan Bateman has submitted JEP 162, which proposes some changes in Java 8 to smooth the eventual transition to modules, to provide new tools to help developers prepare for modularity, and to deprecate and then, in Java 9, actually remove certain API elements that are a significant impediment to modularization. Thanks to everyone who responded to the proposal with comments and questions. As I wrote initially, deferring Jigsaw to a Java 9 release in 2015 is by no means a pleasant decision. It does, however, still appear to be the best available option, and it is now the plan of record. [Less]

In the 98th episode of the Java Spotlight podcast, we interviewed Cliff Click, CTO and Co-Founder of 0xdata on Benchmarking.As usual, you can grab just this episode or fetch the whole feed.

As Brian Goetz tweeted, the videos from this year's JVM Language Summit are now available in multiple formats, along with the slides used in the presentations.Enjoy!

The previous release candidate had a regression that caused custom attributes specified in the remap xml file not to be applied. This caused the build to fail on .NET 4.0. Changes (relative to rc 0): ... [More] Updated version to 7.2.4630.1 Fixed build number in CommonAssemblyInfo.cs.in. Fixed .NET 4.0 build issues. Fixed map.xml custom attribute application regression. Updated HOWTO. Binaries available here: ikvmbin-7.2.4630.1.zip Sources: ikvmsrc-7.2.4630.1.zip, openjdk-7u6-b24-stripped.zip [Less]

Not that I feel older, it's nice to turn 0x25 again ;) [1]Thanks to all who remembered and to all the friends that forgot :)[1] In fact, it was on 13th, but I didn't publish this article :)