1 Library emulation: combating library aging Fabio Corubolo London, December 3 rd 2009

3/12/20092 File format obsolescence File formats eventually become obsolete This normally happens as software change and old format are eventually dropped Some solutions have been proposed to solve the issue

3/12/ Data format preservation: solutions How can we preserve access to documents and data formats?

3/12/20094 Multivalent approach for Digital Preservation MV is a framework for document parsing and display Aims to support any doc format Media parsers in pure Java, no native method to maintain architecture independence Direct access to the original formats with the JVM JVM is well specified, has multiple implementations Media parser source code can be good representation information

3/12/20095 Media parsers: limitations Writing media parsers is expensive It would be better to reuse existing code Java libraries are many, but don't cover all; C and other language libraries are some times essential Some libraries can be considered reference for decoding a type of data Hard to recreate the same decoding feature/bug by feature/bug

3/12/20096 Library emulation Why not use existing software to compile native (C, Pascal, Fortran) libraries directly to Java code? Two open source examples already exist:  NestedVM (Brian Alliet, Adam Megacz)  Cibyl (Simon Kågström) Based on the concept compiling to MIPS architecture, and mapping MIPS instructions to Java code or bytecode MIPS instructions map well to Java bytecode

3/12/20097 Library emulation Why not use existing software to compile native (C, Pascal, Fortran) libraries directly to Java code? Two open source examples already exist:  NestedVM (Brian Alliet, Adam Megacz)  Cibyl (Simon Kågström) Based on the concept compiling to MIPS1 architecture, and mapping MIPS instructions to Java code or bytecode MIPS instructions map well to Java bytecode

3/12/20098 Compiling libraries using NestedVm An adapted GCC toolchain Supports GCC C, C++, Pascal, Fortran Converted software is bug to bug compatible to the native A libc and a Unix runtimes implement most kernel and posix features, so many libraries can just be compiled with no modification (SYSCALLS)

3/12/20099 DEMO

3/12/ Results Added Jbig2 support to PDF in pure Java: speed comparable to an existing Java library Also: libtiff, libfreetype 2, libjpeg, zlib, libmspack Time required for getting the build to work is a small fraction of creating a new Java code library

3/12/ Pros Simple, low effort method to make sw and libraries live longer Cross platform Bug to bug compatible Easy to update as library evolves Results can be simply included in external workflows Easy to test correctness with the native libraries: same inputs and outputs

3/12/ Cons A performance hit of 2-10 X A complex build process can require tedious manual patching Works on a subset of the existing software libraries

3/12/ Conclusions Why not use this now? Simple solution: archive the Java compiled library for future access and use in other platforms Very interesting when supporting a variety of rare data formats Performance hit will be less significant when compared with data loss

14 Acknowledgements The Shaman project is partially supported by the European Union under the Information and Communication Technologies (ICT) theme of the 7th Framework Programme for R&D (FP7) This document does not represent the opinion of the European Community, and the European Community is not responsible for any use that might be made of its content.