Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Engage 2019 - De04. Java with Domino After XPages


Published on

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

Published in: Software
  • Login to see the comments

Engage 2019 - De04. Java with Domino After XPages

  1. 1. Java With Domino After XPages What now?
  2. 2. Jesse Gallagher @Gidgerby — — — WTF Tech Podcast:
  3. 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. 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. 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. 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. 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. 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. 9. The Future of XPages?
  10. 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. 11. XPages Outside Domino • XPages started live outside Domino • It still kind of works there: gallagher/xpages-runtime • This could be a good step-by-step migration path • …but it requires changes from HCL 11#engageug
  12. 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. 13. Where does that leave us right now?
  14. 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. 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. 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. 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. 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. 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. 20. Java Web Apps: JEE (Java EE? Jakarta EE? EE4J?) 20#engageug
  21. 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: 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. 22. What is Java EE? 22#engageug
  23. 23. What is Java EE? 23#engageug
  24. 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. 25. The Difficulty Path 25#engageug Basic XPages XPages + Java XPages + Java + Jars OSGi Plugins JEE Web Apps OSGi Plugins + Maven
  26. 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. 27. Helpful Tools for Standalone Java Servers • Domino Open Liberty Runtime: • CrossWorlds: • Dropping Domino’s HTTP task: • Darwino:
  28. 28. Thank You! Q&A