If you have been developing XPage applications you have been developing in Java even if you didn’t know it.
When your web browser hits a .xsp url it is not receiving the xsp file that you have written in DDE, it is receiving HTML that has been generated by a java class which is, in turn, calling other Java classes. The XSP file that you have written in DDE is no longer involved, it was transformed into java without you even knowing.
You can see this for yourself, open the ‘Package Explorer’ view in DDE and open your NSF. In there you will see a folder called ‘local/xsp’ and there will be a java class for each XPage and customer control in your NSF. This is the sourcejava for your xsp page which is later compiled into java byte code. The xml on the xsp design element doesn’t even come into it any more.
If you don’t know Java at all or even very well then if you open one of these compiled pages it is going to scare the heck out of ya. What is a package, why is it doing all these imports, public, private, protected, static, final, void, class, abstract, extends… If you don’t know the language then it does indeed seem very scary.
Now, Tim Tripcony is doing a series on taking the scary out of Java for XPages ( he stole my original title but that’s ok ) but Tim already knows Java where as I’m just starting down the road to Java. I have basic ( not the language ) knowledge of how some bits fit together and how to reference it from XPage applications but right now I’m like the majority of Xpage developers and I use SSJS a lot so in this series I’m going to take you with me as I discover Java and Xpages and how it all fits together.
Dec's Dom Blog 