Hello Roger, > As a matter of interest what problem exactly do you have with NestedVM? > It's output is indeed opaque (not human comprehensible) but the same is true > of Java source versus bytecode. In both cases the input source is readable.
When I first tried to use NestedVM for our needs (long time ago) it had a problem with file paths, in particular on Windows only those paths were working that resided on a drive C, paths with other drive letters didn't work (drive letter was truncated from a path at some moment). As I recall the problem was deep inside NestedVM code and it took significant amount of time for me to figure out what the problem is and then I recall I wasn't able to fix it more or less fast, despite the issue itself is minor. The bug itself was not the reason for not using NestedVM, but rather revealed (for me) what I called "opaqueness" - any, even minor issue in the NestedVM or code it executes would be uneasy to locate and to fix and as I understand it would not be clear whether the problem is in NestedVM code or in the code it executes. Having a library that you may "debug" into and read without efforts if needed (even if you know C, if you're deep in Java development process it is not that easy to switch) and that fits the existing infrastructure (Java in our case) seamlessly is one of the main reasons we decided to implement SQLJet instead of using NestedVM. Also, more emotional reason rather than logical one is that having a VM inside another VM gave me a feeling of something cumbersome at the moment. There also were reports that NestedVM-based JDBC driver is slow, comparing to the native one, and, I suppose, Java implementation has more space for optimization comparing to object-code execution engine. Last, but not least, Java implementation gives us an opportunity to add custom features to the database engine either breaking or keeping compatibility with SQLite database format (this reason has no relation to NestedVM of course). I like to repeat though that I think of NestedVM as of a brilliant idea and implementation, and I believe most of the users are happy with it. -- Alexander Kitaev, TMate Software, http://svnkit.com/ - Java [Sub]Versioning Library! http://sqljet.com/ - Java SQLite Library! Roger Binns wrote: > Alexander Kitaev wrote: >> Not to depend on native SQLite binaries or >> opaque NestedVM code, > > As a matter of interest what problem exactly do you have with NestedVM? > It's output is indeed opaque (not human comprehensible) but the same is true > of Java source versus bytecode. In both cases the input source is readable. > > It would also be interesting if anyone has built something that comprehends > the SQLite C source and then does the conversion into other languages based > on that. It would make updates a lot easier, the generation of instrumented > and test code easier, and the search for issues or optimisations easier. > > Roger _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
