# Tuesday, 19 July 2005
Assembly File Size

Yesterday's release candidate has a much smaller IKVM.GNU.Classpath.dll than the previous release candidate. As I noted this is due to some optimizations in the metadata. Let's look at the file size of IKVM.GNU.Classpath.dll over time:

Date IKVM Version File Size (bytes)
2004-06-28 0.8.0.0 3,239,936
2005-01-10 0.10.0.1 7,348,224
2005-03-02 0.12.0.0 7,409,664
2005-05-07 0.14.0.1 7,483,392
2005-07-01 0.16.0.0 7,266,304
2005-07-18 0.18.0.0 6,782,976


For reference, here's a graph that shows the growth of GNU Classpath:

The big jump in size between 0.8 and 0.10 is mostly due to three reasons: 1) Long period between releases, 2) Huge growth in GNU Classpath, 3) 0.10 for the first time includes source file names and line number tables (to be able to show source files and line numbers in stack traces).

The size reduction in 0.16 was due to a more efficient format for the line number tables. After making this optimization in 0.16, I wanted to investigate exactly what makes up the size of IKVM.GNU.Classpath.dll, but I couldn't find any tools to analyse a managed PE file based on this criterion. So I opened the ECMA specification and hacked together some code. Here's what I found:

First, let's start with the size of the Java classes and resources that IKVM.GNU.Classpath.dll consists of (to have some reference):

 

bytes

Classes 9,694,349
Resources 2,016,851
Total 11,711,200
Zipped 5,843,852


So, compared with the uncompressed size of the classes and resources, the size of IKVM.GNU.Classpath.dll isn't too bad at all.

Here's a breakdown of the parts of the PE file structure:

  bytes
PE Headers/overhead 4,096
.text section 6,770,688
.rsrc section 4,096
.reloc section 4,096


Not very interesting, except maybe that there is a .reloc section that I don't understand the need for, since there's only managed code in this module.

A little more interesting is a breakdown of the .text section:

  bytes
Unknown 8
CLI Header 72
Code + resources 3,651,236
Managed metadata 3,116,284
Filler (alignment) 3,088


Here's a breakdown of the managed metadata:

  bytes
Metadata Header 32
#~ header 12
#Strings header 20
#US header 12
#GUID header 16
#Blob header 16
#~ stream 1,704,068
String heap 356,048
Userstring heap 327,652
GUID heap 16
Blob heap 728,392


And finally, a breakdown of the #~ stream:

  bytes
Header 112
Module table 12
TypeRef table 2,210
TypeDef table 79,146
Field table 148,620
Method table 669,870
Param table 220,448
InterfaceImpl table 9,472
MemberRef table 5,424
Constant table 47,370
CustomAttribute table 488,676
StandAloneSig table 24,216
PropertyMap table 8
Property table 90
MethodSemantics table 66
MethodImpl table 600
ModuleRef table 8
TypeSpec table 400
ImplMap table 108
Assembly table 28
AssemblyRef table 112
ManifestResource table 3,654
NestedClass table 3,416
Filler (alignment) 2


For those unfamiliar with the CLI metadata specification, these tables contain fixed length records and the fields in the records typically contain flags, indexes into other tables or pointers into a string, userstring or blob heap, or an offset into the Code + resources part of the .text section.

From the above table It should be obvious that the custom attributes contribute a significant part of the file size (and remember, this is the 0.18 version of IKVM.GNU.Classpath.dll that has already been optimized quite a bit).

In my analysis tool I built specific code to look at the sizes of the custom attributes and here's the report it generated:

Custom Attributes
-----------------
Total Blob Bytes:  527670
Total Table Bytes: 488676

Type         Constructor
----         -----------
0x0000000B   IKVM.Attributes.SourceFileAttribute::.ctor(20 01 01 0E ( ...))
0x00000013   IKVM.Attributes.JavaModuleAttribute::.ctor(20 00 01 ( ..))
0x0000001B   IKVM.Attributes.RemappedTypeAttribute::.ctor(20 01 01 12 15 ( ....))
0x00000023   IKVM.Attributes.ModifiersAttribute::.ctor(20 01 01 11 1D ( ....))
0x0000002B   IKVM.Attributes.GhostInterfaceAttribute::.ctor(20 00 01 ( ..))
0x00000033   IKVM.Attributes.HideFromJavaAttribute::.ctor(20 00 01 ( ..))
0x0000003B   IKVM.Attributes.ImplementsAttribute::.ctor(20 01 01 1D 0E ( ....))
0x00000043   System.ThreadStaticAttribute::.ctor(20 00 01 ( ..))
0x0000004B   System.ObsoleteAttribute::.ctor(20 00 01 ( ..))
0x00000053   IKVM.Attributes.InnerClassAttribute::.ctor(20 02 01 0E 11 1D ( .....))
0x0000005B   IKVM.Attributes.ExceptionIsUnsafeForMappingAttribute::.ctor(20 00 01 ( ..))
0x00000063   System.ComponentModel.EditorBrowsableAttribute::.ctor(20 01 01 11 80 FD ( .....))
0x0000006B   IKVM.Attributes.NameSigAttribute::.ctor(20 02 01 0E 0E ( ....))
0x00000073   IKVM.Attributes.ThrowsAttribute::.ctor(20 01 01 1D 0E ( ....))
0x0000007B   IKVM.Attributes.RemappedInterfaceMethodAttribute::.ctor(20 02 01 0E 0E ( ....))
0x0000010B   IKVM.Attributes.LineNumberTableAttribute::.ctor(20 01 01 1D 05 ( ....))
0x0000023B   IKVM.Attributes.MirandaMethodAttribute::.ctor(20 00 01 ( ..))
0x000008A3   IKVM.Attributes.ConstantValueAttribute::.ctor(20 01 01 08 ( ...))
0x00000DFB   System.Diagnostics.DebuggableAttribute::.ctor(20 02 01 02 02 ( ....))
0x00000E03   IKVM.Attributes.RemappedClassAttribute::.ctor(20 02 01 0E 12 15 ( .....))
0x00000E0B   System.Reflection.AssemblyCompanyAttribute::.ctor(20 01 01 0E ( ...))
0x00000E13   System.Reflection.AssemblyCopyrightAttribute::.ctor(20 01 01 0E ( ...))
0x00000E1B   System.Reflection.AssemblyTitleAttribute::.ctor(20 01 01 0E ( ...))
0x00000E23   System.Reflection.AssemblyProductAttribute::.ctor(20 01 01 0E ( ...))

Type            Count  Blob Bytes  Total Bytes
----            -----  ----------  -----------
0x0000000B        917        7522        18526
0x00000013          1           5           17
0x0000001B          4         404          452
0x00000023        390         140         4820
0x0000002B          3           0           36
0x00000033        593           0         7116
0x0000003B       1785       33923        55343
0x00000043          6           0           72
0x0000004B        389           0         4668
0x00000053        776        3689        13001
0x0000005B         42           1          505
0x00000063         68           9          825
0x0000006B         89        2982         4050
0x00000073       5657       22069        89953
0x0000007B          1          25           37
0x0000010B      29864      456058       814426
0x0000023B        128           0         1536
0x000008A3          1           9           21
0x00000DFB          1           7           19
0x00000E03          4         479          527
0x00000E0B          1          21           33
0x00000E13          1         272          284
0x00000E1B          1          41           53
0x00000E23          1          14           26

For comparison, here's the same table for the 0.16 version:

Custom Attributes
-----------------
Total Blob Bytes:  638882
Total Table Bytes: 631896

Type         Constructor
----         -----------
0x0000000B   IKVM.Attributes.JavaModuleAttribute::.ctor(20 00 01 ( ..))
0x00000013   IKVM.Attributes.SourceFileAttribute::.ctor(20 01 01 0E ( ...))
0x0000001B   IKVM.Attributes.RemappedTypeAttribute::.ctor(20 01 01 12 15 ( ....))
0x00000023   IKVM.Attributes.ModifiersAttribute::.ctor(20 01 01 11 1D ( ....))
0x0000002B   IKVM.Attributes.GhostInterfaceAttribute::.ctor(20 00 01 ( ..))
0x00000033   IKVM.Attributes.HideFromJavaAttribute::.ctor(20 00 01 ( ..))
0x0000003B   IKVM.Attributes.ImplementsAttribute::.ctor(20 01 01 1D 0E ( ....))
0x00000043   System.ThreadStaticAttribute::.ctor(20 00 01 ( ..))
0x0000004B   System.ObsoleteAttribute::.ctor(20 00 01 ( ..))
0x00000053   IKVM.Attributes.InnerClassAttribute::.ctor(20 04 01 0E 0E 0E 11 1D ( .......))
0x0000005B   IKVM.Attributes.ExceptionIsUnsafeForMappingAttribute::.ctor(20 00 01 ( ..))
0x00000063   System.ComponentModel.EditorBrowsableAttribute::.ctor(20 01 01 11 80 FD ( .....))
0x0000006B   IKVM.Attributes.NameSigAttribute::.ctor(20 02 01 0E 0E ( ....))
0x00000073   IKVM.Attributes.ThrowsAttribute::.ctor(20 01 01 1D 0E ( ....))
0x0000007B   IKVM.Attributes.RemappedInterfaceMethodAttribute::.ctor(20 02 01 0E 0E ( ....))
0x0000010B   IKVM.Attributes.LineNumberTableAttribute::.ctor(20 01 01 1D 05 ( ....))
0x00000233   IKVM.Attributes.MirandaMethodAttribute::.ctor(20 00 01 ( ..))
0x000008A3   IKVM.Attributes.ConstantValueAttribute::.ctor(20 01 01 08 ( ...))
0x00000DFB   System.Diagnostics.DebuggableAttribute::.ctor(20 02 01 02 02 ( ....))
0x00000E03   IKVM.Attributes.RemappedClassAttribute::.ctor(20 02 01 0E 12 15 ( .....))
0x00000E0B   System.Reflection.AssemblyCompanyAttribute::.ctor(20 01 01 0E ( ...))
0x00000E13   System.Reflection.AssemblyCopyrightAttribute::.ctor(20 01 01 0E ( ...))
0x00000E1B   System.Reflection.AssemblyTitleAttribute::.ctor(20 01 01 0E ( ...))
0x00000E23   System.Reflection.AssemblyProductAttribute::.ctor(20 01 01 0E ( ...))

Type            Count  Blob Bytes  Total Bytes
----            -----  ----------  -----------
0x0000000B          1           5           17
0x00000013       4216       82327       132919
0x0000001B          4         404          452
0x00000023       5829         224        70172
0x0000002B          3           0           36
0x00000033       3209           0        38508
0x0000003B       1775       33852        55152
0x00000043          6           0           72
0x0000004B        389           0         4668
0x00000053        766       78090        87282
0x0000005B         42           1          505
0x00000063         68           9          825
0x0000006B         89        2982         4050
0x00000073       5650       22069        89869
0x0000007B          1          25           37
0x0000010B      30469      418060       783688
0x00000233        131           0         1572
0x000008A3          1           0           12
0x00000DFB          1           7           19
0x00000E03          4         479          527
0x00000E0B          1          21           33
0x00000E13          1         272          284
0x00000E1B          1          41           53
0x00000E23          1          14           26

One notable item is that the line number tables have grown in 0.18, this is due to the fact that 0.18 has been compiled with the Eclipse Java Compiler whereas 0.16 was compiled with Jikes. For some reason, the Eclipse compiler generates larger line number tables. I haven't investigated this yet.

The new -strictfinalfieldsemantics ikvmc option was the direct result of studying the impact of metadata on the file size. Without this option, public and protected final fields are converted into readonly properties and the field requires and additional attribute. With the option, final fields are converted into initonly fields, which has the same semantics under a strict interpretation of the 1.5 VM specification. This option alone saves 155,648 bytes.

Looking at the custom attribute sizes, there appears to be more room for improvement. In particular, the ThrowsAttribute, InnerClassAttribute and ImplementsAttribute can benefit from using tokens instead of encoding the class names in the constructor blob, but the required APIs to resolve tokens are new in Whidbey, so for the time being that isn't an option.

Another long term improvement would be to include the line number tables in the method IL (or after the IL), to save on the records in the custom attribute table (which contribute a very significant 358,368 bytes). This would probably be possible in Whidbey by using MethodBody.GetILAsByteArray(), but it would be nicer if the ECMA spec would be extended to support this directly (it would also remove the need for the ridiculously large PDB files simply to get line numbers in stack traces for other .NET applications).

Tuesday, 19 July 2005 11:06:52 (W. Europe Daylight Time, UTC+02:00)  #    Comments [1]
# Monday, 18 July 2005
IKVM 0.18 rc1

The previous release candidate 0.16 rc1 never actually made it to release because of a GNU Classpath showstopper bug. Thanks to Mark Wielaard for working hard to quickly do a follow up GNU Classpath release that fixes the problem and includes a number of other improvements. I haven't made many changes to IKVM in the mean time, the only major one being that I focussed some effort on reducing the size of the metadata of IKVM.GNU.Classpath (and as a side effect for most other ikvmc generated assemblies as well). I also switched to the Eclipse Java Compiler  because Jikes generates code that is incompatible with the new -strictfinalfieldsemantics ikvmc option.

Update japi results are available here.

Changes:

  • Integrated GNU Classpath 0.17.
  • Switched to the Eclipse Java Compiler for compiling GNU Classpath (not just the generics branch).
  • Added optimization to only store source file name is the name differs from the class name + ".java"
  • Simplified and optimized inner class attribute metadata.
  • Added -strictfinalfieldsemantics option to ikvmc to generate more efficient (and 1.5 spec compliant) code. Note that this is not enabled by default for maximum compatibility with the Sun JVM (which isn't compliant with the 1.5 spec).
  • Rely less on HideFromJavaAttribute and more on naming conventions to use less metadata.
  • Changed ikvm.exe to ignore common -X options that java.exe supports.
  • Changed java.version system property to 1.4.1 to support Eclipse 3.1.
  • Added GNU Classpath version to ikvm.exe -version output.

Files are available here: ikvm-0.18.0.0.zip (sources + binaries), ikvmbin-0.18.0.0.zip (binaries)

Monday, 18 July 2005 10:09:06 (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]
# Friday, 01 July 2005
IKVM 0.16 rc1

GNU Classpath 0.16 was released yesterday, so I've made a new IKVM release based on it. An interesting new feature in this release is that you can now debug dynamically loaded Java classes in the June CTP of Visual Studio 2005. Note that this only works if you start your application in the Visual Studio debugger (at startup the IKVM runtime checks System.Diagnostics.Debugger.IsAttached to determine if it should emit debugging information or not).

Update japi results are available here.

Changes:

  • Integrated GNU Classpath 0.16.
  • Fixed GC race condition for remapped exceptions (introduced in previous snapshot).
  • Added support for naming method/constructor parameters in map.xml.
  • Added support for attaching attributes to parameters in map.xml.
  • Named all method/constructor parameters in map.xml.
  • Changed ExceptionHelper.readObject to not convert ClassNotFoundException into IOException.
  • Named parameters for Cast, CastArray, IsInstance and IsInstanceArray methods in ghost structures.
  • Removed support for "deprecated" attribute in map.xml. Marking methods deprecated in map.xml can now be done by applying the System.ObsoleteAttribute attribute.
  • Removed support for "hidefromjava" attribute in map.xml. Marking methods HideFromJava in map.xml can now be done by applying the IKVM.Attributes.HideFromJavaAttribute attribute.
  • Instancehelper methods on java.lang.String are no longer EditorBrowable(Never).
  • Only emit method parameter names for public/protected methods in public types.
  • Interface methods and methods that don't have debug info now get synthesized parameter names.
  • A couple of "random" awt fixes.
  • Added support for P/Invoke (DllImportAttribute).
  • Moved ikvmc specific compiler support to AotTypeWrapper class.
  • Fixed member access checks (for real this time).
  • Moved native methods of FileChannelImpl and MappedByteBufferImpl from IKVM.Runtime to IKVM.GNU.Classpath (using P/Invoke from Java).
  • Added -fileversion option to ikvmc to set the unmanaged file version.
  • Added call to AssemblyBuilder.DefineVersionInfoResource() to ikvmc, so that a version info resource is now automatically created (the contents are based on the various assembly attributes and the -version and -fileversion options).
  • Fixed possible (but unlikely) NullReferenceException in ClassLoaderWrapper.FinishAll() when it encounters a type that cannot be finished for some reason.
  • Made the line number table encoding a little more efficient.
  • Changed build process to support building the GNU Classpath generics branch (in addition to the main branch).
  • Added a hack to ikvmstub to export generic type instantiations. This enables a usable mscorlib.jar to be generated from the 2.0 version of mscorlib.dll.
  • Implement reversible name mangling for .NET type names (to handle generic type instantiations).
  • Fixed name mangling for delegate inner classes.
  • Set DebuggableAttribute to assembly before creating the module, to make sure Visual Studio (Whidbey) picks up the attribute when debugging dynamically generated code.
    Fixed possible System.ArgumentException in Class.forName() (when trying to load a class with a name that is invalid in .NET)
  • Fixed JNI_GetCreatedJavaVMs to accept null pointer for nVMs.
  • Fixed class name in error message for VerifyError that occurs when overriding a final method.
  • Added workaround to make dynamic debugging work in Whidbey June CTP.

Files are available here: ikvm-0.16.0.0.zip (sources + binaries), ikvmbin-0.16.0.0.zip (binaries)

Friday, 01 July 2005 12:47:52 (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]
# Wednesday, 29 June 2005
The Eclipse Java Compiler

For the past three years I've been using the Jikes compiler to build GNU Classpath, but unfortunately Jikes development isn't very active anymore. I wanted to start playing with the GNU Classpath generics branch (the branch that contains the classes that require 1.5 specific language features), so I needed a compiler that could compile the generics branch and was freely available. The Eclipse Java Compiler was the obvious choice and while I ran into two bugs when I tried to compile the generics branch, the bugs were fixed within hours after I filed them, that kind of responsiveness is confidence inspiring.

The next IKVM release (hopefully due next week) will still be built with Jikes, but future releases will most likely be built with the Eclipse Java Compiler. To make this easier I've used ikvmc to compile it to ecj.exe and created a Windows installer that installs ecj.exe and adds IKVM.GNU.Classpath.dll and IKVM.Runtime.dll to the Global Assembly Cache. If you're not on Windows, you can download ecj.exe in this zipfile. Note that ecj.exe requires Mono 1.1.8.1 or later.

Wednesday, 29 June 2005 14:51:00 (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]
# Thursday, 23 June 2005
PDC '05

From September 13 thru 16 I'll be in Los Angeles for the Microsoft Professional Developer Conference.

If anyone wants to meet up and hang out or chat, drop me a note.

Thursday, 23 June 2005 15:56:19 (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]
# Monday, 23 May 2005
New Snapshot

Partial Trust

I did some research into supporting partial trust and it looks like it might be feasible. This snapshot already contains some changes to better support running in partial trust (particularly for IKVM.GNU.Classpath, IKVM.Runtime contains unsafe code so it currently needs to be trusted). On .NET 1.1 non of the built in partial trust permission sets are suitable, because I require ReflectionPermission(ReflectionPermissionFlag.TypeInformation). In Whidbey this permission flag is deprecated, so the story looks more promissing there.

One of the consequences of adding partial trust support is that IKVM.Runtime.dll will need to be split into several parts. At the very least the JNI implementation will need to be in a separate assembly, so that the common non-JNI scenarios won't require SkipVerification permission.

Exception Handling

I made some major changes to exception handling in this version. However, for Java code nothing should change (except that it hopefully runs a little bit faster), but for .NET/Java interop there are some important changes:

  • Exceptions generated by the CLR or .NET code (e.g. System.NullReferenceException) will no longer be changed into their Java equivalents for non-Java code. This means that when you catch an exception in IKVM Java code, you'll still see the corresponding Java exception (e.g. java.lang.NullPointerException), but when you rethrow the exception, the original exception gets thrown.
  • When Java code explicitly throws a .NET exception (e.g. System.NullReferenceException) it is no longer remapped to the Java equivalent.
  • Catching exceptions now faithfully corresponds to the IKVM type system. This means that you can now use catch(cli.System.Exception) to catch the unremapped .NET exceptions.

This is a major step towards my ultimate vision for exception handling, but I'm not nearly there yet. Other changes I want to make include adding more exception state to java.lang.Throwable instead of the WeakHashMap construct that is currently used (the WeakHashMap will still be required to associate the .NET exceptions with their remapped Java exceptions). I also want to use exception filters to check for remapped exceptions, to make the debugging experience better and the bytecode compiler needs to be improved to recognize try {} finally {} constructs so that they can be compiled as .NET try {} finally {} blocks, instead of the currently used and vastly less efficient try {} catch() { throw; }.

Other News

Mark Proctor reports that Drools runs on IKVM.

Changes:

  • Sync'ed with GNU Classpath cvs.
  • Removed VMClass.forName() implementation (rely on standard implementation instead).
  • Fixed ikvmc to ignore directories in jars.
  • Added "isStatic" parameter to JNI methods ToReflectedMethod and ToReflectedField (this parameter is missing in the JNI specification, but exists in the Sun implementation).
  • Removed workaround for previously unimplemented MethodBase.GetMethodFromHandle in Mono from JNI code.
  • Removed workaround for previously broken GCHandle.IsAllocated in Mono.
  • Removed workaround for previously broken Assembly.GetTypes() in Mono.
  • Disabled finalizer in MemberWrapper (since code unloading isn't supported, members will never be finalized anyway).
  • Added MirandaMethod to MemberFlags.
  • Fixed cosmetic bug in verifier that caused unloadable array types to be named incorrectly.
  • Implemented 1.5 java.lang.String methods (except String.format()).
  • Added ldsfld instruction support to remapper.
  • Implemented ikvmc -compressresources option, to use a simple compression algorithm for resources.
  • Classpath locale information is now in *.properties files instead of classes with resource compression this shaves a couple of hundred KB of the size of IKVM.GNU.Classpath.
  • Many changes to exception handling to improve performance, compatibility and consistency.
  • Added EditorBrowsable(Never) attribute to helper methods in java.lang.Throwable.
  • Fixed method "cloaking" (i.e. hiding .NET methods on Java types in IntelliSense) to hide inherited static methods as well.
  • Various fixes to work towards supporting running in partial trust.
  • Fixed ikvmc bug that caused it to run Java code when tracing was enabled.
  • Added support for applying CodeAccessSecurityAttribute derived attributes (although not at the assembly level yet).
  • Fixed a Miranda bug that caused incorrect classes to be generated for abstract classes implementing java.lang.Comparable but not implementing compareTo.
  • Implemented support for applying attributes to methods/fields defined in map.xml.
  • Changed reflection to disallow reflecting on IKVM.Runtime types (to avoid potential security holes, where Java code can access internal members of IKVM.Runtime).
  • Enabled generation of debug info when a debugger is attached (at the time the runtime is initializing), to allow debugging of dynamically generated code (a Whidbey feature, although in beta 2 it doesn't work yet).
  • Added check to ikvmc to make sure that referenced ikvmc-generated assemblies were compiled with the same version of the ikvm runtime.

New snapshots: just the binaries and source plus binaries.

Monday, 23 May 2005 11:31:14 (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]
# Wednesday, 18 May 2005
Cross Language Debugging in MonoDevelop

Lluis Sánchez posted some cool screencasts that demo cross language debugging in MonoDevelop [via Miguel de Icaza].

Wednesday, 18 May 2005 14:16:45 (W. Europe Daylight Time, UTC+02:00)  #    Comments [1]
# Wednesday, 11 May 2005
IKVM 0.14 Released

I released 0.14 and put the files up on SourceForge. The bits are identical to Monday's rc2.

Wednesday, 11 May 2005 14:43:20 (W. Europe Daylight Time, UTC+02:00)  #    Comments [1]
# Monday, 09 May 2005
Harmony

There's been a lot of confusion about Harmony in the last couple of days. I don't pretend to speak on behalf of the project, but I wanted to give my take on it.

The primary goal of Harmony is to create a J2SE 5 implementation under the Apache License. Many people have interpreted this as meaning that the ASF would start building a JVM and class library from scratch, but that's not the intention at all (although it is a possible worst case scenario). Talks are ongoing between the FSF and ASF to try and work together to change the GNU Classpath license to be compatible with the Apache License. In this light it is important to note that GNU Classpath is already licensed under a modified version the GPL that is more liberal to attract more developers and users. Another thing to note is that the FSF owns all copyright on GNU Classpath (each individual contributor signs over their copyright to the FSF), so the FSF can relatively easily change the license of GNU Classpath (or, for example, dual license it).

In his "Fork in the Open Source Java world" blog entry (a title I obviously disagree with) Miguel argues that the GPL may be a liability instead of an asset for some open source projects. I tend to agree with his view, the GPL and the FSF activism scare many people away, and even with a more liberal license there exist strong motivational factors for companies to work with the community instead of forking a large project and improving only their private version.

As for the pretentious name, all I can say is that I had nothing to do with that :-)

Update: Mark Wielaard corrects me:

And just to correct a little information in Jeroen's latest blog. The FSF/ASF talks are about the general (L)GPL/ASL 2.0 incompatabilities. We do hope to finally solve those since most of them are just legal technicalities and misunderstandings/misinterpretations. (This is something I think is of even more value then this new harmony project).

The current exception statement to the GPL used by GNU Classpath is compatible with and acceptable to the Apache community. But the FSF did say that IF the exception statement was in any way unclear THEN they would certainly be willing to clarify it so that there was no obstacle for adoption of GNU Classpath. There currently doesn't seem any need to do this though.

Monday, 09 May 2005 10:05:34 (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]
Release Candidate 2

Thanks to M. David Peterson for reporting a regression in rc1. I fixed that and created rc2.

Files:

ikvm-0.14-rc2.zip  (source + binaries)
ikvmbin-0.14-rc2.zip   (binaries)

Changes:

  • Fixed regression in member access check that caused public members inherited from a non-public base class in a different package not to be accessible.
  • Merged ikvm-native FreeBSD compilation fixes from Mono's svn back in.
  • Updated all assembly versions to 0.14.0.1 (including JVM.DLL that I forgot in rc1).
Monday, 09 May 2005 09:24:36 (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]