Well, you probably had thought the Ja.NET SE project had died, since there hasn’t been much activity lately (i.e. releases, blogs, etc.). Well, it hasn’t .... there actually has been alot of activity, just not visible to the outside community. I have been working on it off and on, and have made some really good progress, ... in spite of having a real paying software development job which of course is always first in priority. :-) I'm going to try and do a much better job of communicating going forward.
Build 358 was uploaded a few days ago, along with a zip of what I'll refer to as additional useful development tools (Ja.NET-SE-Additional Development Tools.zip). I have been using these tools in several Java library "porting" efforts, so I thought I would provide them as an additional download for others to use as well. I'll blog more about what's in this zip and how to use itin upcoming blogs.
So first, let me try to summarize where I am with the 358 build. This build contains numerous fixes as you probably already guessed, as well as "feature" additions to the Java JDK class library built for .NET. I have successfully been using this build on Windows XP SP2, Vista and Win 7. At this point I have only built and tested on 32 bit OS’s. At some point I'll get around to testing on 64bit OS's.
I have used this drop to "port" numerous Java based open source libraries to .NET. Now, when I say "port", what I really mean is, I have taken the Ja.NET SE JDK, along with the "Additional Development Tools.zip" I mentioned above, and have used the Ant build scripts that are provided with the open source projects which I'm porting and built binary versions of the project's libraries that run on a JVM as well as the .NET CLR. In many cases the projects have built with no changes to the Ant scripts or the Java source code.
To give you an example of what should be possible with the 358 build, let me describe one of the porting efforts I am currently working on. I started the effort a while back, with the goal of pulling together a version of the Eclipse IDE running on .NET. I started this mainly for two reasons; First Eclipse is a rather large and sophisticated Java based program (i.e. multithreaded, custom class loaders, etc.) , and I thought that getting it to build and run on .NET would be a really good test of the Ja.NET SE JDK tools and runtime. Second, I wanted to pull together a Java IDE that could be used with Ja.NET SE. That is, an IDE that included the Ja.NET SE tools (i.e. compiler, assembly merger, etc.) fully integrated so as to make it easy to author Java code that referenced the .NET runtime (i.e. with code completion, etc.).
Now, as you may or may not know, the Eclipse IDE has been designed and developed around a component based architecture. It is composed of several Java based "plug-ins" or OSGI "bundles" as they are sometimes called these days, each packaged as a separate .jar file. When you launch the IDE on Java, you are first starting up the bundles that represent the OSGI module system (i.e. a OSGI container runtime) followed by a load of all of the additional bundles that actually make up the Eclipse IDE itself. The Eclipse SDK package, (i.e the one I've ported to .NET), contains approximately 150+ bundles with a total of some 18,000+ Java source files. I would estimate the lines of Java source to be well over a million lines of code. Using the 358 build, I have successfully been able to compile and run all of this Eclipse SDK code.
As you probably can imagine, the 18,000+ Java source files have dependencies on several other open source projects, in addition to themselves. In fact, what I found is that Eclipse is reliant on Apache Ant , IBM's ICUJ, JSCH, Apache Tomcat, Apache Commons EL, Apache Commons Logging, Apache Lucene, Mortbay Jetty, ObjectWeb ASM, SAT4j, Log4J, just to name a few. So before I was able to build all of the Eclipse bundles, I have also had to download and build several other open source projects, including those mention above, using the 358 distribution and the additional tools.
When building Eclipse from source, you need to used Ant along with several custom Ant Tasks that are provided with the Eclipse distribution. For the most part, each plug-in is built separately using its own Ant build script, which is then packaged into its own .jar file, along with the bundles manifest. The packaging I used for the built .NET version is pretty much the same. The main important difference is the bundle's .jar file includes a .NET assembly with the .NET implementation code for the bundle in addition to the Java .class files which are used when running on a JVM.
The source code changes that I have had to make during the port were primarily concerned with removing the JNI native library dependencies from a few of the plug-ins. The biggest plug-in I had to tackle was SWT. It uses JNI to issue calls to the OS API's to create windows, buttons, etc. What I decided to do was to "port" some experimental SWT/WPF Eclipse implementation code that the Eclipse community had developed in C++ over to Java, so I could then have a pure .NET managed SWT/WPF wrapper implementation. Probably a little Eclipse history would help understand this approach.
A few years ago the Eclipse development community decided to develop an "experimental" SWT/.NET WPF port. What they ended up developing was a software bridge that enabled the SWT plug-in to host the .NET CLR in the same process as the one that was running the JVM and SWT and to "call" into the .NET WPF Framework libraries to create the underlying handles for the SWT Widgets using the WPF UI controls. The plug-in would basically load into the running CLR, some proxy code that they had developed, which enabled it to call into the CLR to create and manipulate WPF UI elements (i.e. Window, Popup, Button, etc.). Most of this bridge and proxy code was written in managed C++, with a little bit of native C++ thrown in for managing JNI and CLR handles and bridging calls between VMs.
So, what I decided to do for my "port", was to rewrite all of that C++ code in Java, and reference the .NET WPF Framework directly from the Java code, since with Ja.NET SE, all of Eclipse (including SWT), would be running directly on the .NET CLR and there is no need for any bridging between VMs. To do this, I modified the Ant build script for the SWT plug-in to include the WPF Framework DLL's (e.g. PresentationFramework.dll, etc.) on the classpath of Javac task and then modify the SWT Java source code to reference the WPF framework directly .... using the C++ code as guidance. This worked out pretty well. In fact, with those changes done, I was able to get Eclipse up and running natively on .NET. In fact it seemed to function pretty well, unfortunately, not perfect.
It turns out, porting the SWT C++ "experimental code/approach" to Java was not as robust as I had hoped. I found a few performance problems with some of the SWTdialogs and after trying to diagnose and fix those issues, I decided it was best to just rewrite the SWT/.NET WPF port. The good news in this is that none of the performance problems have been associated with Ja.NET SE, which is good thing, and is just one of the reasons why I think 358 is a pretty good build.
Enjoy... let me know what problems you run into!
Dave