I wanted to try the Document.setPreferJavaDates today and see how it worked.
I called Document.setPreferJavaDates( true ); to ensure that no (Notes)DateTime objects were created as I didn't need them/didn't want to deal with recycling.
First I tried:
Document.getItemValueDateTimeArray( "fieldname" );
This returned a Vector of DateTime.
Then I tried:
Document.getItemValue( "fieldname" );
This also returned a Vector of DateTime.
The way that finally worked as expected (returned a Vector of java.util.Date) was this:
Document.firstItem( "fieldname" ).getValues();
I would imagine this is the least used method among developers wanting to get a date value from a field. This code was executed on a server running Domino 8.5.3FP2
Showing posts with label java. Show all posts
Showing posts with label java. Show all posts
Thursday, September 19, 2013
Friday, June 15, 2012
Recommended tutorials for doing asynchronous processing in beans
Asynchronous processing in Java applications – leveraging those multi-cores
Using asynchronous mechanisms in Java and JavaScript for improving the user experience
Using asynchronous mechanisms in Java and JavaScript for improving the user experience
Tuesday, December 13, 2011
ClassNotFoundException with the new Java design element
Last week Vince Shuurman blogged about having to recompile when opening an XPage app in Domino Designer.
I had the same issue. I was using some Java code in an XPage, and every time I opened the app in designer, I got ClassNotFoundException when opening the XPage. A build of the project fixed the issue.
My java code was in the new Java design element (new in Domino 8.5.3), so I suspected that it might have something to do with this.
I moved the code to a "custom" java source folder, and the error went away. Closing/opening the app in Designer did not result in ClassNotFoundException.
I had the same issue. I was using some Java code in an XPage, and every time I opened the app in designer, I got ClassNotFoundException when opening the XPage. A build of the project fixed the issue.
My java code was in the new Java design element (new in Domino 8.5.3), so I suspected that it might have something to do with this.
I moved the code to a "custom" java source folder, and the error went away. Closing/opening the app in Designer did not result in ClassNotFoundException.
Labels:
java,
random tip,
xpages
Friday, October 21, 2011
Java Debugging in Designer without hacks
I found this today: How can I enable Java debugging?.
Not sure if this is new in 8.5.3, but I never heard of it. It makes it a lot easier to debug than the using the two headed beast method which seemed like too much trouble.
The full instructions are in the Designer help. Search for java debugging.
Not sure if this is new in 8.5.3, but I never heard of it. It makes it a lot easier to debug than the using the two headed beast method which seemed like too much trouble.
The full instructions are in the Designer help. Search for java debugging.
Labels:
domino designer,
java,
random tip
Friday, October 29, 2010
LotusScript: Fast sorting of arrays using Java
If you want to sort large string arrays (>1000 items), LotusScript can be horrendously slow. Back in the day, I tried to use Java via LS2J. Unfortunately LS2J was so unstable that I went back to pure LS sorting.
The reason I'm so interested in efficiently sorting arrays, is that I use a token string array as a base when rendering various content in a CMS I maintain at work. Sorting big arrays in LS is, as said, slow. Sorting token string arrays, based on a specific token in LS is s l o w!
Then came Domino 8.5.2, and NotesAgent.runWithDocumentContext :D
Basically, it lets you send an in-memory NotesDocument to an agent (LS or Java), and modify it.
To the demoapp..
In the demoapp, I've created a couple of helpers that lets you sort arrays with the Java API (via a Java Agent). It supports (locale aware) sorting of "regular" string arrays, and token string arrays, based on a token
With 5-600 items in the array, Java beats LS, even when sorting by token. The more items, the bigger the difference.
With 10 000 items, running on my computer:
Java sort: 0.9 seconds
LS Sort (algorithm): 46 seconds
Java token sort: 1.5 seconds
Open the demoapp on the web to run the test on your system. Modify the (SortDemo) agent to test different array sizes.
>> Download DemoApp (demoapp is around 6MB, due to 40k+ documents)
Share and enjoy!
The reason I'm so interested in efficiently sorting arrays, is that I use a token string array as a base when rendering various content in a CMS I maintain at work. Sorting big arrays in LS is, as said, slow. Sorting token string arrays, based on a specific token in LS is s l o w!
Then came Domino 8.5.2, and NotesAgent.runWithDocumentContext :D
Basically, it lets you send an in-memory NotesDocument to an agent (LS or Java), and modify it.
To the demoapp..
In the demoapp, I've created a couple of helpers that lets you sort arrays with the Java API (via a Java Agent). It supports (locale aware) sorting of "regular" string arrays, and token string arrays, based on a token
With 5-600 items in the array, Java beats LS, even when sorting by token. The more items, the bigger the difference.
With 10 000 items, running on my computer:
Java sort: 0.9 seconds
LS Sort (algorithm): 46 seconds
Java token sort: 1.5 seconds
Open the demoapp on the web to run the test on your system. Modify the (SortDemo) agent to test different array sizes.
>> Download DemoApp (demoapp is around 6MB, due to 40k+ documents)
Share and enjoy!
Labels:
java,
lotusscript
Wednesday, October 7, 2009
Technique: Using a Page as a cross language template/string container
In this demoapp, I use a page as a definition for an XML-representation of a document. It is related to a project at work, where we send XML to a web service. This service is to be called both from the Notes Client, and from an XPage. I could script the XML in both the agent and the XPage, but this could easily develop into a maintenance nightmare.
In the demo, I've used the body of a page as a token string (separated by ¤). The first token is the field-definition. This is to be used in a formula evaluate towards a NotesDocument. The second part is the template itself.
By having the field-definition in the page, you just have to update the page if you want more field values.
I wrote three different script libraries, each having more or less the same functionality. One LotusScript library, one Java (Script) library, and one ServerSide JS library. The libraries contain functionality that extracts the body of the a page based on its name (using a NotesNoteCollection of the pages in the DB).
I also wrote a LS agent, a Java Agent, and a XPage (acting as an agent). Each of them prints XML (based on the template) for the first document in a certain view.

This technique can also be used if you have a big string that is used in code written in multiple languages. If it's Java-code you're writing, and need a big string, this may be an easier way to maintain the string. Another thing that occurs to me is if you generate the same XML/HTML/etc. in multiple databases, you can maintain the String-template in one database, and use Design inheritance to spread it (or get the page from another database using otherDatabase.CreateNoteCollection(false)... )).
As with all techniques, this might not be the right tool for your job. Weigh pros and cons before you decide to use it/not use it.
>> Download DemoApp (open the app in a browser to test the demos)
Comments/critique/bugreports are as always welcome. :)
In the demo, I've used the body of a page as a token string (separated by ¤). The first token is the field-definition. This is to be used in a formula evaluate towards a NotesDocument. The second part is the template itself.
"first_name":"last_name":"company":"address":"age"
¤
<character>
<first_name>[first_name]</first_name>
<last_name>[last_name]</last_name>
<company>[company]</company>
<address>[address]</address>
<age>[age]</age>
</character>
By having the field-definition in the page, you just have to update the page if you want more field values.
I wrote three different script libraries, each having more or less the same functionality. One LotusScript library, one Java (Script) library, and one ServerSide JS library. The libraries contain functionality that extracts the body of the a page based on its name (using a NotesNoteCollection of the pages in the DB).
I also wrote a LS agent, a Java Agent, and a XPage (acting as an agent). Each of them prints XML (based on the template) for the first document in a certain view.
This technique can also be used if you have a big string that is used in code written in multiple languages. If it's Java-code you're writing, and need a big string, this may be an easier way to maintain the string. Another thing that occurs to me is if you generate the same XML/HTML/etc. in multiple databases, you can maintain the String-template in one database, and use Design inheritance to spread it (or get the page from another database using otherDatabase.CreateNoteCollection(false)... )).
As with all techniques, this might not be the right tool for your job. Weigh pros and cons before you decide to use it/not use it.
>> Download DemoApp (open the app in a browser to test the demos)
Comments/critique/bugreports are as always welcome. :)
Labels:
java,
lotusscript,
templating,
xpages
Wednesday, April 1, 2009
Updated the TextToPNG-generator
Update 14.04.09: I added support for PNG transparency, and improved the vertical positioning of text to avoid clipping.
When I first made it, i called it a header-generator.
I actually needed something similar today at work, for a newsletter-application I'm working on. I added some functionality at work, and planned to release the updated version as is. I saw how horrendous the interface looked/wished for a little more functionality, so I added a little more functionality/freshened up the interface.
Old interface:

New interface:

>> Download DemoApp
Requirements to run the app: Domino 8.x (code written in Java 5)
Example images:




When I first made it, i called it a header-generator.
I actually needed something similar today at work, for a newsletter-application I'm working on. I added some functionality at work, and planned to release the updated version as is. I saw how horrendous the interface looked/wished for a little more functionality, so I added a little more functionality/freshened up the interface.
Old interface:
New interface:

>> Download DemoApp
Requirements to run the app: Domino 8.x (code written in Java 5)
Example images:





Monday, October 15, 2007
String to char-array in Java
For those curious Java versus LS. It's lightning fast:
String to char[]: 15ms, string length, 700 000
Added to the string concatenation "benchmark"
String to char[]: 15ms, string length, 700 000
Added to the string concatenation "benchmark"
String concatenation with a Java agent
Here are the results from string concatenation in Java:
Standard concatenation (75 000 concatenations): 192.594s, string length, 300 000.
java.lang.StringBuffer-concatenation (75 000 concatenations): 0.062s, string length, 300 000.
RTI-concatenation (75000 concatenations): 1.765s, string length, 300 000.
The best in LS, 75 000 concatenations, 0.25s. The numbers aren't directly comparable, as I'm running on different hardware than Julian.
By "Standard" concatenation, I mean bigString += string. Standard concatenation and RT-concatenation is slower in Java than in LS. Using Java's native StringBuffer class, is a lot faster than any of the competitors in LS (so far).
I'm not surprised that Java's StringBuffer beats Julian's array-based StringBuffer-class in LS, as Sun probably puts a lot more effort into optimization of the language than IBM does with LS.
My test ran on Notes 7.02, which I think runs version 1.4 of the Java runtime. Newer versions of Java may be even faster.
My Java-skills are mediocre at best. Let me know if my test-methodology is wrong in any way.
>> Code for the test
Standard concatenation (75 000 concatenations): 192.594s, string length, 300 000.
java.lang.StringBuffer-concatenation (75 000 concatenations): 0.062s, string length, 300 000.
RTI-concatenation (75000 concatenations): 1.765s, string length, 300 000.
The best in LS, 75 000 concatenations, 0.25s. The numbers aren't directly comparable, as I'm running on different hardware than Julian.
By "Standard" concatenation, I mean bigString += string. Standard concatenation and RT-concatenation is slower in Java than in LS. Using Java's native StringBuffer class, is a lot faster than any of the competitors in LS (so far).
I'm not surprised that Java's StringBuffer beats Julian's array-based StringBuffer-class in LS, as Sun probably puts a lot more effort into optimization of the language than IBM does with LS.
My test ran on Notes 7.02, which I think runs version 1.4 of the Java runtime. Newer versions of Java may be even faster.
My Java-skills are mediocre at best. Let me know if my test-methodology is wrong in any way.
>> Code for the test
Friday, October 12, 2007
Simple header-generator in Java
Not sure if header-generator is the best word for it.
Fonts aren't platform independent. An image of a font is.
Just a little experiment with Graphics2D in Java. JavaAgent running on WebQuerySave generates an image (and embeds it in the document) from header-text, selected font/-size. Also adds a shadow if desirable.
Width is currently hard-coded (400px), so the biggest fonts, with font-size set to 96 won't fit.
Fonts are @FontList. Since this is not available on web, I made a keyword-document containing the text-list of fonts. Not all types of fonts are supported, it seems.
I use a Java WQO-agent that sets a multivalue field containing all font names in GraphicsEnvironment.getLocalGraphicsEnvironment().getAllFonts(). This way, you should get the fonts available on your machine/server.
Header-images are saved as png in the systems tempfolder.
>> DemoDB
Examples:



Fonts aren't platform independent. An image of a font is.
Just a little experiment with Graphics2D in Java. JavaAgent running on WebQuerySave generates an image (and embeds it in the document) from header-text, selected font/-size. Also adds a shadow if desirable.
Width is currently hard-coded (400px), so the biggest fonts, with font-size set to 96 won't fit.
I use a Java WQO-agent that sets a multivalue field containing all font names in GraphicsEnvironment.getLocalGraphicsEnvironment().getAllFonts(). This way, you should get the fonts available on your machine/server.
Header-images are saved as png in the systems tempfolder.
>> DemoDB
Examples:
Labels:
java