logo

Domino Designer's New Java Code Element

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:

image

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

image

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.

image

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

image

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? 

image

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(?)

Here's a snippet from the What's New page for 8.5.3 (emphasis my own):

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

  1. 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.

      • avatar
      • Jake Howlett
      • Mon 2 Apr 2012 04:50 AM

      XPages only - is that your understanding of it or the official line?

      If it's the official line then (not only does it suck) but they ought to make it a bit more clear in the wording of the "What's New". It says not "particularly" for XPage apps. Not "only".

      Show the rest of this thread

  2. It is for XPages only.

    It'll be more obvious when you'll use the different perspectives within Domino Designer.

    - The "Domino Designer" perspective (default!) shows all elements.

    - The "Forms/Views" perspective (aka "the classic, non-XPages way") does not show the design element.

    - The "XPages" perspective shows the design element.

      • avatar
      • Jake Howlett
      • Mon 2 Apr 2012 05:20 AM

      Oh well, shame.

      Thanks for alerting me to the "Forms/Views" perspective. I had no idea that existed and it makes much more sense for me to work in that perspective as a non-XPager.

      Show the rest of this thread

  3. The goodie you are looking for is squirelled in

    File/Preferences/Domino Designer/Java Editor/Autosave Java design element on save of individual Java sources.

    Sooooo much less annoying.

      • avatar
      • Jake Howlett
      • Mon 2 Apr 2012 05:58 AM

      Why didn't you tell me about that a month ago!!!!! :-)

      Hide the rest of this thread

      1. 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.

        1. Just as Andrew says, working sets can be very useful. There still are some minor annoyances but working sets will really help you organize your projects.

          Again to complement Andrew, the time has come that we can use source control in Designer without some expensive add-ons. If you don't want to use Git, you can use Subversion. Here are some links:

          http://heidloff.net/home.nsf/dx/09152011024951AMNHEA28.htm

          http://stackoverflow.com/questions/.. ..control-with-lotus-notes-designer-8-5-3-gef-sdk-missing

          http://www.openntf.org/internal/hom.. ..&name=Subversion%20UpdateSite%20for%20Domino%20Designer

          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 ;-).

    • avatar
    • Rami Muurimäki
    • Mon 2 Apr 2012 01:46 PM

    I think you pulled way up your learning curve today? :)

    • avatar
    • Chris
    • Thu 30 Oct 2014 07:13 AM

    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 :-)

    Did anyone ever find a neater solution?

    • avatar
    • harkpabst_meliantrop
    • Thu 20 Nov 2014 06:54 PM

    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.

Your Comments

Name:
E-mail:
(optional)
Website:
(optional)
Comment:


About This Page

Written by Jake Howlett on Mon 2 Apr 2012

Share This Page

# ( ) '

Comments

The most recent comments added:

Skip to the comments or add your own.

You can subscribe to an individual RSS feed of comments on this entry.

Let's Get Social


About This Website

CodeStore is all about web development. Concentrating on Lotus Domino, ASP.NET, Flex, SharePoint and all things internet.

Your host is Jake Howlett who runs his own web development company called Rockall Design and is always on the lookout for new and interesting work to do.

You can find me on Twitter and on Linked In.

Read more about this site »

More Content