There's a lot to be said for constancy. Most of the problems I've encountered with Domino - especially the newer Java based Notes Client, have been due to Java. Lotus Script has it's gotcha's but they are pretty well documented, thanks to those like you Jake who keep such information online.
As Dragon indicates, the rather constant change in Java versions causes a lot of problems. When you adopt a third party frame work, you adopt all of the problems it has today and all of the problems it will have tomorrow. I suspect this is why many long time developers create their own frameworks - as you shared with your Document classes the other day. If it's your job and reputation on the line, you become risk averse and take in hand the tools which are least likely to embarrass you.
That said, my last project was powered in the main by LotusScript but had some Java, and mostly ran on my own tag library system (build in LotusScript with Java implemented where performance bottlenecks were occurring with LS implementations of Base64 encoding, URL decoding / Encoding and web POST / GET requests). However - my next project is pure Java, JSP, Javascript as I'm working on an application that runs in Websphere Portal Server. I'm inheriting not only all of the Portal server and Websphere application server baggage and issues, but those of the developers who have been modifying it for my client before me and those who have departed that I am taking over for. So in this case, I have to use Java and take the problems that come with all this baggage in stride.
So for those of us who can't be choosy, use the tools available and /or required to the best of your ability and worry not about the age of the technology. COBAL, I will note, is still in serious and reliable use - 30 years on.
There's a lot to be said for constancy. Most of the problems I've encountered with Domino - especially the newer Java based Notes Client, have been due to Java. Lotus Script has it's gotcha's but they are pretty well documented, thanks to those like you Jake who keep such information online.
As Dragon indicates, the rather constant change in Java versions causes a lot of problems. When you adopt a third party frame work, you adopt all of the problems it has today and all of the problems it will have tomorrow. I suspect this is why many long time developers create their own frameworks - as you shared with your Document classes the other day. If it's your job and reputation on the line, you become risk averse and take in hand the tools which are least likely to embarrass you.
That said, my last project was powered in the main by LotusScript but had some Java, and mostly ran on my own tag library system (build in LotusScript with Java implemented where performance bottlenecks were occurring with LS implementations of Base64 encoding, URL decoding / Encoding and web POST / GET requests). However - my next project is pure Java, JSP, Javascript as I'm working on an application that runs in Websphere Portal Server. I'm inheriting not only all of the Portal server and Websphere application server baggage and issues, but those of the developers who have been modifying it for my client before me and those who have departed that I am taking over for. So in this case, I have to use Java and take the problems that come with all this baggage in stride.
So for those of us who can't be choosy, use the tools available and /or required to the best of your ability and worry not about the age of the technology. COBAL, I will note, is still in serious and reliable use - 30 years on.