I’m finally finished beating my head against the wall trying to get drag and drop to work in Lotus Notes 8. It turned out to be a good deal less friendly than I expected.

The actual core of drag and drop listening is stock Eclipse RCP. That’ll trigger off the events as expected, but I found that it wasn’t passing anything across. After digging down as far as I could to see if it just wasn’t processing the transfer properly, I concluded that it was a dead end.

The old way of dealing with this would have been to use NotesUIWorkspace to get the currently selected document. That was never implemented in Java (which is probably because it’s not needed). Because of the eclipse architecture, it is strictly possible to access whatever you want using the standard eclipse classes. Thankfully, we don’t even have to worry about going this deep, I stumbled across an open source plug-in called Formul8 by Jeff Gilfelt. Jeff’s plug-in allows you to execute formulas in the context of the currently selected Document(s), which is similar to what I needed.

Under the hood Formul8 is powered by ‘com.ibm.lotuslabs.context’. Armed with that discovery, I headed back to google, finding this post  about how to use ‘lotuslab.context’, in addition, it also links to a copy of the source code (yippee!).

The ability to compile Java to native code has existed for a while in the form of GCJ, though for the most part it has been overlooked due in part to the incomplete Swing/AWT implementation. Knowledge about how to use GCJ for native compilation is a bit vague. When you first start using GCJ as a real alternative to the Sun JDK it’s difficult to get an idea of exactly what GCJ is capable of doing.

Getting GCJ

If you are a linux user most distributions come with GCJ as either preinstall or one that you can easily install with your favorite package manager. If you are using Windows then your best bet is to use the packages found that http://www.thisiscool.com/gcc_mingw.htm

Mohan Embar, the author of the ThisIsCool website has created several builds of the MingW GCJ that can be easily installed. Additionally he has built in SWT and SwingWT support to some of the builds. Keep in mind that shared builds, and the creation of ‘dll’ files is not supported under the 4.x series of GCJ found on this page.

For the remainder of this build we will be using the latest GCJ found on this page, which includes the eclipse merge branch from the GCC SVN, the best thing about this is that it gives support for Java 5 features.

Basic Native Compilation

The first step is to create a basic ‘Hello World!’ application, to demonstrate compiling an application.

public class HelloWorld {

/**

* @param args

*/

public static void main(String[] args) {

// TODO Auto-generated method stub

System.out.println(“Hello World!”);

}

}

Assuming you’ve added the gcc-ecj\bin\ folder to your path, you can then compile the application using the following command:

Gcj –o Hello.exe –main=HelloWorld HelloWorld.java

You can then run the resulting EXE just as you would any other application.

Basic Windows Application

If you tried running this application from windows (and not from the command line) you wouldn’t have seen much, just a black window flashing up and then closing again. Let’s do a basic Windows application so that you can begin making your masterpiece. This is accomplished using SWT. We will start by creating a ‘HelloWindows.java’ file. You can view the source with Listing 1

We will then compile the source in two steps.

gcj –classpath .; lib\swt.jar -c -o HelloWindow.o

This creates a object file that can be used in the next step to create a working java application.

gcj –main=HelloWindows -mwindows -o HelloWindows.exe HelloWindow.o lib\swt.a

You will still need the DLL files that came packaged with thisiscool gcj in order to run the application but it should create a small windows with ‘Hello Windows’ in the title bar; not very exciting I will admit, but it demonstrates a working windows application.

Notes about this step:

The ‘swt.jar’, ‘swt.a’ and ‘swt*.dll’ files can be found as a part of the thisiscool download, you either need to move them into the same directory as your project or provide a full directory in the adequate place. The dll files should be placed in the same directory as the build .exe file.

More Complex Projects and Libraries

One of the things you may not know is that GCJ can not only work from source files, but also from class and jar files. This is particularly useful if you want to do more complex projects that use existing libraries such as the db4o-6.0-java5.jar file gotten from http://www.db4o.com/.

First create the object file, using the command:

gcj -c db4o-6.1-java5.jar

This creates a file, db4o-6.0-java5.o; we then use ‘ar’ tool to create a static library:

ar -r libdb4o.a db4o-6.1-java5.o

This library file can then be combined into our future projects much the same way as jar files are used in current java projects.

Using Our Shared Library

Not to put the work to waste lets compile a project using the DB4o library that we created in the last part. The source code is too long to paste into the body of the article so I’ve included it in a zip folder so that you can try it later. Let’s start by compiling the source to object files as before:

gcj -classpath .;lib\db4o-6.1-java5.jar;lib/swt.jar -c HelloDb4o.java Account.java

Then we take the library we created before and combine it with the main project (also adding the SWT library):

gcj -o hellodb4o.exe -mwindows –main=HelloDb4o HelloDb4o.o Account.o lib\libdb4o.a lib\libswt.a

You now have an application that will display the record from the database.

Final Notes

Size is often one of the pet complaints when people compile using GCJ, I would encourage people to check out UPX (http://upx.sourceforge.net/).

The source listings here in were done quite hurriedly; particularly the last application would need a good deal of work before it was functional in a useful way. DB4o is a topic for several books, I strongly encourage you to take it out for a test drive.

In order to catch bugs it is in the interest of the developer to remove the ‘-mwindows’ option from the final build. This causes a command line window to be created behind the main screen to which printed exceptions are sent. Alternately and perhaps more correctly logging to file could be implemented.

Finally, it is possible to use Ant and other build tools to make building projects easier, you will find details in the resources on how to accomplish this. For the purposes of explanation I have chosen NOT to use these tools in this article.

Resources

The following were useful guides/tools as I was getting started with GCJ Native Development.

Create native, cross-platform GUI applications – http://www.ibm.com/developerworks/library/j-nativegui/

Create native, cross-platform GUI applications, revisited – http://www.ibm.com/developerworks/java/library/j-nativegui2/

How to compile Java application to native code, for example to Windows EXE file – http://robohobby.s41.eatj.com/java_to_native_code_exe.jsp

DB4o Object Oriented Database – http://www.db4o.com/

The Ultimate Packer for Executables – http://upx.sourceforge.net/

ThisIsCool GCJ – http://www.thisiscool.com/gcc_mingw.htm

Recently I’ve been doing quite a bit of development in Java. Of the many languages that I’ve played with and used I find Java to be one of the most functional programming languages out there. There are plenty of factors that have helped me choose Java as my primary programming language, and while I’m not under the illusion that java is the ‘monkey wrench’ of the programming world, its still an invaluable tool.

I’ve been around programming languages for the last 6 – 7 years, in that time a lot has changed. The software industry has matured in its approach to programming, and the fundamental building blocks that make up the software industry have matured as well. Gone is the time when you needed a PhD to understand the complexities of computer programming. This is not an article about the many different languages; this is not even an article about how Java is better than ‘x’ language. This is simply an article about the features of Java that slipped it into my toolkit.

Native Graphics Support

The first thing that usually pops into mind when you want to convince someone about the superiority of java, is the fact that it’s a compile once run anywhere language. Honestly though I find this less useful than you might think. What I do find useful is the fact that with very little research you can write a graphical user interface for an application. I find the graphics support for Java to be logical, where so many other graphics libraries are not. While I’m not overly fond of the layout managers that Java provides, I can appreciate the fact that they’re there if I do ever find a use for them.

Excellent Database Support

This was one of my primary reasons for moving to java in the first place. If you’ve ever tried to get MySQL working with (Visual) C# then you’ll know what I’m talking about. The JDBC makes connecting to whatever database a dream, if your program is well written you can even switch database backend without to much trouble.

Eclipse IDE

If you haven’t tried Eclipse then you don’t know what your missing out on. While its certainly not solely dedicated to Java it’s a very flexible and well designed tool that will help you get your work done. In addition to being a useful portal to the Java language, it is also a driving force in making Java into more than just the pet project of Sun Microsystems. Take a look at SWT, which was originally developed by IBM and is distributed as a part of eclipse and you will begin to understand.

Lack of Deployment Options

This is one of the fundamental failings of a lot of programming languages. Running a java program relies on the operating system already having a copy of the Java Runtime Environment (JRE) installed. If its not then you won’t be able to do squat, additionally there is no way of knowing whether the version of Java that you’re programming in, and that has the features you want is installed on the client.

You fall back into the same rut that the old VB programs had with missing DLL files. There is no simple way of installing both Java and the given Application in one easy step. Additionally you are held hostage by the fact that you require certain environment variables to be set correctly for the java program to run (JAVA_HOME, CLASSPATH). This is all well and good but it’s just more overhead for the programmer to worry about when they need to do a large scale deployment of an application that they’ve developed.

GCJ bridging the gap

One of the baseline flaws with Java is the fact that it is interpreted (from bytecode) at runtime, and as such relies on the JVM. More importantly it means that it runs slower on CPU intensive processes like md5 hashing for example. GCJ is the GNU Toolkit’s answer to the fact that Java is not open source. It is in effect a complete replacement for Sun Java. More importantly it provides support for compiling Java directly as an Executable freeing it from the reliance on the JVM.

The speeds generated when running is GREATLY improved, to close GCC/G++ levels, and more importantly the deployment is less of an issue. You do lose the fundamental portability that is gained with Java classes, but there is no reason you can’t provide the class files and just install GCJ (rather than Java) to allow the class files to be converted into executables.

THE only place where GCJ is still lacking is the area of AWT/Swing; the developers are still working on adding the support necessary to support the windowing toolkits. Incidentally they are looking for help in this area if any of you programming gurus want to give up your spare time.

Conclusion

The bottom line with Java is that it is a functional and practical language. The fact that Sun is still holding the reins is regrettable because it’s inhibiting a language with otherwise HUGE potential from maturing. The compile once, run anywhere is less useful than ‘write once / compile (& run) anywhere’ this subtle difference is where Sun missed the boat. The matter of compiling different copies for different operating systems is trivial when you consider the fact that doing it the way they are cripples the speed of the language.

Other than that Java is a great choice because it’s a language that’s flexible enough to be used on plenty of different operating systems. You do lose a certain amount of control over the low level functions; however this particular beef has been adequately dealt with in the form of JNI.