Slides from my Engage 2019 presentation on potential paths for XPages developers in the future.

1. Java With Domino After XPages
What now?

2. Jesse Gallagher
@Gidgerby — http://frostillic.us — http://iksg.us — http://www.darwino.com
WTF Tech Podcast: wtftech.fm

3. This session has three purposes:
1. Discuss paths to build on our Java knowledge
2. Provide an introduction to the Java EE world
3. Group therapy

4. Disclaimer
• I don’t work for HCL
• I don’t have any real inside information on their plans
• The landscape could change
• …it probably won’t change dramatically, though
4#engageug

5. The Path To Here
• XPages was added to Domino in 2008
• It snuck an almost-but-not-quite Java EE stack into
Domino
• …but hid it under SSJS and unstructured development
• The Extension Library turned it into a real app platform

6. What XPages Brought Us
• A real reason to learn Java
• Comfort with using existing Java libraries
• A (rocky) introduction to OSGi
• An introduction to Eclipse
• Steps towards separating data and code
• Strong incentives to use source control, not developing in
prod, and so forth
• An introduction to Maven… right?

7. Buuuuuut…
• Learning materials were few and far between
• Coming in, very few Domino developers had Java
knowledge
• Designer discouraged really getting into the underlying
JSF stack
• The shape of what a “great XPages app” really is never
quite took form

8. The Slowdown
• After more-or-less steady progress to 9.0.1, things ground
to a halt
• (Six years ago!)
• The ExtLib slowed down too, with the last couple releases
focusing on Bluemix
• A larger portion of dev time became consumed by working
against the age of the platform
• We were “IE6’d” out of several technologies: newer JS
versions and features, WebSockets, HTTP/2, Java 7+
until recently, Java EE since 5

9. The Future of XPages?

10. HCL Could Massively Improve It
• They’ve said they’re going to “continue investing” in it
• However, that sentence is always followed by a “but…”
• So: don’t expect massive changes
10#engageug

11. XPages Outside Domino
• XPages started live outside Domino
• It still kind of works there: https://github.com/jesse-
gallagher/xpages-runtime
• This could be a good step-by-step migration path
• …but it requires changes from HCL
11#engageug

12. XPages Offline on Mobile?
• It’s technically possible! I did it:
• The same can be done on iOS
• …but I don’t think it’s terribly likely
12#engageug

13. Where does that leave us right now?

14. Where We Are
Points on the path:
1. Never got into XPages
2. Use XPages with just SSJS
3. Use XPages with in-NSF Java
4. Write OSGi plugins
5. Moved above/out of XPages entirely
The awkward zone

15. The Paths Forward
• Go back to LotusScript
• Switch to node.js
• Soldier on with XPages
• Focus on REST APIs
• Cram Java EE/Spring/Servlet tech into Domino
• Standalone Java server

16. The Paths Forward
• Go back to LotusScript
• Switch to node.js
• Soldier on with XPages
• Focus on REST APIs
• Cram Java EE/Spring/Servlet tech into Domino
• Standalone Java server

17. The Paths Forward
Focus on REST Services
Pros:
• You can potentially keep using Designer if you want
• Strongly encourages good API/app separation
• You get to use a client JS app framework
Cons:
• You’ll have to learn a client JS app framework

18. The Paths Forward
Cram Java EE/Spring/Servlet Tech into Domino
Pros:
• Keep the app server you have
• Java 8 removed a lot of hindrances
• General documentation and examples abound
• Direct NSF access
Cons:
• You’ll have to learn some new tools
• The servlet API lags far behind (no WebSockets, no HTTP/2)
• OSGi makes things awkward
• Specific examples are few and far between
• Some common practices don’t apply: JPA, security APIs, etc.

19. The Paths Forward
Standalone Java server
Pros:
• You’re not held back by the platform
• Work with the tools everyone else is using
• Spring and modern JEE are great!
Cons:
• It’s a weird, wide world
• Accessing Domino data is less straightforward

20. Java Web Apps: JEE
(Java EE? Jakarta EE? EE4J?)
20#engageug

21. What is Java EE?
• “EE” means “Enterprise Edition”
• Essentially, Java EE is “Java web server stuff”
• It was recently transferred to Eclipse, where it will be
developed as “Jakarta EE”
• Trademarks are fun
• It’s a whole thing: http://eclipse-foundation.blog/2019/05/03/jakarta-
ee-java-trademarks/
• It encompasses many components, including JSF and JAX-
RS
• XPages can be viewed as a fork of some of Java EE circa Java EE 5
• It’s not the only game in town: Spring, MicroProfile, vert.x,
Quarkus, and others
#engageug

22. What is Java EE?
22#engageug

23. What is Java EE?
23#engageug

24. Java EE: Old and New
• Java EE used to be really cumbersome
• There’s a reason we all dreaded IBM’s WebSphere push
• But then it went to the gym!
• Nowadays, it’s extremely straightforward, fast, and
powerful
• It also used to be extremely expensive
• Nowadays, you can go pure open-source
24#engageug

25. The Difficulty Path
25#engageug
Basic XPages
XPages + Java
XPages + Java
+ Jars
OSGi Plugins
JEE Web Apps
OSGi Plugins + Maven

26. Things You’ll Hate, Then Love
• Application servers
• Tomcat, TomEE, GlassFish, Payara, Liberty
• Not just modifying production apps willy-nilly
• Maven/Gradle
• App + database separation
• Automated testing
• IDE choice
• Eclipse, IntelliJ, VS Code, NetBeans(?)
26#engageug

27. Helpful Tools for Standalone Java Servers
• Domino Open Liberty Runtime:
https://github.com/OpenNTF/openliberty-domino
• CrossWorlds:
https://wiki.openntf.org/display/CW/CrossWorlds
• Dropping Domino’s HTTP task:
http://hasselba.ch/blog/?p=2625
• Darwino: https://www.darwino.com

28. Thank You!
Q&A