I uploaded a new build of Ja.NET SE today, and it includes several changes.
First, the Apache Harmony distribution bundles versions of xalan, xerces, and xml-commons, as its implementation of JAXP for Java 5. All along, I have been including a .NET version of the xml-apis from xml-commons in the Ja.NET SE distribution, but have not been including .NET code for xalan or xerces. With build 146, this has changed and there are now .NET assemblies (janet.apache.xerces.dll, janet.apache.xalan.dll, janet.apache.resolver.dll and janet.apache.serializer.dll) included in the distribution. These are automatically added into the bootclasspath at startup. Versions 2.7.1 of Xalan and 2.9.1 of Xerces are included.
As you may or not be aware, the Ja.NET SE compiler generates .NET Custom Attributes for Java Annotations. The goal of course is that you should be able to use these Java annotations in any .NET applications should you want to. Well,I discovered, as I was trying to use Java annotations in some C# code, that I really screwed up the implementation of annotations that use Class literals, Java Enums and believe it or not Strings. I implemented the compiler code for annotations quite sometime ago, and for the life of me, I can't figure out what I was thinking at the time ... it was really stupid. Well, in this build, I changed it all, and it is now much better. I"ll do a blog posting giving an example using JUnit. So, any binaries with annotations that you have built using the previous build of Ja.NET SE will not work with this latest drop, so recompile it!
I have made changes to the bam (Build Assembly Module) tool to make it behave even more like jar. There are several changes to bam, but the biggest is it will now accept any file type as input. As it did before, It will take all .class files (ie. .NET assemblies created by javac) and merge them into a larger assembly. But, in addition, it now will include anything else you give to it and add it into the assembly as a resource. In support of that, I have also updated the Ja.NET SE runtime ClassLoader infrastructure to be able to find and retrieve resources from any assemblies that you include on your classpath. (i.e. Remember, assemblies(.dll's) can be added to the classpath much like jars can). So code that calls getResource(...) will be able to retrieve resources from assemblies as you would expect. This is important especially in cases when you are using a Java based assembly/library not bundled in a .jar file, in a C# application and the code in the library expects to be able to read up resources using the Java API's like getResource()... etc.
There were several other changes made, but I won't bore you with all the details.
-Dave