Just lately I've been doing an inordinate amount of Java coding in Domino Designer. Which, for the most part, I'm really enjoying. I'd much rather it were C# and Visual Studio, but hey, it's work and I shouldn't complain.

At some point recently I upgraded my Notes client to 8.5.3 and then some time later I noticed a new design element appeared under the Code section in Designer, as below:

Inside this new area you can directly create and modify classes, like so:

This appeals to me as I find the way Java code is currently stored in Script Libraries a bore. The way you have to save not only your Java source but then also the Library itself. Huh? Same goes for Java Agents!

My hope was that the new Java design element would do away with some of the hassles of using Java and Domino, so I gave it a try, but soon got confused and gave up on it as a new and buggy feature not to be trusted (for now).

The Problem(?)

I created a simple class called Test in the net.codestore; package.

Then in a standard Java Agent I tried to import the package, but it wouldn't resolve it.

One of the solution is suggested was to try and fix the project settings and add the database itself to the build path for the Agent. Huh?

This seems to work. Kind of. The package can then be found be the Agent but you can't create an object based on the Test class. And then when you save and re-open the Agent the reference breaks again.

XPages Only(?)

JavaÔäó design element -- This release offers a Java design element to make it easier to use Java in Domino applications, particularly in Domino XPage applications. This design element let you create a single Java class that is scoped to the actual NSF project itself. This Java file is then directly callable by code in XPages. Previous to this release, you had to put these files manually into the NSF. The introduction of this element makes the use of such files easier and more prescriptive. The idea behind this element is to let you use the normal Eclipse user interface for the Java element wherever possible.

Does this mean it's only for XPages? If so then boo. If not what am I missing or doing wrong?

Comments

The new Java perspective is meant to make it easier for XPages developers to add Java code to the project. Up to 8.5.3 you had to open Package Explorer and add the code to the WEB-INF directory. The XPages and agent runtimes run in different JVM's and can't share code.

So yes, it's only for XPages. If there's a way to share code, I sure would love to know.

Another big help is the working set functionality which lets you define 'working sets' which will only show a subselection of all your nsf databases.

Hugely cool, and really recommended as a low-budget source control system, is using the source version control possibilities. You will want to download the EGit Manager from openntf; and get an account at github.

I use http://www.assembla.com/ for my source control server and I can recommend their services. They also have a free plan that will be good enough for single developer or small team projects. Next step: learn graphic designers to use source control for our collective projects ;-).

I know this an old post, but just thought I'd share my frustrations on this topic too.

We are using 8.5.2/8.5.3 and I have written a number of Java classes that are primarily use by some XPages/XAgents.

I now find myself in the situation where one of my colleagues needs to call that same code from 'traditional' Notes code (either by invoking a Java agent or possibly calling using LS2J) but we can't do it.

The only way I've found that apparently will work, is to compile and export all my custom Java classes into a JAR file and then copy this JAR onto the server's file system (and your development workstations') in the jvm/lib/ext directory, as I believe this location is used by all the JVMs invoked by Domino.

Whilst this will work, my problem with this is that by taking your code outside of the NSF you make deployment and source code management that little bit harder! It's all nice and easy when its contained in a nice NSF template :-)

I'm far from being an expert on this topic, but this is what we ended up in the past, even in an XPages-free environment.

You did not mention yet, what other approach you have tried to store your custom code. But I agree, that the self-containing nature of an nsf file is one of the extremely strong points of Domino, well worth to preserve. It is only one of the points, that IBM obviously always failed to catch. Otherwise they would have put more effort into topics like storing and distributing your custom Java code.