learn the Java Collections Framework
Category xpages java
If you're a Domino developer, you're likely already developing XPage applications or headed in that direction. And if you're already developing with XPages, you're likely at least curious about Java, if not already familiar with at least a few concepts of the language.
I'm asked with increasing frequency, "how should I start learning Java?" That's not a surprising question, given both the complexity of the language and the sheer amount of information available; it's comparatively easy to learn LotusScript, because it's a comparatively finite language and there is a single authoritative source: Domino Designer Help. And, let's face it, there are simply less people using LotusScript than Java. While a community of literally millions of developers can be an advantageous resource once you're comfortable with the language, if you're wondering how to even begin, that's a lot of hay to discard just to find your first needle.
One approach, of course, is to find a good book. I've consistently heard great things about Head First Java (though I've never read it myself). Of late, however, I find I'm recommending to developers new to the language, and to those with some familiarity who want to apply that familiarity specifically to XPage development, this tutorial on the Java Collections Framework.
Every Notes / Domino developer is already familiar with the philosophy of a collection: it's just a way to refer to multiple things by a single name. In LotusScript, we have arrays and Lists. But even Notes Formula has lists. So we already get the concept, now we just need to update our terminology.
For example, a list in Formula is not the same as a List in LotusScript; a Formula list is really more akin to a LotusScript array. A LotusScript List, on the other hand, is a construct used to map keys to values: for instance, names to phone numbers.
Similarly, a List in Java is like a LotusScript array or a Formula List; a Java Map is like a LotusScript List.
If you haven't already finished the above tutorial, sorry to spoil the suprise, but the previous sentence already tells you most of what you need to know. Reading the full tutorial is a great way to quickly come up to speed on all the interfaces that comprise the Collections Framework - particularly the methods each supports - but if you only understand List and Map, you're already well on your way to writing better XPages... even if you never write a single line of Java. The true "nuts and bolts" of XPages are Lists and Maps, so even if your own code is strictly SSJS, that code is still interacting with Lists and Maps, and understanding what those are and how they work will make your results far more predictable.
If you're a Domino developer, you're likely already developing XPage applications or headed in that direction. And if you're already developing with XPages, you're likely at least curious about Java, if not already familiar with at least a few concepts of the language.
I'm asked with increasing frequency, "how should I start learning Java?" That's not a surprising question, given both the complexity of the language and the sheer amount of information available; it's comparatively easy to learn LotusScript, because it's a comparatively finite language and there is a single authoritative source: Domino Designer Help. And, let's face it, there are simply less people using LotusScript than Java. While a community of literally millions of developers can be an advantageous resource once you're comfortable with the language, if you're wondering how to even begin, that's a lot of hay to discard just to find your first needle.
One approach, of course, is to find a good book. I've consistently heard great things about Head First Java (though I've never read it myself). Of late, however, I find I'm recommending to developers new to the language, and to those with some familiarity who want to apply that familiarity specifically to XPage development, this tutorial on the Java Collections Framework.
Every Notes / Domino developer is already familiar with the philosophy of a collection: it's just a way to refer to multiple things by a single name. In LotusScript, we have arrays and Lists. But even Notes Formula has lists. So we already get the concept, now we just need to update our terminology.
For example, a list in Formula is not the same as a List in LotusScript; a Formula list is really more akin to a LotusScript array. A LotusScript List, on the other hand, is a construct used to map keys to values: for instance, names to phone numbers.
Similarly, a List in Java is like a LotusScript array or a Formula List; a Java Map is like a LotusScript List.
If you haven't already finished the above tutorial, sorry to spoil the suprise, but the previous sentence already tells you most of what you need to know. Reading the full tutorial is a great way to quickly come up to speed on all the interfaces that comprise the Collections Framework - particularly the methods each supports - but if you only understand List and Map, you're already well on your way to writing better XPages... even if you never write a single line of Java. The true "nuts and bolts" of XPages are Lists and Maps, so even if your own code is strictly SSJS, that code is still interacting with Lists and Maps, and understanding what those are and how they work will make your results far more predictable.

Comments
I found it very good and would highly recommend the book, and it has a good forum(s) { Link }
When I first got it, I kept thinking, but it doesn't relate to how to use java in Domino, because my head was stuck in "Domino only" mode, but as soon as you start learning java, you get the "aha", pretty quickly.
Posted by Nick Wall At 05:03:54 AM On 05/24/2012 | - Website - |
Posted by David Marko At 04:59:25 AM On 05/24/2012 | - Website - |
There are good certification books of the same authors as Head First Java. Most certifications are just crap, but SCJP steered me to the important pain points important to get through to get enough understanding of the language. As a certification should be.
To come back to the topic of Collection Framework: After certi you not only think Map and Set and List, but TreeList, LinkedHashMap, HashMap, TreeSet, HashSet, ArrayList. And this aquaints you with an important mindset to make use of all those much to many classes of the java system: Don't script the logic all for yourself, but let classes written by more inteligent people do the work.
Posted by axel At 06:33:32 AM On 05/24/2012 | - Website - |
Java makes it kind of troublesome by including so many specific implementations, but focusing on the Interfaces - List, Map, Set, and the others in java.util - keeps things clean and helps tremendously when writing Java classes for XPages.
Posted by Jesse Gallagher At 07:37:46 AM On 05/24/2012 | - Website - |
Posted by Tim Tripcony At 03:37:59 AM On 05/24/2012 | - Website - |
Posted by Ulrich Krause At 03:04:11 AM On 05/24/2012 | - Website - |
Posted by Ralf M Petter At 09:08:52 AM On 05/24/2012 | - Website - |
THAT is the key to making the transition. If you're a Lotusscript procedural programmer, you MUST MUST MUST make the transition to OOLS. Do that, even for only a few months, and your transition to Java will take about 3 weeks.
If you try to make the jump to Java directly from procedural Lotusscript, then not only are you going to have to learn the nuances of a new language, but you'll have to transition to OOP at the same time. This can be very jarring. (sorry... pun intended.)
Once you're already in an OO mindset, then I agree that the Collections API is a great start to learning Java. Because they are Interfaces, it makes a good introduction to understanding the difference between an Interface and a Class. They also provide a gateway into understanding Generics.
Interfaces and Generics are very important concepts for Lotusscript developers to learn for exactly the same reason that Option Declare is an important practice for Lotusscript developers to learn: it moves your bug detection from run-time to compile-time. Every time you see a red X in your IDE that indicates a compiler problem, that's one less bug you would have shipped to a user. If you use Interface contracts and Generics rigorously, you can dramatically reduce the number of defects in your production code. (This is exactly why I don't like SSJS for anything more than 3 lines.)
Posted by Nathan T. Freeman At 10:10:59 AM On 05/24/2012 | - Website - |
Posted by Tim Tripcony At 05:41:06 PM On 05/24/2012 | - Website - |
Posted by Paul T. Calhoun At 12:29:06 PM On 05/24/2012 | - Website - |