|BTree J2ME Download|
|Home||BTree Guide||BTree Performance||Sample Applications||BTree Roadmap||Other Products|
The JSR75 extension was recently added to the Java standard. This allows standardised access to file systems on mobile devices. The presence of this standard allows Virtual Machinery to offer a Btree implementation that is closer in behaviour to the standard file-based trees implemented in the J2SE and J2EE environments. There are however a number of significant caveats associated with using JSR75 -
The BTree file format used in the JSR75 implementation of our BTree is the same as that used in all our other BTrees. By using the socket communication mechanism supplied in the distribution you can file out your BTree to the external file system and access it with any other BTree applications that you have including the BTree Toolkit (see details here). You can also use the same socket mechanism to load an external BTree into your J2ME environment.
From a Virtual Machinery perspective the same restrictions apply to JSR75 based BTrees as those on the J2SE and J2EE platforms (i.e. maximum page sizes of 64k and a maximum of 64k pages) however these limits will be reduced by the device on which you run your BTree implementation e.g. file size, available space.
Caching is implemented in the JSR75 implementation as for all our BTree implementations. Caching does not neccessarily make sense in a J2ME environment as at present almost all J2ME devices use 'high speed' (and I use that term advisedly) RAM for all of their storage so in theory caching the index pages (as advised for J2SE and J2EE based BTrees) may make little difference and may in fact worsen the situation as both the 'cached' and the 'filed' page are using up the same (precious) memory. However it is likely that as device memory capacities increase there may be a distinction between 'fast' memory as used by a Java application (and the cached page) and slower long-term storage media as used by persistence mechanisms like JSR75. In the long term some J2ME devices are likely to have small disk-drives. It is difficult to give general advice in the J2ME world as devices do differ over a very wide range so I would suggest trying caching over the range of your target devices and making an empirical judgement.
The implementation has the small footprint neccessary for small devices - 38k for the full function jar and 25k for the Read-Only jar. It also provides tools to pass BTrees to and from the outside world over socket connections. The BTrees are saved to the file system using Virtual Machinerys standard BTree format which means that you can use the BTree Toolkit to carry out a number of operations on your BTrees including compression, validation, export, import and viewing of BTrees. All of the tools run on the Java platform and have been tested on a wide number of platforms including Windows, Mac and Linux.
You can find out more about JSR75 here.