Bob Balaban's Blog

     
    alt

    Bob Balaban

     

      What if....Java in Domino were better?

      Bob Balaban  October 9 2007 09:00:00 AM
      Greetings, Geeks!

      Today I am pleased to debut yet another guest blog from a member of our crack (not "cracked", mind you, "crack") dev team, Steve Nikopoulos. Steve and I put this post together to get your feedback on improvements to Java integration in both the Client and Server (as you'll see below). Please welcome Steve to the blogosphere, and have at it!

      Many of you use Java in Notes and/or Domino today. Many (most?) of you find it less that fully satisfying for any number of reasons (Big one: lack of an integrated Java debugger. Another big one: because of our testing and stability requirements, it often takes a while for us to roll out new versions of the JVM. ...we could go on).

      For our Next Major Feature Release (NMFR), we may have an opportunity to improve Java integration in both the Designer environment and in the Client and Server runtime environments (and the lawyers make us say: this is all hypothetical, no promises, subject to change, yadda yadda yadda). Naturally, we have some questions.

      For the purposes of this discussion, we're going to put aside the topic of Designer integration (we think we know what we're going to do there, and those of you who have been faithful followers of this and other blogs authored by certain Lotus employees will have a decent idea of what those plans are). We do, however, want your feedback on the topic of JVM (runtime) integration in the Client and the Server.  This is your chance to tell us about the top 3 or 4 things that bother you about designing and deploying applications written in Java on Notes/Domino.

      What would it take for you to use Java more effectively in your Notes/Domino applications? What types of applications do you want to build using Java that you either can't do today,  or that are really difficult to write? Would you prefer to write them in Java (why?) or in some other programming language? (which one?)

      Again, we're not asking about Designer integration here (let's say, just for hypothetical fun, that we're going to let you create and debug Java programs/Agents for N/D in Eclipse).  Your topics might include suggestions about libraries, packaging, security, performance, scalability, administration, diagnostics, apis, etc.

      Remember: "Be positive when possible, be negative when necessary." Thanks!
      Comments

      1Jesper Kiær  10/09/2007 9:47:57 AM  What if....Java in Domino were better?

      1. I always wanted to do some stuff with Applets, but..It was ALWAYS a nightmare. The applet might run in the browser, but in the client, it wouldn't. Could not find some files, JAR, or whatever...

      Jar,Applet should be placed in the Notes database and simply just work, without the weird dialog with Base Direcory etc.

      2.

      I remember using an applet (using ncso.jar)in a form once. It worked but loaded slowly. I looked in java cache and found out that every time a web page was shown using this form the ncso.jar was fetched from the server, because of the different document UNID in the URL ..I presume. So something slow was turned into something even slower :-(.

      These 2 things should really be fixed.

      Make using Java libries, applets intutive, simple and easy. It is not today

      brgds jesper

      2Jeff Gilfelt  10/09/2007 10:30:30 AM  What if....Java in Domino were better?

      I would like to be able to write Java server agents that, rather than being initialised and then unloaded upon every execution, are initialised only once and can service many requests, much like a Java servlet. This would make it a lot easer to connect Domino to persistent enterprise data services and should also yield better performance for "agent heavy" Domino applications.

      While this could be implemented as an entirely separate servlet engine as discussed in the earlier Garnet thread, why not apply this behaviour to the existing agent (and web service) manager? You could introduce a new agent property in the designer like "enable persistent lifecycle".

      3  10/09/2007 10:50:23 AM  What if....Java in Domino were better?

      Hello. Thank you very much again for soliciting comments:

      1. Domino 7 provides web services via the base Axis libraries (repackaged under lotus.domino.axis). It's awesome and I want to thank you for it. However, the consumer implementation (ie. creating the java stubs via WSDL2Java) is not yet fully implemented. I'd like to see that bring web services full circle. You can get it done in 7 using the command line axis tool and performing a few tweaks like setting the classpath to NCSO.jar and websvc.jar and importing the resulting stub classes to a domino library but it's not intuitive. The beauty of Domino's current web service is that it closely resembles an agent in the domino ide...so getting a consumer development tool to that point, perhaps where one could simply import wsdl and the engine cranks the classes out internally would sell a lot of Domino developers. The web services consumers are usually the most onerous half of a web services interface build.

      2. Support for SOAP Attachments. Content is getting larger, so it's more difficult to stuff large binaries within soap xml. Transfers can be done via chunking but the trend seems to be SAAJ.

      3. An impossible dream would be to dynamically upgrade the jvm on a Domino client or server....however, I don't know about the impacts on the dll's (much less Domino Designer help). There were significant changes between jvm 1.3 to 1.4 to 5 and I constantly found myself throwing undefined exceptions via the "one version less" jvm in the current Domino release.

      4. Something that allows domino to hold java objects in at least session context. Perhaps a method like session.setAttribute(name,value) and session.getAttribute(name). This would allow for the storing of collections in memory. I guess it can be worked around now by unbundling the collection into a backend notes record and rebundling when necessary or perhaps saving the object to a local dat file but something like those methods, particularly in session scope, would enhance the platform and mimic a strength of open source j2ee engines.

      5. This is asking a lot...but a more robust and a fully encapsulated Domino-like servlet engine (see web services). The problem here is that servlets are fueld by I'm not sure where servlet settings found in web.xml in j2ee apps could be integrated into Domino...i know Notes 7 allows for a properties file...but the fully integrated web services has me kinda greedy and spoiled on this one.

      6. @2 made reference to it...Domino's security is kinda hard to grasp regarding imported jar files. Particularly critical and commonly used jars like ojdbc14. I'm not sure if there's an easier way to accomplish granting permissions to these jars outside of the overhead of an administrator maintaining the permissions file or having to keep the jar in domino's default library. I'd like to see granting permissions on the agent/web service level. i see why it's there though...so maybe a compromise would be a server document field where specific jars can be listed.

      Overall, I think requests 3 and 5 are shooting for the moon. I also want to reiterate that, in my opinion, everything that has been done with java in Domino has been brilliant.

      4  10/09/2007 10:53:02 AM  What if....Java in Domino were better?

      redo on 5 above...

      5. This is asking a lot...but a more robust and a fully encapsulated Domino-like servlet engine (see web services). The problem here is that I'm not sure where servlet settings commonly found in web.xml in j2ee apps could be stored in Domino on the database level...i know Notes 7 allows for a properties file...but the fully integrated web services has me kinda greedy and spoiled on this one.

      5Tim Siney  10/09/2007 10:54:56 AM  What if....Java in Domino were better?

      I code high traffic web applications almost exclusively and unfortunately I have had rather a negative experience with the current Java implementation in Domino. I've worked with java in domino from version 5 right up to version 7. With that in mind I'll state my experiences:

      To put it bluntly, the current implementation of Java in domino is next to useless for any serious purpose. It leaks memory like a sieve and as soon as a java agent starts getting hit it will crap out and start returning error messages. The LS2J stuff eats up memory and will also die a death as soon as the going gets tough. Java agents also seem to be a great deal slower than the equivalent lotusscript versions.

      Therefore I think the first step is to get the java implementation in domino up to a workable standard so that it is quick, stable and won't crash and bring the server down at the drop of a hat. It makes sense to me to allow the java implementation in domino to be linked to an external servlet container such as tomcat which would solve a lot of the stability issues (although I guess this topic is a whole other area of discussion!).

      Tighter integration between domino and external java app servers would be extremely useful. At the moment when we call servlets/jsp's etc which reside in tomcat from our domino web apps, we have quite a convoluted procedure to enable SSO between the tomcat server and domino. I'd love to be able to verify a domino user with a session cookie and a few lines of code rather than maintain a complicated domino SSO server setup and manually check cookies for LTPA tokens etc.

      Another useful addition would be httpservletrequest and httpservletresponse type objects - I often need to get values of submited forms in domino, and at the moment have to parse the request_content field (which unfortunately seems to be limited to 32k...) and have to roll my own extraction routines. An inbuilt one would be hugely useful.

      The performance of ncso.jar seems to pretty sluggish, this could really do with a speed boost. The bugs need to be worked out fully as well. I submitted a ncso.jar bug report recently, waited a few weeks for it to be fixed and was told in as many words that the bug was known about anyway but no one had bothered to fix it before the product was released. I think this attitude to Java in domino just about sums up the feeling I have about it - it seems like it has been added as an afterthought, almost a toy.

      Negative stuff over, I am glad to hear these issues may be addressed. Java is an extremely powerful language which can do many things are simply impossible to do using lotusscript. I'd love to be able to use it more extensively with domino.

      6Mario Varchmin  10/09/2007 11:07:29 AM  What if....Java in Domino were better?

      1. I would like to be able to select a JRE instead of being forced to use the JRE that comes with Notes/Domino. It would be sufficient if IBM would provide a list of supported OS/JRE configurations. If I chose to use something else and it works for me, then why not?

      2. I would like to be able to use Java in Notes for Apple Macintosh.

      3. Improve garbage collection! One of the beauties of Java is, that in general, you don't have to worry about garbage collection. That is, unless you are programming Java for Notes/Domino.

      4. I second the wish for agents that don't need to be loaded and unloaded each time they are invoked.

      5. I like the lotus.domino.* classes very much, because they follow exactly the class model that exists in LotusScript. When I am familiar with the LotusScript classes, it is no problem at all to write my first Java agent. On the other hand, when I am coming from the Java world, where I am used to the Collection classes of java.util.*, or the directory classes of javax.naming.* and javax.naming.directory.*, it would be quiet nice to apply this knowledge to Domino. I think the Domino objects could easily be exposed through Collection classes (such as List, Set or Map), or the directory classes (NamingEnumeration, Attributes, etc.). This would make Domino appear less "exotic" and the developers more productive. The resulting code might also be more generic, or existing code may be more easily adapted to Domino.

      Best regards

      Mario

      7Bram Withaar  10/09/2007 11:50:12 AM  What if....Java in Domino were better?

      I like to have an more up to date jvm for java agents.

      Right now i'm coding in eclipse, create a jar, and import that in a notes agent. Shared java libraries don't work well, when i change a jar in a java lib the java agent still sees the old code.

      Better garbage collection.

      Don't know about better applet support, nd8 opens a lot of new possibilities with java components in a composite app.

      8Gerald Mengisen  10/09/2007 2:55:22 PM  What if....Java in Domino were better?

      I would very much like that things like recycle and NotesThread.init were things of the past when writing Java code from an application server that accesses Domino.

      The current "tell diiop log=4" is a great tool for figuring out what objects are being created, but I find it could be more verbose about recycling (in case you can't get rid of the recycle method altogether). What I'm missing is a way to see all non-recycled objects created via DIIOP.

      It would also be great if Database and View objects were re-usable in pools - I had no luck when trying to implement such thing in a separate thread.

      As mentioned by Mario Varchim before, I like the fact that the lotus.domino.* classes follow pretty much the LotusScript object model.

      9Fredrik Stöckel  10/09/2007 6:44:18 PM  What if....Java in Domino were better?

      Better support for alternative (binary) output in java agents

      (fix the undocumented getAgentOutputStream() method :))

      Custom-data objects (for agents) are really cool, More stuff like that please :)

      Make it easy to maintain jvm\lib\ext from the admin client (r/w permissions) so we can drop our jar files there in an easy way. Now we tend to add large jars in our agents/script libraries just because it's painfull to maintain the jvm\lib\ext directory (or we forget to move the jars after the development phase).

      Is it possible to dynamically read the jvm\lib\ext directory from the server/localhost depending on where the application is located ?(local ext directory/or on server) when opening an agent/library in the Designer? this would prevent java errors when modifying agents that imports packages located in the ext directory on the server but not in the ext directory on the local machine

      (today youo need a 1:1 mapping of the files in the ext directory if developing in Domino Designer)

      /Fredrik

      10Richard Schwartz  10/09/2007 9:17:59 PM  What if....Java in Domino were better?

      No more recycle.

      Mac support. (I hear that's coming, finally.)

      No more recycle.

      Pluggable JVM.

      No more recycle. I realize that this might be incompatible with pluggable JVMs, but maybe not. It's always bothered me that I have to stick with the built-in JVM, but it doesn't give me any specific advantages. Make it give us an advatage! If you use the standard JVM, you don't have to recycle. If you use an alternate JVM, you do have to recycle. That seems a fair trade to me.

      The same JVM and classes available across all platforms. Not sure what the story is with 8, or even 7, but I know in the past there have been JVM version differences and/or differences in the standard classes that are available on, say, iSeries or Linux vs. Windows.

      And did I mention, no more recycle!?

      11Edith Birrer  10/10/2007 2:54:21 AM  What if....Java in Domino were better?

      Things I have missed in the past or I had problems with:

      1) A decent XML parser - but that's fixed in ND8, I heard.

      2) Scheduled agents that are loaded into memory and then run from time to time and keep their status between runs (not as now with unloading/loading every time). Much like a the Java TimerTask class does.

      3) Good image processing (for example to shrink images the uses imports or the like) - I don't know whether this one is also addressed in ND8? Or maybe it's just the problem that Java in Domino is always "one version behind": see 4)

      4) As mentioned in 3, the Notes/Domino JVM is one version behind the Java world. Things that are easily done in Java outside Domino can "not yet" be done inside Domino. Unless, if you are lucky, you can import additional jarfiles which - if you are even luckier - can be used with the Java version of Domino. I understand the reasons for an "old" JVM being delivered with ND, but it would be great to choose the JVM for Domino, or somehow upgrade it to a newer version.

      12Ralf M Petter  10/10/2007 3:49:16 AM  What if....Java in Domino were better?

      I think the biggest problems for the java Developer in the notes environment are that there are so many bugs and restrictions that no one at Lotus really wants to fix.

      Two examples:

      Modal Swingdialogboxes in java Agents are staying in back of the NotesWindow when you change from another application to the Notesclient. It looks like the client hangs, but you can switch with Alt+Tab to the Modal Dialog. I like the idea to imporve the notes client UI with Javaagents, but this bug makes it pretty useless and i do it only if there is no other possibility. I have discussed this issue with several Developers on the DNUG 2006 in Karlsruhe and i have sent a Demodatabase to Maureen Leeland, but with no answer up to now.

      When you call java classes with LS2J you can not access lotus.domino.* classes from the called class. LS2J is really a very nice idea, but with this restriction it is also pretty useless.

      Please, please improve Java in Notes, because i think that Java and Notes can really be a dream team if the bugs ans restrictions will be fixed.

      Ralf

      13Stephan H. Wissel  10/10/2007 3:54:41 AM  What if....Java in Domino were better?

      - Fix the memory leaks

      - No more recycle

      - Init-treat improvements

      - a UI Object a java agent can communicate with

      - Persistent agents (agent-servlets)

      - Some of the stuff Beck et al has opensourced

      - No more recycle

      :-) stw

      14Kerr  10/10/2007 8:41:36 AM  What if....Java in Domino were better?

      Hi Bob, it was good to meet you in London a few weeks ago. This is the quick list:

      Quicker updates to the JVM. Discreetly upgradeable if possible, but if a point release upgraded the JVM that would be OK. I can't see any reason why that would cause a problem as long as the JVM was backward compatible, which it should be.

      Database scope classloader for loading jars bundled with the db. Agents using those jars would not need to reload them.

      Mechanism to allow long running agents, i.e. initialise once and then stay in memory. There are lost of angles to this and is linked to discussions around "Son of Garnet".

      Revamped Java API, designed from the ground up to look like a modern Java API rather than a port of the LotusScript API. Get rid of requirement for recycle in the API.

      Low level Java API. Let me do anything I can do with the C API with Java. Again this should be designed from the ground up as a modern Java API rather than a simple wrapper round the C API. Let me register server add-ins that uses this low level API.

      One of the tings that I end up doing again and again is to wrap a business object around a document, normally specified by a form and accessed through a specific view. What I'm essentially trying to do here is to add behaviour and a nice business specific OO interface onto a class of document in my app. It would be nice if Domino could take a lot of that legwork away in a standardized way.

      15Scott  10/10/2007 5:56:25 PM  What if....Java in Domino were better?

      Lots of good suggestions and yes I would also like to see the recyle dropped, the performance improved, the JVM being pluggable and making servlets as easy as a Notes agent / web service would be very cool.

      Mostly I've always wanted Java extend into the Notes UI more. UI objects for Java would be great and if this let me code in java completely then fantastic (not that LotusScript is bad, but the lack of full on OO support is very irrating at times). Then when there is a requirement to do something in the UI (typically network related) that requires Java being able to simple do it without LS2J wrappers etc would be brilliant.

      And as a finally thought .. making available the eclipse based UI widgets to a Notes application could have possibilities... but I haven't really thought that one through much.

      Basically if the Java support in the designer is going to be as good as I think it is, then I think designers will be using Java far more frequently, sort out some of these 'niggles' and you'll be onto a winner..

      16Darren Duke  10/10/2007 8:34:51 PM  What if....Java in Domino were better?

      Ditto, no more recycle

      Ditto, stability

      Ditto, pluggable JVM

      Ditto, UI classes

      Ditto, persistent java agent objects and session management (outside of the rather dated servlet engine)

      17Dwight Wilbanks  10/11/2007 8:59:03 AM  What if....Java in Domino were better?

      Will the "better java" be comming before or after the lotusscript class editor? Or COM object property browsing in the debugger or strong types for COM objects, with typeahead?

      That impact my answer dramatically. If you're really killing off lotusscript, then java needs to be able to "take over", and the needs for the java fix list needs to be able to concider more than if its just an alternative.

      If your are killing lotusscript then a syntax tranformation utility is essential in the java implementation.

      I know, I know, the IBM montra is that they are not killing lotusscript, but the words don't match the actions. It's being killed by neglect. What is it called when someone says one thing but does another?

      18Steve Nikopoulos  10/11/2007 9:53:57 AM  What if....Java in Domino were better?

      Great feedback! Thanks everyone. I always knew that there were people out there that wanted more capabilities with Java and Domino. Here are some specific responses to comments:

      -> "I always wanted to do some stuff with Applets, but..It was ALWAYS a nightmare. The applet might run in the browser, but in the client, it wouldn't. Could not find some files, JAR, or whatever... Jar,Applet should be placed in the Notes database and simply just work, without the weird dialog with Base Directory etc."

      It has been our working assumption that the ship has sailed for Java applets in the browser. Interesting to hear that this may not be the case. I don't know about the problem with the "Base Directory dialog". It would help if you could add more details.

      -> "Domino 7 provides web services ... It's awesome and I want to thank you for it. However, the consumer implementation..."

      Glad to hear you like it! But, in fact we did not deliver the web services consumer feature until the 8.0 release. Take a look at script libraries where you can import a WSDL document and have stub code generated right in the script library.

      -> Thoughts on the "need to have a pluggable jvm":

      There are a bunch of technical issues that we need to work out to make this happen. I don't know yet if it is "impossible" because the JVM is deeply nested inside many of the server processes and in the notes client. Perhaps it would be good to get some ideas on the level of support that IBM ought to provide in these kind of configurations?

      -> A comment on the need to eliminate recycle():

      We have had preliminary talks with the JVM lab inside IBM about this problem and it appears that Notes is not the only one API that have exposed this kind of curse on their developers. I understand that SWT has a similar model as Notes. Both have a bunch of C/C++ code being called from Java. SWT uses the dispose() method to recycle their native objects, similar to the Notes recycle() method. But, it seems likely that we can make some improvements on this.

      19Brian Miller  10/12/2007 11:19:17 AM  What if....Java in Domino were better?

      I think that Stephen covered everything very, very elegantly.

      The one thing that I would add is this: Notes developers should *never* have to manage threads in Java. I'm OK with it being available to people who want to go there, but I want to be able to completely ignore the whole concept, and just have Domino handle it.

      For example, "Session s = new Session();" should just work, in exactly the way it does in LS when you use "Dim s As New NotesSession". There's a monolithic session singleton, and using "new" creates an object with a reference to it. I shouldn't have to start or end threads to get access to a Session object. The system should "just know", and start a thread silently in the background as it's needed.

      One other thing that I would add is that I'd like it to be easier to do things with JDBC. What might solve this is the change to the security context that everyone is referring to when they say "persistent" or "agent-servlet". Once you load a class, if should be accessible but multiple runs of the same agent, and perhaps other agents. It's not an easy problem to solve.

      Adding to that, an integration point with Hibernate (or, one of the lesser-known alternatives) would be really kick-ass. It's less of a "fix-it-now" priority, but it would make enterprise connectivity much more usable and helpful.

      Another point: We should never have to put anything in the lib/ext directory to make it work. Stuffing classes into a Script library should be all we ever need to do. If you look in the knowledge base, there are a lot of workaround that tell people to use the lib/ext directory.

      Last: When people say "UI Objects", what they mean is this: Everywhere that you can use LotusScript today, you should also be able to use Java. It's that simple - and, no doubt, that complicated on your end.

      20Dan Sickles  10/12/2007 1:29:27 PM  What if....Java in Domino were better?

      "Everywhere that you can use LotusScript today, you should also be able to use Java." - Yes, complicated. I'd settle for it working with the SWT stuff and not with the old render code (which should go away over time anyway).

      21Daniel Lehtihet  10/13/2007 3:21:33 PM  What if....Java in Domino were better?

      When using java agents today (Rel. 7.x and previous versions) one often gets to a stage where these agents make the http process die a slow death, no matter if the agent code cleans up after itself (i.e http waiting for thread........ shows up in the console when you try to quit the HTTP process). It would be great if there were mechanisms built in that could "clean up" orphan threads after a certain amount of time. Today, i don't think that the java support in Domino is very reliable.

      22Christian Voigt  10/13/2007 4:16:40 PM  What if....Java in Domino were better?

      Java is the most powerful language currently supported by domino.

      - Access to an almost unlimited number of frameworks/libraries

      - Access to state of the art tools

      - Support for unit-testing

      - Javadoc

      In short. Everything useful that @formula and LotusScript have not.

      Therefore I'd like to see:

      - All events (UI, Field initializations, ...) programmable by java

      - Easy integration with with Unit-Tests (e.g. agents)

      - Easy integration with standard profilers

      - Faster adoption of current JREs

      - Support for servlets (current API)

      I don't mind recycle ;-) Since R7.0.2 it works for the first time in all those years.

      23Bob Balaban  10/13/2007 8:42:55 PM  What if....Java in Domino were better?

      Greetings, Geeks!

      Once again, thank you so much for your thoughtful (even if not entirely positive) feedback. Really appreciate it! Here are my replies and counter-comments:

      @1 - I agree with Steve, we're pretty much assuming nobody wants to use applets anymore (except in a very few cases). I hear you about the deployment issues, this is something we should address.

      @2 - See my post on "Remember Garnet", what you are describing sounds like servlets to me.

      @3 - Have you tried the Web Service consumer features in Notes 8.0? I find the UI a little strange, but the functionality is very good.

      @4 - See my comment for @2

      @5 - A number of very serious-sounding issues here. Have you submitted any PMRs on these? If so, please email me the numbers, I would like to follow up and see what (if anything) became of them. If any were erroneously closed, it may be possible for us to re-open them.

      @6 - The issue on JRE selection is really one of testing, it is enormously expensive to fully QE a new JVM version. We are thinking about ways of making the situation better, however, although it is very complicated. Of course, in Eclipse you can configure any JRE you want to use with any target runtime. Try experimenting with this way of doing it, and see if it "just works", or if there are major problems (and if there are, please let us know about them!)

      As Steve wrote, we are working with the IBM JVM team to see if they can give us some better ways of doing things. In the best possible case, we would be able to get rid of recycle() as well as make other improvements. We don't yet know how likely that is to be achievable, however, or when.

      Regarding collection classes, when notes.jar and ncso.jar were invented, Vector was pretty much the only choice. Now, of course, there are lots more options, and better performing ones, too. The problem now is, if we made unilateral changes to (say) return an ArrayList instead of a Vector, it would break all kinds of existing code, and we try to never do that (unlike some other software companies I could name....). Another option might be to provide alternate implementations of the search and query and iteration methods (of which there are a lot), but to tell you the truth, I would rather allocate effort to adding/exposing new functionality instead of "improving" existing stuff. Judgment call, but that's how I would vote.

      @8 - I'd like that too :-) We're working on it, but no promises just yet. Pooling solutions exist (I wrote one at Looseleaf a few years ago), but it's not a panacea. Ping me offline if you want more details

      @9 - Can you be more specific about what you mean by "binary output in java agents"? I think you can do that now, but I'm not sure what you really have in mind

      @10 - So, Rich, are you saying you're not a fan of recycle()? Just checking, your post was a little ambiguous....

      @11 - Re; Agents, see comment to @2

      @12 - Well, I really can't remember the last time I heard a colleague say "I don't WANT to fix that bug". We WANT to fix EVERY bug, but we can't always do it. The 2 that you mention do sound rather serious. Were they reported? Can you please send me the PMRs?

      @13 - Stephan, same request to you as to the others -- please send me PMRs, I will investigate.

      @14 - Hi Kerr, great meeting you, too. Classloader suggestion is a good one, needs investigation. Long-running agents == servlets (IMHO), see the Garnet post (as I said to @2). Rewrite the Java api for cosmetic reasons? Simply not going to happen, I'd fight long and hard to invent new functionality before wasting time re-implementing stuff we already have. As for more CAPI exposure in Java, we do have plans for that. The problem is, without a generic "native" call-out mechanism to C that doesn't require a hand-crafted intermediate layer (which Java does require today), and one which furthermore handles pointers and callbacks, it's pretty slow going to do that, very labor intensive. But we do plan to make progress in that area.

      @15 - Java UI stuff, yes, IMHO very important, especially now that we have an Eclipse-managed (Java) UI framework. Too soon to talk about specific plans or details, but we are looking very hard at this.

      @17 - "Will the "better java" be comming before or after the lotusscript class editor?" Too soon to say. Maybe they will happen at the same time, maybe not. I sure would like that to be the case, but I can't promise it.

      I started saying this within 15 minutes after we shipped a Java API for Notes 4.6 in 1997, and I guess I will just have to KEEP saying it: We are NOT killing off LotusScript. Really. Not happening. Even if you're the most cynical, battle hardened developer , used to being treated like dirt by some of our competitors, I think you have to admit that we would be incredibly stupid to "kill off" a language that we own, and that forms the basis for the business logic in most of our shipping templates. We might be dumb about a lot of things, but we're not THAT dumb. Ok? Can we stop talking about killing off LotusScript now?

      @19 - The problem with threads in java is that the language mostly forces you to be aware of them. I desperately want to make thread management easier by getting rid of the need for Notes/Domino developers to never again have to worry about init/term (by the way, if you just use NotesThread instead of Thread, then you mostly don't have to worry about it, but that isn't always possible). We're working on it, too soon to report significant progress.

      A couple of questions for you: What is it about JDBC that you find difficult to use? Re; Hibernate, what are your use cases for that? Can't you just drop a JAR file on N/D and use it?

      I agree with you about the lib/ext deployment trickiness. I don't like it either.

      @21 - Daniel, do you have any PMRs related to this? I would like to investigate further. TIA

      @22 - WHAT!!?? You "don't mind recycle()" ?? Well, I do :-)

      24Ralf M Petter  10/15/2007 2:27:29 AM  What if....Java in Domino were better?

      @23 The PMR for the problem that you can not access Notes Object from code called by the ls2j is PMR# 90221,060,618.For the problem with the modal dialogs we have not created a PMR. I have discussed this problem on the DNUG 2006 with some Developers and then i have sent a demo database to maureen leeland in may 2006.

      If it will help, i can create a PMR for the modal dialog problem.

      25Jesper Kiær  10/15/2007 4:29:00 AM  What if....Java in Domino were better?

      @23 OT Applets

      I agree that Java Applets rightfully are having a hard time in the web browser, because other lighter solutions have emerged, like AJAX.

      The Notes client does not support xmlhttp, so instead you could use an Applet to do the same things there. This means you could do live updates of fields on a open document etc.

      What about Java Applet Charts (like JFreeChart)in a document?

      Maybe Java Applets shouldn't be considered dead just yet :-)

      26Tim Siney  10/15/2007 4:55:09 AM  What if....Java in Domino were better?

      Bob, if you let me know your email address I'll contact you regarding my issues.

      27Wayne Sobers  10/15/2007 10:02:55 AM  What if....Java in Domino were better?

      You should also take into account that not everyone will be able to use the "standard" client - we can't.

      If the basic client handled Java applets natively it would allow existing solutions to be integrated and allow for alternate methods of "view" presentation.

      28Thomas Bahn  10/15/2007 4:38:28 PM  What if....Java in Domino were better?

      We are doing a lot of Notes client development, for which we have built an extensible LotusScript OO framework.

      There are heavy restrictions on object-oriented programming in LotusScript, like no interfaces, single-inheritance, no method overloading (same name, different parameter signature), no namespaces/packages, no class members (Java: static), etc.

      I would really love to jump to Java for the Notes Client application development (especially with a IDE like Eclipse).

      The main reason, we can't use Java are the missing UI classes.

      Thomas Bahn

      { Link }

      29Axel Janssen  10/16/2007 4:00:24 AM  What if....Java in Domino were better?

      Mock Classes for the lotus.domino classes would be great. Actually I started to write it for myself.

      This is targeted to write unit-Tests for own classes which use lotus.domino classes. Having such mocks has a great potential to drastically fasten the development process of Notes Java-Agents.

      For example Springframework has own mocks for lots of their classes: { Link }

      A mock for lotus.domino.Document could look like that (excerpt):

      package de.aja.notes.mocks;

      import lotus.domino.Document;

      public class DocumentMock implements Document {

      private Map itemValueMap = new HashMap();

      public void addItemValue(String name, Object value) {

      itemValueMap.put(name, value);

      }

      public Vector getItemValue(String name) throws NotesException {

      Vector ret = new Vector();

      Object val = itemValueMap.get(name);

      if (val != null) {

      ret.add(val);

      }

      return ret;

      }

      public int getItemValueInteger(String name) throws NotesException {

      Vector vec = getItemValue(name);

      if (vec.size() == 0) return 0;

      Object firstEntry = vec.get(0);

      if (firstEntry instanceof Number) {

      if ((firstEntry instanceof Double)|| (firstEntry instanceof Float)) {

      return ((int) Math.round(((Double)firstEntry).doubleValue()));

      } else {

      return (int) ((Long) firstEntry).intValue();

      }

      } else {

      return 0;

      }

      }

      }

      30Axel Janssen  10/16/2007 4:04:16 AM  What if....Java in Domino were better?

      With Mocks one can develop unit-tests for classes which uses lotus.domino.* classes without any communication with Domino. Just mock-implementations of the interfaces of the public java api of lotus-notes.

      31Kerr  10/16/2007 6:48:30 AM  What if....Java in Domino were better?

      @23, of course everything has a priority and that's as it should be. However, I'd like to clarify that I think that developing a modern Java API would not just be cosmetic and if done correctly would be a huge boost to developer productivity while using Java in Domino. The language hasn't remained static and increasingly the Java API to domino is looking like a bit of a dinosaur.

      Re garnet/servlets, I made several comments on the remember garnet post. I've gone back and reread them and pretty much stand by comment 100. I'd love to know what you are planning in this area, but as an outside observer I get a little worried when I hear "Long-running agents == servlets (IMHO)". I really hope there is more to it than that.

      Ah, to be on the design partners list for this... ;)

      32Daniel Lehtihet  10/16/2007 10:16:00 AM  What if....Java in Domino were better?

      Hi Bob,

      There are several documents regarding this in the Lotus Support database (search for "HTTP Waiting For Thread"). Lotus QE has not been able to reproduce this problem. I've seen it a lot in the past on 6.5x on AIX 5.3.

      I will try to reproduce it on 7.02 under AIX 5.3 before i enter a PMR with Lotus/IBM. I'm guessing that when agents repeteatly gets called and managed by the HTTP process (instead of the AMGR), then server is unable to free the allocated resources somehow.

      33Axel Janssen  10/17/2007 4:05:42 AM  What if....Java in Domino were better?

      I don't see a pressing need to develop a new dev-enviroment for Notes Agents.

      The process to develop agents or java-scriptLibraries (not to confuse with javaScript-scriptLibraries) in Eclipse and pulling them from notes as deployment platform via edit project / pointing to src folder in Eclipse project actually works quite well. When I have time, I am going to try to write an ant task which pushes into notes from Eclipse. This shouldn't be too dificult as the code of Domiclipse allready solves this.

      Again: From my pov Lotus should take a closer look on the development process. Local debugability from the development IDE, local traceability from the development IDE without any dependencies on a running Notes-Process.

      I've heard strange things in forums. Organisations with n developers who all use domiclipse and export their stuff to notes without any synchronization. This doesn't work, of course. But people lack a clear direction about a sound development process. They read about new tool on blogs, use it in a way it was not intended and end up frustrated.

      34Samuel deHuszar Allen  10/18/2007 1:38:57 PM  What if....Java in Domino were better?

      I would like to chime in on support for the ability to use external JVMs. Especially as the open-source community has more playtime under it's belt with the new open-source java implementation, I think Java performance in general will begin to skyrocket. It would be nice to be able to harness that in ND.

      I also think that as Symphony gets brought up to the more Java-heavy OOo 2.x codebase, the ability to use non-IBM JVM's will make it much easier to drop code in without a lot of (or at least less) tweaking.

      35Erik Brooks  10/18/2007 3:09:59 PM  What if....Java in Domino were better?

      @32 - 7.0.3 was just released. There are many associated fixes listed in the Fix List database related to java and agent resources (primarily memory leaks).

      36Fredrik Stöckel  10/19/2007 10:49:16 AM  What if....Java in Domino were better?

      @23 - Bob, the only (official) way to print stuff to the web-browser from an agent is through the getAgentOutput() method that returns a standard PrintWriter. The PrintWriter is OK for regular textual output.

      But if I want to return for example a pdf-file directly to the browser, I need a stream or something that plays nicely with byte arrays:

      StringBuffer sb = new StringBuffer();

      sb.append("Content-type: application/pdf; Charset=UTF-8\n");

      sb.append("Content-disposition: attachment; filename=" + filename +”\n”);

      sb.append("Content-Length: " + PDFBytes.length + “\n”);

      sb.append("Accept-Ranges: bytes\n");

      sb.append("Content-transfer-encoding: binary");

      sb.append("Connection: close");

      getAgentput.println(sb.toString());

      BufferedOutputStream out = (BufferedOutputStream) getAgentOutputStream();

      out.write(PDFBytes, 0, PDFBytes.length);

      The problem is that the getAgentOutputStream() returns a stream (a printstream?) that defaults to the platform standard charset (I think), and it might (will) corrupt the output to the browser.

      I can of course take my byte array and write it to disk (as a file) (this is how I do it today) and then use the standard PrintWriter to redirect [] the user to the newly created file, but the extra round-trip to disc/and clean-up of old files and extra i/o is exactly what I’m trying to avoid.

      This is something what might be very useful in a lot of situations.

      37Bill McCuistion  11/08/2007 11:09:46 PM  What if....Java in Domino were better?

      Bob, You might want to take a look at how Intuit is dealing with the issue of multiple SDK's for a common-core application, namely the QuickBook SDK.

      The QB-SDK and ND-SDK issues are very similar, at least from this developer's viewpoint: Multiple client versions, multiple releases, multiple OS/Hosting environments, etc.

      For years, the QB-SDK provided separate SDK-Tools for each release/platform. This was a night-mare for the developer (e.g me and others like me). Most recently, with QBSDK-2008, there is an "Integrated SDK", which does a good job of mapping the differences in the nuances of the data-structures, methods and functions between the various SDK branches. For them, this is V1, but represents a milestone on branched SDK reconciliation.

      I have the same basic issue w/r/t the IBM/Lotus Notes-Domino SDK alternatives (LS/@Formula/Java/etc) languages.

      Although I have very significant issus with how Intuit implemented their "On-Screen Reference" (OSR) via JSON/AJAX, the attempt is good, at least for a R1 effort. I'm sure they will fix the anomolies soon and make the framework work.

      From the QB-SDK JSON data, I have constructed a series of several hundred QBXML messages with the "Green/Yellow/Blue/Green" indicators to inidicate variance from a "base-reference" "conformance profile".

      For the IBM/Lotus ND* SDK, it would be perhaps useful to construct an XML-based framework that would assist in the reconciliation of the various SDK/Language/Platform/UseCase options in the ND* world.

      Although the Notes "Help" system does a fairly good job of x-refing languages, it is not "data processing friendly", which leads to confusion during both the IBM/Lotus SDLC and the IBM/Lotus Developer/Architect/Administrator SDLC.

      Contact me directly if you want to explore.

      Sorry for the late post.

      OBTW - To answer your question - The ND/Java API should simply comform to the ND Object Model, and behave like any well-behaved Java API.

      If you have a solid ND Object Model, you could support an API for every language, including Fortan (eh!).

      38Bjørn Cintra  11/23/2007 8:24:32 AM  What if....Java in Domino were better?

      I'm late to the discussion (as always), but I have only one thing to add to what the others have already said:

      Groovy!

      Having support for the Groovy language from inside Domino would be great ;)

      39Dietrich Willing  11/28/2007 12:04:24 AM  What if....Java in Domino were better - LS2J improvements

      I've been using LS2J to create PDF files using iText recently. What I consider improvements are,

      1. Better help files. For example, when sending an array to Java, it must be a fixed array, ie Dim myArray(4) As String, not Dim myArray (0 to 4) as String.

      2. You can't reference a package or class in another Library in the Java Library you are calling. Lotus Notes crashes.

      Say you create a Java Library you call by LS2J. If you add a jar file using the 'Edit Project' button, all is OK. If your jar file has been added to another Java Library and you add that Java Library, Lotus Notes crashes.

      If this can't be fixed, then please extend the string capacity of the ini variable JavaUserClasses (currently 256) or add another ini variable that does the same thing. This would help those situations where a server has many databases that require references to jar files.

      40Simon  06/10/2008 9:43:59 PM  What if....Java in Domino were better?

      Very late to this:

      A reason why we 'need' persistent objects in java agents is

      a) You can't use servlets as web query save

      b) You can't use servlets as web services, well... ok you can but now that you have a Web service data type having persistence across calls would be sensational. I am sure domino WebServices are just wrapped up agents =)

      Currently lack of persistence is my single greatest problem

      Simon