Issue #10 resolved

Dropping pure-java support

Taro L. Saito
repo owner created an issue

Building pure-java version of sqlite-jdbc is now impossible due to missing support of gcc4.x in nestedvm, while sqlite compilation needs gcc4.x.

I would like to drop the support of pure-java version in future releases.

Even if we drop the pure-java support, we still can support many OSs because building native libraries has become much easier. Many cross-compilers are available in Ubuntu for building binaries for windows(mingw 32/64-bit) and linux (i686, amd64, arm, etc.). I tested them and it works great in another project (snappy-java). Mac version still needs some Mac machine, but I am a mac user, and have no difficulty in building for Mac.

As described in issue 9, build settings for pure-java version are a little bit cumbersome. The currently bundled pure-java library is based on an older sqlite version in which the build succeeded. That means we cannot catch up with the latest features of sqlite in pure-java version. Some feature works in native mode, but not in pure-java mode. I think it's quite problematic.

Comments (9)

  1. Carlin Desautels

    In response to issue 9 and this, may I propose that:

    • The pure java build is excluded by default
    • Adding a command to maven cli to enable the inclusion of pure java
      • $mvn -Dpure.java # something like this

    This allows you to make pure java a deprecated feature to eventually remove or focus development on later.

    Lastly with this proposal, I will assume that the pure java and native builds are not exclusive. By enabling pure java you are including it into the driver in addition to the native build versus replacing the native build.

  2. Taro L. Saito reporter

    I don't remember correctly but since some version (let's say it version X), pure-java build has been impossible.

    A reasonable release plan would be:

    • Publish a stable release, version X with both native and pure-java build.
    • Then, exclude the pure java build completely after version X
      • That means removing build native/pure-java switch in pom.xml, Makefile, NestedDB.c, etc.
  3. Anonymous

    What about a the iPad? At the moment only the pure-java version of sqlite-jdbc can be used. On the iPad the JamVM (Cydia) is used.

  4. Anonymous

    SQLite compile certainly doesn't require GCC 4.x. It should compile on any version of GCC that is C99 compliant. In fact, it will compile with C89 compliance, provided that the compiler additionally implements "long long".

    Perhaps there are additional issues introduced by sqlite-jdbc, but those are separate from what SQLite itself requires.

  5. Carlin Desautels

    After posting on the sqlite-dev mailing list asking for a minimum version of gcc, they responded with:

    The "SQLite" managed by this mailing list and website is pure ANSI-C code. ... And so there is no minimum version of gcc required. SQLite works on a variety of C compilers.

    And:

    i've compiled sqlite3 on several compilers in strict C89 mode, and the only minor portability problem i'm aware of is a single use of "long long" for the sqlite_int64 type. C89 does not specify long long, but most platforms seem to have it. AFAIR, gcc's ANSI compatibility was quite good even back in vsersion 2.95 (around the turn of the century), and it wouldn't surprise me to see sqlite3 compile on that compiler.

    This should be a problem with NestedVM and specifically its gcc version lock. The problem I ran into was during the creation of gcc 3.3.6 running $make purejava.

    To my understanding of these things, if you have gcc 3.3.6 everything should work as intended?

  6. Taro L. Saito reporter

    3: I would like to keep a pure-java version for iOS.

    Carlin: Even if the building nestedvm for gcc 3.3.6 is succeded, you will see some test failures in pure-java mode:

    $ mvn test -DargLine='-Dsqlite.purejava=true'
    
    Tests in error:
      insert(org.sqlite.TransactionTest)
      locking(org.sqlite.TransactionTest)
      multiRollback(org.sqlite.TransactionTest)
    

    The cause of the error is:

    multiRollback(org.sqlite.TransactionTest)  Time elapsed: 3.304 sec  <<< ERROR!
    java.sql.SQLException: [SQLITE_BUSY]  The database file is locked (database is locked)
    

    I have no idea on how to solve this problem.

  7. Log in to comment