java.io.File doesn’t work as expected in Domino FP7 and newer versions

I found this error in a java agent first. If you detach a file from a Notes document using Domino Classes and try to get a handle on the file using java.io.File the file isn’t found until you do a new call against the server. I don’t know if this has to do with the change of Java version server side or not but the same code works in FP6.

Code Example

Body.extractFile(strFileName);
File objInFile = new File(strFileName);
if(objInFile.exists()){

But if you go and use java.io.File in an XPage it will not find a file until you reload the page completely, it seams to work fine in FP6 but not in newer versions.

I have tried this on Window 64bit version of Domino 9.01fp6, 9.01fp7 and 9.01fp9

Anybody else seeing the same problems please report against the problem
SPR # PALTAQQLXH / APAR LO92928

If you want to test it in a database let me know and I can supply a sample database

Have you experienced any other bugs related to the Java upgrade?

  1. In my testing, it looks like the bug is in Item#getValueString(). For an attachment named “Untitled.png”, it came back with a 42-character string containing the name followed by a mix of non-printing characters and seemingly-random letters. The LotusScript version (using item.Values(0)) doesn’t have this trouble. I’d guess the Java string construction in lsxbe land is chomping off extra bytes in memory.

    But, on the plus side, the specific sequence of extractFile + java.io.File seems to be unaffected – it’s just a casualty of this other bug.

Leave a Comment


NOTE - You can use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This site uses Akismet to reduce spam. Learn how your comment data is processed.