That Java Thing, Part 1: The Java Problem in the Community

Nov 2, 2015, 1:20 PM

Tags: java xpages
  1. That Java Thing, Part 1: The Java Problem in the Community
  2. That Java Thing, Part 2: Intro to OSGi
  3. That Java Thing, Part 3: Eclipse Prep
  4. That Java Thing, Part 4: Creating the Plugin
  5. That Java Thing, Part 5: Expanding the Plugin
  6. That Java Thing, Part 6: Creating the Feature and Update Site
  7. That Java Thing, Part 7: Adding a Managed Bean to the Plugin
  8. That Java Thing, Part 8: Source Bundles
  9. That Java Thing, Part 9: Expanding the Plugin - Jars
  10. That Java Thing, Part 10: Expanding the Plugin - Serving Resources
  11. That Java Thing, Interlude: Effective Java
  12. That Java Thing, Part 11: Diagnostics
  13. That Java Thing, Part 12: Expanding the Plugin - JAX-RS
  14. That Java Thing, Part 13: Introduction to Maven
  15. That Java Thing, Part 14: Maven Environment Setup
  16. That Java Thing, Part 15: Converting the Projects
  17. That Java Thing, Part 16: Maven Fallout
  18. That Java Thing, Part 17: My Current XPages Plug-in Dev Environment

Java has been a bugbear for the Domino community for a long time. Though Notes and Domino have presented a top-to-bottom (mostly) Java environment for years, the monumental inertia of the corporate development community, the platform's tortured history of insufficiently-fleshed-out Java hooks, and IBM's "pay no attention to that man behind the curtain" pitch with regard to the language created an environment where Java is often something for "other developers".

XPages represented a tremendous leap forward for development on the platform, ditching the completely-unique bizarre forms-based web-dev experience in favor of something much closer to modern web development. At the time, the unstructured, SSJS-heavy façade presented by Designer made a sort of sense: the switch to XPages was already a huge change for Domino developers, and making XPage development look sort of like classic Notes/Domino development was a spoonful of sugar with the medicine.

But the critical flaw of XPages development has never been fixed: there's no smooth path from "hello, world" to a well-structured complex application. SSJS, as implemented in XPages, is unsuitable to the task, while Designer's presentation of the Java layer ranges from "non-obvious" to "hostile". Still, IBM did a good job of presenting the next major tier for XPages developers: writing Java first in the NSF and then in OSGi plugins. The problem has always been in figuring out how to get there.

This hurdle started out as an inconvenience just for those who wanted to figure out how the machine worked, but has grown into a significant problem for all Domino developers. While the XPages stack has remained relatively stagnant, the rest of the development world has raced forward, with new technologies giving rise to new frameworks and transforming the old. This is no discredit to the XPages team: they have consistently put in tremendous work across the board, but it's quite an industry to keep up with.

So we're in a tough spot now. The XPages platform isn't going away any time soon, but it's important for us as developers to progress. One option is to abandon ship entirely: pack up and move to some unrelated platform, leaving Domino behind entirely. But most of us, out of personal affection, professional acumen, or (primarily) business requirements, don't want to do that. Unfortunately, the path to improvement with Domino has only gotten more complicated with time. It began with learning about Java, OSGi, and Eclipse proper, but has since expanded to include a whole rogues gallery of other technologies: Maven, Tycho, m2e, Jenkins, Git, Wink/JAX-RS, jQuery, Bootstrap, Angular, and on and on.

There's no time like the present, though. I've walked this path, and I want to help everyone else walk it too. To kick that off, this series is going to cover the process of creating a basic XPages plugin, making it a little more complex, converting it to Maven, and building it with Jenkins.

To kick things off, the next post will provide an introduction to the concept of OSGi and the parts of it that we need to know for Domino development. Things may seem weird along the way, but trust me: it's worthwhile.

Commenter Photo

Patrick Kwinten - Nov 2, 2015, 2:41 PM

sounds great! hopefully it will a plugin everyone can use/is usefull

Commenter Photo

Jimmy Beltram - Nov 2, 2015, 3:00 PM

let's face it: education on development with Java in Domino and in XPages has been really poor. There is no literature that describes the whole process of writing an app using (mainly) Java in the Notes world.

if you read the whole IBM Press XPages book you don't get much further with Java development. too bad TheView is also killed. that was always a good opportunity to get updated on using new technology to write apps.

of course I would not like to blame any blogger, but I haven't seen a serie on how to use Java in XPages like there was with using SSJS as in that qzar blog series.

my experience with the corporate development world is unless there is no book material you will never educate the masses of developers. simply because there is no budget as there was in the 90's.


Commenter Photo

Don Mottolo - Nov 2, 2015, 9:19 PM

Thanks in advance.  Looking forward to it!

Commenter Photo

Shillem Volpato - Nov 3, 2015, 3:06 AM

Sincerely speaking, so far the only merit of XPages has been driving me to understand what the real underpinnings were.
I'm from Italy - I mean, here doesn't seem to be like in the US when it comes to XPages daring developers - and I struggled a lot to find someone that had my same concern regarding the awful approach advertised by IBM.

The I took the other way around. I bought a JSF book (Core JavaServer Faces) and it alone taught me more than a hundred XPages blog posts could. I finally understood the technology, but at the end I realized that I was learning something new entirely, not transitioning.

Honestly, I'm not even sure why I'm bothering writing code on XPages when I could be better off even with a simple Tomcat. I guess, as you wrote, it's the fear of leaving the known for the complete unknown. But I grudge every day when I know that something that would be simple with JSF2.0+ can't easily be achieved because I'm on a frankenstein JSF1.x.
I don't even want to start talking about the supremely outdated Eclipse DDE (the only reason why I'm still having a Windows VM). Really, I feel I'm working in the past, for what, to learn about the dawn of a technology I suppose.

I started staying away from all the features IBM XPages provides; apart from the basic xp tags, I use MVC/DAO patterns, write my own classes and wrappers and use what belongs to javax.faces.
So, maybe, one day it will be less painful to jump off the boat without ditching everything.
Why, if nothing much changes, I will surely jump off this boat. It's been nice but the trip is almost over.

Commenter Photo

Tony Westwell - Nov 3, 2015, 4:05 AM

Looking forward to this.

Commenter Photo

Michael - Nov 3, 2015, 4:54 AM

@Shillem : what feature of JSF2 do you concretely miss in XPages (which, in many aspects, is more advanced than JSF2 !)

Same goes for DDE, what do you really miss that's in Eclipse Mars for example ? (here I'm just curious)

Commenter Photo

Jesse Gallagher - Nov 3, 2015, 7:22 AM

Heh, well, I don't mean to use this as an opportunity to take shots at IBM. This series should be useful, though, whether you intend to grow your XPages expertise or to use it as a jumping point for other Java-based technologies.

I can definitely say, too, that using Mars is a much-nicer experience than using Designer. It's a lot of little things: improved performance here, better code completion there - it all adds up.

Commenter Photo

Shillem Volpato - Nov 3, 2015, 7:48 AM

Sorry, sometimes I get carried way.

But I am even more sorry to have completely omitted giving credit to truly insightful blogs like this and similar.
If it weren't for you guys it would have been even worse.

So, kudos to you that take the time to break these topics down.
If I'm here it is not to encourage everyone to run away but because I am an interested reader.

Well, as Jesse has already partially commented, it's the sum of small things that at the end of the day make a huge difference.

One very small/big thing might just be being able to pass parameters to methods (sometimes just the very object that is looped in a repeat tag in order to reference it in the calling method).

As it is now, it's either the actionListener way - but parameter values are limited to strings - or the (YourObject) xspDataIterator.getDataModel().getRowData() way in a regular method (repeat binding required). Very boring process.
Then someone might even say that I'm doing it wrong at this point, but hey, I'm trying to figure XPages out all the time, I'm not saying I have all the solutions.

Commenter Photo

Michael - Nov 3, 2015, 8:20 AM

Well, I agree Mars etc ..would be cool but that would not revolution the way we deal with XPages neither open platform to broader audience.

Reactive extensions, support for websockets etc would ! As Graph stuff from Nathan does. As Crossworlds does.

My 2 cents

Commenter Photo

Paul Withers - Nov 4, 2015, 9:40 AM

Sorry, I think Mars could probably revolutionise development quite a bit. Domino developers use few plugins available in standard Eclipse like FindBugs, because the version of Eclipse is so old they can't be used. The same goes for Javadoc development. The JavaScript editors are, apparently, much poorer in Designer. But the biggest impact wouldn't be on what it offers in productivity enhancements, but on removing one of the reasons developers aren't moving into plugin development, servlet development, web application development, build management etc.

At ConnectED in January I saw a significant shift in the more advanced XPages developers stepping beyond just Domino development. This risk is a huge widening of the gulf to those who are less willing to build their skills, which means those who could answer their questions no longer have the regular experience to be able to answer their questions. I'm finding that already with a number of SSJS or "how do I get this working in the NSF" queries on StackOverflow - because I don't do it, I sometimes can't help. I did a session at ConnectED on plugin development that went into detail for that purpose, same as I did a Show and Tell at Connect 2014 on source control to remove the excuses for not using it. It's also why I made XPages Help Application open source - my first attempt to write a Java XPages application. And also why I'm doing a series of blogs on moving from XPages to web applications.

In defence of IBM, I'm not even sure what the "best" way of developing a Java XPages application is. The "right" way is almost certainly MVC with DAO, but that's often overkill. And with rich text and attachments, using the dominoDocument datasource avoids a lot of unnecessary headaches and is still my preferred approach. But before that all aspiring XPages developers need to become fully conversant with the excellent documentation Tony McGuckin has created on performance and the lifecycle. Slides are available from various Connect sessions, including the one I did with him last year. It's also in Mastering XPages etc. Tim Tripcony introduced me to that area by giving me a PhaseListener for a session at Engage a few years ago, and understanding the lifecycle is more crucial than understanding Java.

Commenter Photo

Christian Guedemann - Nov 7, 2015, 10:42 AM

Hey Paul


Good motivation speak to finalize the build of the XPages Designer Plugin for Eclipse. With this, XPages Developer will be capable to work only with Mars...

(Bye, bye vacations...)

Commenter Photo

Jason Hook - Nov 9, 2015, 11:19 AM

Just to say I've been using Servlets deployed as OSGi plugins to great effect for probably 18 months (time flies). I use them to integrate services like electronic licensing, ecommerce and other non domino services and they work really well. They are surprisingly robust!

Looking forward to your series...


New Comment