GNU Classpath

I did quite some contributions to OpenJDK in the last years, and committed few patches, probably less than what I would have liked, but a reasonable number given the difficulty of contributing to OpenJDK, and in my case of those specific patches ... [More] , being quite above the average.Probably for this reason, because it's not something that happens every day, even when it's becoming somehow regular in his cadence, any time it happens to push another patch, fix another bug or do another non "trivial" contribution (not to take that word literally, there are no trivial contributions ever, really), it feels very special. It makes me shake a bit too, considering that this code runs everywhere in this planet (and sometimes outside!): those patches end up virtually in billions of devices, now and in the future, for generations.It makes me wonder if I should be rich because of this ;) but the reality is this simple, I am rich. Of a richness which is not about money, is about a very personal reward of contributing to something bigger, something useful. To share. It grows within us, and grows forming this aura that you can recognise in an instant.To get here, it has been a long journey, a journey that took the most part of the last ten years of my life, that made me meet incredible people, do things that are still useful to many; and that rewards me every time, even when sometimes, like it's normal to be, turns into a slight sense of frustration that always resolves very quickly into a great sense of achievement, as soon as things works out how they are supposed to. And be with me on this one, this journey I did so far is something that many people can do, there's nothing special in me.This year marks 10 years of Free Java, 7 of which with OpenJDK. We have seen this all, and we will speak about that at FOSDEM 2013. And we want your contribution, we want to hear from you, in your own words, the story of your journey into the OpenJDK land.Help us make this FOSDEM the best ever :) [Less]

The CLR's DEVPATH feature has always been broken and its brokeness varied over the years, but for my purposes it was a very useful feature. However with .NET .4.5 Microsoft decided to up the ante. If you have configured ... [More] your .NET 4.5 runtime as a "developer installation", ngen will fail to generate native images for framework assemblies. This means that after Windows Update services mscorlib.dll, no native images will be used anymore. Obviously you can work around this by editing the machine.config and re-running ngen, but that is a bit of a pain so decided to hack together a workaround. The basic idea is to have a DLL that gets injected into (nearly) every process and patches mscoree.dll to make CreateConfigStream read developer-machine.config instead of machine.config if the DEVPATH environment variable is set. The source and binaries are available here. Like the Microsoft DEVPATH code, this is untested so there is no warranty and use at your own risk. Bug reports are welcome of course. There is no installer and there are no installation instructions, because frankly, if you don't know how to install it you probably shouldn't be doing so anyway.. The overhead is fairly low. If you don't have DEVPATH set the DLL will immediately unload again. The file size is only 3KB and in memory it will only use a single 4KB page. [Less]

This week brought along new developer preview releases of the JDK and related projects. On the JDK 7 side, the Java™ Platform, Standard Edition 7 Update 12 Developer Preview Releases have been updated to 7u12 Build b05. On the JDK 8 side, as Mike ... [More] Duigou announced on the lambda-dev mailing list, A new promotion (b68) of preview binaries for OpenJDK Java 8 with lambda extensions is now available at http://jdk8.java.net/lambda/. Happy testing! [Less]

There is a new version of jtreg available. The primary new feature is support for tests that have been written for use with TestNG, the popular open source testing framework. TestNG is supported by a variety of tools and plugins, which means that it ... [More] is now possible to develop tests for OpenJDK using those tools, while still retaining the ability to have the tests be part of the OpenJDK test suite, and run with a single test harness, jtreg. jtreg can be downloaded from the OpenJDK jtreg page: http://openjdk.java.net/jtreg. TestNG support jtreg supports both single TestNG tests, which can be freely intermixed with other types of jtreg tests, and groups of TestNG tests. A single TestNG test class can be compiled and run by providing a test description using the new action tag: @run testng classname The test will be executed by using org.testng.TestNG. No main method is required. A group of TestNG tests organized in a standard package hierarchy can also be compiled and run by jtreg. Any such group must be identified by specifying the root directory of the package hierarchy. You can either do this in the top level TEST.ROOT file, or in a TEST.properties file in any subdirectory enclosing the group of tests. In either case, add a line to the file of the form: TestNG.dirs = dir ... Directories beginning with '/' are evaluated relative to the root directory of the test suite; otherwise they are evaluated relative to the directory containing the declaring file. In particular, note that you can simply use "TestNG.dirs = ." in a TEST.properties file in the root directory of the test group's package hierarchy. No additional test descriptions are necessary, but test descriptions containing information tags, such as @bug, @summary, etc are permitted. All the Java source files in the group will be compiled if necessary, before any of the tests in the group are run. The selected tests within the group will be run, one at a time, using org.testng.TestNG. Library classes The specification for the @library tag has been extended so that any paths beginning with '/' will be evaluated relative to the root directory of the test suite. In addition, some bugs have been fixed that prevented sharing the compiled versions of library classes between tests in different directories. Note: This has uncovered some issues in tests that use a combination of @build and @library tags, such that some tests may fail unexpectedly with ClassNotFoundException. The workaround for now is to ensure that library classes are listed before the test classes in any @build tags. To specify one or more library directories for a group of TestNG tests, add a line of the following form to the TEST.properties file in the root directory of the group's package hierarchy: lib.dirs = dir ... As before, directories beginning with '/' are evaluated relative to the root directory of the test suite; otherwise they are evaluated relative to the directory containing the declaring file. The libraries will be available to all classes in the group; you cannot specify different libraries for different tests within the group. Coming soon ... From this point on, jtreg development will be using the new jtreg repository in the OpenJDK code-tools project. There is a new email alias jtreg-dev at openjdk.java.net for discussions about jtreg development. The existing alias jtreg-use at openjdk.java.net will continue to be available for questions about using jtreg. For more information ... An updated version of the jtreg Tag Language Specification is being prepared, and will be made available when it is ready. In the meantime, you can find more information about the support for TestNG by executing the following command: $ jtreg -onlinehelp TestNG For more information on TestNG itself, visit testng.org. [Less]

Today we released Caciocavallo 1.3. The release announcement can be found here. However, what is the more important news is that after the release, I fixed Cacio-Web to work with the latest Cacio build and enabled it in the default build so it ... [More] doesn’t fall to the wayside again. On popular request I would like to summarize how to get Cacio-Web running. Note that this currently only works on Linux (patches to enable this on other platforms are welcome!) First of all, check out the source code (the cacio-web changes are not yet released): hg clone http://hg.openjdk.java.net/caciocavallo/ng/ caciocavallo Then build it (you need Maven!): cd caciocavallo mvn clean install And finally you should be able to run with with something like this: java -Dcacio.web.port=9091 -cp cacio-web/target/cacio-web-1.4-SNAPSHOT-jar-with-dependencies.jar:/home/rkennke/src/test/SwingSet2.jar net.java.openjdk.cacio.server.CacioServer The -Dcacio.web.port parameter specifies on which port should Cacio-Web listen. Notice that the classpath needs to include your application (SwingSet2.jar in this case). Then point your browser to a URL like this: http://localhost:9091/SessionInitializer?cls=SwingSet2 Where the parameter cls specifies the (fully qualified) name of the main class of the application to start. Please let me know if you run into any problems. [Less]

As some of you may know, Thermostat has had a custom Look And Feel, named Dolphin, for quite some time now.The LaF was designed to simulate the Adwaita theme in the default Fedora Gnome installationIt was a fun theme to write so far, and it's ... [More] probably more stable already than the GTK Look and Feel and looks very good. It can handle without troubles the SwingSet 3 (including animations), but it still has some way before becoming a fully fledged theme for the Java Platform.   With Thermostat approaching a 1.0 milestone (wow!) and given those considerations, the Thermostat hackers have decided to not ship this theme as default, but we also don't want to lose all this good work.So we decided to make Dolphin a separate project and develop outside Thermostat, perhaps introducing it back after 1.0 release, when it's more stable and useful.  I created an official repository for the project by cloning the latest development snapshot of the code (which is currently 0.5.0), on the IcedTea server: hg clone http://icedtea.classpath.org/hg/dolphin/ I also upgraded the release version to 0.5.1-SNAPSHOT and will keep from now on separate release updates from Thermostat.Of course, everyone can participate to this work, and is very welcomed to! I hope that we can bring together this great look and feel to the next century ;) [Less]

Time for another development snapshot. Changes: Do the "no serialization" check before calling Serialization.AddAutomagicSerialization() to avoid triggering the class initializer ... [More] (which will try to load SerializableAttribute, which is not available everywhere). Removed more ConstructorBuilder usage to fix regression (constructor custom attributes specified map.xml were not applied). Construct the System assembly name from the mscorlib name to support other runtimes. Removed dummy constructor from __Helper class. Removed remaining ConstructorBuilder usages. Removed unnecessary MethodBuilder casts. Removed permanent app.config files and changed build process to only generate them when doing a .NET 2.0 build. Bug fix. Transient field modifier should also be retained on literal fields. Bug fix. Field.getModifiers() should only return the relevant modifiers. Removed some O(n^2) operations to improve handling of class files with a large number of fields. Bug fix. Set AddressOfRawData in IMAGE_DEBUG_DIRECTORY. Bug fix. Class.forName("") should not throw System.ArgumentException. Bug fix. Off-by-one error in local ref index reusing. Fix for bug #3575555. Bug fix. Don't try to inject DynamicMethod in array types (applies to array.clone() method for MethodHandles). Bug fix. Abstract generic methods are not supported. Fix for #3579785. Bug fix. Interface mappings can be "incomplete". Fix for bug #3581564. Added (optional) support for building without System.Core.dll dependency. Bug fix. The local variable state at the end of an exception block (if the last instruction is a local variable store) needs to be merged into the exception handler state. Changed FileNotFoundException message in the case of an access denied to match the JDK message. JRuby depends on this. Renamed Adler32 "checksum" field to "adler", because JRuby depends on this. Bug fix. The static compiler cannot use a different way to encode erased array types than the runtime compiler (because otherwise the runtime can't override statically compiled methods). Fixed native library build to explicitly pass /MACHINE option to linker to avoid warning. Implemented StandardGlyphVector.performDefaultLayout() and setGlyphPosition(int, Point2D). Added missing SecuritySafeCritical attribute. Changed build infrastructure to support targetting .NET 4.0 on systems where 4.5 is installed. IKVM.Reflection: Bug fix. Ignore unknown metadata streams instead of throwing a BadImageFormatException. The CLR ignores these streams as well and some obfuscators add them. IKVM.Reflection: Added TypeInfo (from .NET 4.5). IKVM.Reflection: Implemented caching for TypeDefImpl.IsGenericTypeDefinition property. IKVM.Reflection: Added new .NET 4.5 TypeBuilder.DefineNestedType() overload. IKVM.Reflection: Added new .NET 4.5 API TypeBuilder.CreateTypeInfo(). IKVM.Reflection: Added new .NET 4.0 overload of TypeBuilder.DefineProperty(). IKVM.Reflection: Added new .NET 4.5 property AssemblyName.CultureName. IKVM.Reflection: When an assembly name has a duplicate key, throw FileLoadException like .NET 4.x does instead of COMException like .NET 2.0 does. IKVM.Reflection: Added new .NET 4.5 property MethodBase.MethodImplementationFlags. IKVM.Reflection: Added new .NET 4.5 properties CustomAttributeNamedArgument.IsField and CustomAttributeNamedArgument.MemberName. IKVM.Reflection: Added new .NET 4.5 properties EventInfo.AddMethod, EventInfo.RaiseMethod and EventInfo.RemoveMethod. IKVM.Reflection: Added new .NET 4.5 property ParameterInfo.HasDefaultValue. IKVM.Reflection: Added new .NET 4.5 properties PropertyInfo.GetMethod and PropertyInfo.SetMethod. IKVM.Reflection: Added Universe.DefineDynamicAssembly(AssemblyName, AssemblyBuilderAccess, IEnumerable ) that corresponds to new .NET 4.5 API AssemblyBuilder.DefineDynamicAssembly(...). IKVM.Reflection: Added new .NET 4.5 method EnumBuilder.CreateTypeInfo(). IKVM.Reflection: Added new .NET 4.0 method GetCustomAttributesData() to Assembly, MemberInfo, Module and ParameterInfo. IKVM.Reflection: Added new .NET 4.5 property CustomAttributes to Assembly, MemberInfo, Module and ParameterInfo. IKVM.Reflection: Added new .NET 4.5 property Type.GenericTypeArguments. IKVM.Reflection: Added new .NET 4.0 methods Type.GetEnumNames(), Type.GetEnumName() and Type.IsEnumDefined(). IKVM.Reflection: Added new .NET 4.5 properties Assembly.ExportedTypes and Assembly.DefinedTypes. IKVM.Reflection: Added new .NET 4.5 property Assembly.Modules. IKVM.Reflection: Moved local var signature token creation to a more logical location. IKVM.Reflection: Added new .NET 4.5 methods ConstructorBuilder.SetMethodBody() and MethodBuilder.SetMethodBody(). Note that the implementation is currently completely untested. IKVM.Reflection: Added (old) method MethodBuilder.CreateMethodBody() that is now trivial to implement. IKVM.Reflection: Added new .NET 4.0 property Assembly.IsDynamic. IKVM.Reflection: Added (old) API Module.GetSignerCertificate(). IKVM.Reflection: Bug fix. While reading the Cecil source I realized that array bounds are signed. IKVM.Reflection: Stop relying on System.Reflection.AssemblyName to compute public key token from public key. IKVM.Reflection: Small optimization to table record allocation. Thanks to Marek for the pointer. IKVM.Reflection: Implemented LocalVariableInfo.ToString(). IKVM.Reflection: Bug fix. ModuleReader.ResolveMember() should support types. Thanks to Jb Evain for finding this. IKVM.Reflection: Bug fix. LocalBuilder should extend LocalVariableInfo. IKVM.Reflection: Made AssemblyBuilder.__AssemblyFlags a read/write property and marked __SetAssemblyFlags() obsolete. IKVM.Reflection: Bug fix. Changed AssemblyName.ProcessorArchitecture to match (weird) .NET behavior. When reading the property it returns the architecture of the PE file, not the field from the AssemblyDef record. IKVM.Reflection: Throw InvalidOperationException when MethodBuilder.DefineGenericParameters() is called a second time. IKVM.Reflection: Added UniverseOptions.DontProvideAutomaticDefaultConstructor to disable the "helpful" creation of a default constructor. IKVM.Reflection: Fixed ExportedType resolver to support types defined in another module in this assembly. IKVM.Reflection: Added the Assembly.ModuleResolve event. IKVM.Reflection: If missing member resolution is enabled, automatically create missing modules as needed. IKVM.Reflection: Simplified LazyForwardType resolution to reuse ResolveExportedType() and thus always set the metadata token for forwarded missing types. IKVM.Reflection: Added Type.__IsTypeForwarder property to let mcs distinguish between "normal" missing types and forwarded missing types. IKVM.Reflection: When calling MethodBuilder.DefineParameter() multiple times for the same parameter, we would (sometimes) not store the ParameterBuilder and this would cause the resulting PE file to be corrupt. Now we store the duplicate Param records like SRE does. IKVM.Reflection: Added UniverseOptions.MetadataOnly. IKVM.Reflection: Made user string heap loading lazy. IKVM.Reflection: Bug fix. If SizeOfOptionalHeader is greater than the number of bytes we read from the optional header, we should skip the additional bytes. If it is less, the image is invalid. Thanks to Jb Evain. Binaries available here: ikvmbin-7.3.4728.zip [Less]

I've released IKVM.NET 7.2 to SourceForge and NuGet. The binaries are identical to the ones in release candidate 5. Release Notes This document lists the improvements, known issues and ... [More] incompatibilities. What's New (relative to IKVM.NET 7.1): Integrated OpenJDK 7 u6 b24. Improved java.util.concurrent performance. Removed org.omg.PortableInterceptor.UNKNOWN class, that is not part of [Open]JDK rt.jar. Added ZipFile constructor that was added in Java 7. Add support for running with headless awt toolkit. Changed ikvmc to apply custom attribute annotations on annotation types to the corresponding custom attribute that is generated (and allow AttributeUsageAttribute to override the default AttributeUsageAttribute generated from the @Target annotation). Added app.config files for executables to allow them to run on .NET 4.5 on Windows 8 without triggering the .NET 3.5 auto download. Added (optional) support for building without System.Core.dll dependency. Disabled AppDomain.ProcessExit hook to run shutdown hooks when running on Mono to workaround https://bugzilla.xamarin.com/show_bug.cgi?id=5650. Several verifier fixes. Several metadata reflection fixes. Fixed two try/finally block code gen bugs. Various other minor fixes. IKVM.Reflection: Many minor bug fixes and improvements. IKVM.Reflection: Added most new .NET 4.5 APIs. IKVM.Reflection: Added experimental support for generating Windows Runtime (.winmd) assemblies. IKVM.Reflection: Added missing DefineResource() APIs to ModuleBuilder and AssemblyBuilder. IKVM.Reflection: Added co-/contra-variance support to Type.IsAssignableFrom(). IKVM.Reflection: Added support for using the .NETCore v4.5 aka Metro profile mscorlib.dll. IKVM.Reflection: Added UniverseOptions.DisablePseudoCustomAttributeRetrieval to disable returning pseudo custom attributes. IKVM.Reflection: Bug fix. Ignore unknown metadata streams. IKVM.Reflection: Bug fix. Set AddressOfRawData in IMAGE_DEBUG_DIRECTORY. Runtime Code unloading (aka class GC) is not supported. In Java static initializers can deadlock, on .NET some threads can see uninitialized state in cases where deadlock would occur on the JVM. JNI   Only supported in the default AppDomain. Only the JNICALL calling convention is supported! (On Windows, HotSpot appears to also support the cdecl calling convention). Cannot call string contructors on already existing string instances A few limitations in Invocation API support   The Invocation API is only supported when running on .NET. JNI_CreateJavaVM: init options "-verbose[:class|:gc|:jni]", "vfprintf", "exit" and "abort" are not implemented. The JDK 1.1 version of JavaVMInitArgs isn't supported. JNI_GetDefaultJavaVMInitArgs not implemented JNI_GetCreatedJavaVMs only returns the JavaVM if the VM was started through JNI or a JNI call that retrieves the JavaVM has already occurred. DestroyJVM is only partially implemented (it waits until there are no more non-daemon Java threads and then returns JNI_ERR). DetachCurrentThread doesn't release monitors held by the thread. Native libraries are never unloaded (because code unloading is not supported). The JVM allows any reference type to be passed where an interface reference is expected (and to store any reference type in an interface reference type field), on IKVM this results in an IncompatibleClassChangeError. monitorenter / monitorexit cannot be used on unitialized this reference. Floating point is not fully spec compliant. A method returning a boolean that returns an integer other than 0 or 1 behaves differently (this also applies to byte/char/short and for method parameters). Synchronized blocks are not async exception safe. Ghost arrays don't throw ArrayStoreException when you store an object that doesn't implement the ghost interface. Class loading is more eager than on the reference VM. Interface implementation methods are never really final (interface can be reimplemented by .NET subclasses). JSR-133 finalization spec change is not fully implemented. The JSR-133 changes dictate that an object should not be finalized unless the Object constructor has run successfully, but this isn't implemented. Strict class-file checking is not implemented. If a class with a finalizer and static initializer allocates instances of itself in the static initializer and the static initializer subsequently fails, the .NET runtime may abort the application when trying to finalize the objects. Static Compiler (ikvmc) Some subtle differences with ikvmc compiled code for public members inherited from non-public base classes (so called "access stubs"). Because the access stub lives in a derived class, when accessing a member in a base class, the derived cctor will be run whereas java (and ikvm) only runs the base cctor. Try blocks around base class ctor invocation result in unverifiable code (no known compilers produce this type of code). Try/catch blocks before base class ctor invocation result in unverifiable code (this actually happens with the Eclipse compiler when you pass a class literal to the base class ctor and compile with -target 1.4). Only code compiled together during a single compilation fully obeys the JLS binary compatibility rules. Class Library Most class library code is based on OpenJDK 7u6 build 24. Below is a list of divergences and IKVM.NET specific implementation notes. com.sun.security.auth.module        Only implemented on Windows. java.applet Not implemented. java.awt Partial System.Windows.Forms based back-end. Not supported. java.io.Console Not implemented. java.lang.instrument Not implemented. java.lang.management Limited implementation. java.net SCTP and SDP not implemented. java.net.ProxySelector Getting the default system proxy for a URL is not implemented. java.nio.file Most optional features (e.g. ACLs) are not implemented. java.text.Bidi Not supported. java.util.zip Partially based on GNU Classpath implementation. javax.crypto ECC is not implemented. javax.imageio.plugins.jpeg Partial implementation. JPEGs can be read and written and there is limited metadata support. javax.management Limited implementation. javax.print There is a Win32 specific printing implementation. Not supported. javax.script ECMAScript implementation is not included. javax.smartcardio Not implemented. javax.sound Not implemented. javax.swing Not supported. javax.tools Not supported. org.ietfs.jgss Not implemented. sun.jdbc.odbc Implementation based on .NET ODBC managed provider. sun.net.www.content.audio Audio content handlers not implemented. sun.net.www.content.image Not supported. The entire public API is available, so "Not implemented." for javax.smartcardio, for example, means that the API is there but there is no back-end to provide the actual smartcard communication support. "Not supported." means that the code is there and probably works at least somewhat, but that I'm less likely to fix bugs reported in these areas, but patches are welcome, of course. Specific API notes: java.lang.Thread.stop(Throwable t) doesn't support throwing arbitrary exceptions on other threads (only java.lang.ThreadDeath). java.lang.Thread.holdsLock(Object o) causes a spurious notify on the object (this is allowed by the J2SE 5.0 spec). java.lang.String.intern() strings are never garbage collected. Weak/soft references and reference queues are inefficient and do not fully implement the required semantics. java.lang.ref.SoftReference: Soft references are not guaranteed to be cleared before an OutOfMemoryError is thrown. Threads started outside of Java aren't "visible" (e.g. in ThreadGroup.enumerate()) until they first call Thread.currentThread(). java.lang.Thread.getState() returns WAITING or TIMED_WAITING instead of BLOCKING when we're inside Object.wait() and blocking to re-acquire the monitor. java.nio.channel.FileChannel.lock() shared locks are only supported on Windows NT derived operating systems. java.lang.SecurityManager: Deprecated methods not implemented: classDepth(String), inClass(String), classLoaderDepth(), currentLoadedClass(), currentClassLoader(), inClassLoader() Supported Platforms This release has been tested on the following CLI implementations / platforms: CLI Implementation       Architecture      Operating System .NET 2.0 SP2 x86 Windows 8 .NET 2.0 SP2 x64 Windows 8 .NET 4.5 x86 Windows 8 .NET 4.5 x64 Windows 8 [Less]

Apologies for the ridiculous delay. I've been busy. This is the final release candidate. Changes (relative to rc 4): Updated version to 7.2.4630.5 Bug fix. The static ... [More] compiler cannot use a different way to encode erased array types than the runtime compiler (because otherwise the runtime can't override statically compiled methods). Added missing SecuritySafeCritical attribute. Binaries available here: ikvmbin-7.2.4630.5.zip Sources: ikvmsrc-7.2.4630.5.zip, openjdk-7u6-b24-stripped.zip [Less]

So, finally, after some back and forth, the Shark fixes landed in hotspot-comp (thanks Twisti for reviewing and pushing me). It took a little while to sort out the new atomic operations in LLVM. If you want to play with it, you first need LLVM 3.2 ... [More] (not the latest 3.1 release!): svn co http://llvm.org/svn/llvm-project/llvm/branches/release_32/ llvm-3.2 cd llvm-3.2 ./configure && make && make install Then you need to check out hotspot-comp: cd .. hg clone http://hg.openjdk.java.net/hsx/hotspot-comp/ cd hotspot-comp sh get-source.sh Finally, I recommend you use my build script for Shark: place it in the toplevel directoy of hotspot-comp and modify all the env variables to your needs. Most importantly, change LLVM_CONFIG to point to your $LLVM_INSTALL_DIR/bin/llvm-config. Enjoy the Shark! [Less]