Unable to execute dex: Java heap space Exception bei Sqllite lib

[xvchrisvx]

Hallo!

Ich sitze heute schon den ganzen Tag an einem (sehr) nervigen Problem.
Und zwar bekomme ich folgende Exception:
"Conversion to Dalvik format failed: Unable to execute dex: Java heap space".

Allerdings nur, wenn ich meine SQllite lib in den /lib Ordner packe. Mit der Mysql lib (also diesem mysql connector) läuft alles wunderbar.

Woran kann das liegen? Und ja - ich weiß, dass Sqllite schon integriert ist, ich möchte aber diese spezielle Treiberversion verwenden.

Bitte um Hilfe!

Ergänzende Infos:
Es geht natürlich um Android (4.1) in Kombination mit Eclipse

 

[Br4ve]

Wahrscheinlich benutzt die sqlite lib mehr Arbeitsspeicher... Schau doch mal in die Dokumentation

 

[xvchrisvx]

Danke Br4ve aber das hilft mir nicht wirklich weiter...

 

[schlingel]

Woran kann das liegen? Und ja - ich weiß, dass Sqllite schon integriert ist, ich möchte aber diese spezielle Treiberversion verwenden.

Sehr schlechte Idee, denn dann überschneiden sich die Namespaces - dann kannst du nicht mehr für die Funktionalität garantieren. Das habe ich herausgefunden, wie ich Jackson verwendet habe und auf HTC-Geräten getestet habe. Denn die liefern ihre eigene Version mit. => Du musst die Packages umbenennen damit das funktioniert. Das funktioniert mit jarjar.

Wahrscheinlich benutzt die sqlite lib mehr Arbeitsspeicher

Ja genau, das ist das Problem.

Danke Br4ve aber das hilft mir nicht wirklich weiter...

Was hast du denn mit dieser Erkenntnis gemacht? Hast du die RAM-Einstellungen in der eclipse.ini hoch gedreht? (-Xms und -Xmx)

 

[xvchrisvx]

Was hast du denn mit dieser Erkenntnis gemacht? Hast du die RAM-Einstellungen in der eclipse.ini hoch gedreht? (-Xms und -Xmx)

Das habe ich ganz zu Anfang ausprobiert, höher als 900 bei beiden jeweils ging komischerweise nicht,
dann bekomme ich beim Starten von Eclipse eine "Failed to create the Java Virtual Machine"-Fehlermeldung.
Das Hochsetzen auf 900 hat den Fehler aber auch nur nach hinten geschoben, eine Lösung ist das nicht.

Jarjar habe ich mir mal angeschaut, hier das Ant-Skript:
<project name="jarjar-to-the-rescue">
<property name="jarfile" value="result.jar"/>
<path id="classpath">
<pathelement location="jarjar-1.3.jar"/>
</path>
<taskdef name="jarjar" classname="com.tonicsystems.jarjar.JarJarTask" classpathref="classpath"/>
<delete file="${jarfile}"/>
<jarjar destfile="${jarfile}">
<zipfileset src="sqlitejdbc-3.7.13.jar"/>
<rule pattern="org.**" result="org.neu.@1"/>
</jarjar>
</project>

Aber leider bekomme ich beim Ausführen dann folgende Exception:
java.lang.RunTimeException: Class file too large!
Heißt hier komme ich auch nicht weiter, da mitten drin abgebrochen wird.

 

[schlingel]

Das Hochsetzen auf 900 hat den Fehler aber auch nur nach hinten geschoben, eine Lösung ist das nicht.

Wenn zu wenig Speicher da ist, ist zu wenig Speicher da. Hilft alles nichts, aber mehr als 900MB kannst du schon hergeben. Meins läuft mit 1024MB.

Welches JAR (Link bitte) verwendest du überhaupt für SQLite?

 

[xvchrisvx]

Welches JAR (Link bitte) verwendest du überhaupt für SQLite?

Z.B. diesen hier, es gibt sowieso immer denselben Fehler:
http://www.xerial.org/maven/repository/artifact/org/xerial/sqlite-jdbc/3.7.2/sqlite-jdbc-3.7.2.jar
Hier bekomme ich den auch.

 

[schlingel]

Vergiss es, das funktioniert sowieso nicht. Siehe diesen SO-Post.

Welchen Vorteil versprichst du dir von einer anderen SQLite-Lib als der von Android? Und wenn es umbedingt eine 3rd-Party-Lib sein muss, dann versuche eine zu finden die auf Android läuft. JDBC gehört zu den Sachen die nicht geported wurden, das wäre ca. so vielversprechend wie zu versuchen eine Swing-Lib zu verwenden.

 

[xvchrisvx]

Welchen Vorteil versprichst du dir von einer anderen SQLite-Lib als der von Android?

Weil ich etwas auf dem PC mit einer ziemlich neuen SQLite-Lib getestet habe, die extra für unseren Betrieb angepasst wurde bzw. eine spezielle Komprimierung enthält. Jetzt möchte ich das ganze nochmal auf dem Handy versuchen, die "normale" Version unterstützt diese Komprimierung natürlich nicht...

Wenn Android absolut keinen JDBC Treiber unterstützt, wieso funktioniert es denn mit MYSQL?
Ich denke immer noch, dass es Probleme gibt, weil SQLite eigentlich bereits vorhanden ist.

 

[schlingel]

Ich denke immer noch, dass es Probleme gibt, weil SQLite eigentlich bereits vorhanden ist.

Sicher nicht, denn dein dex-Problem ist eine Compile-Zeit-Geschichte. Package-Namenskonflikte sind ein Runtime-Problem. Äußert sich meistens in ClassNotFound-Exceptions oder irgendwelchen obskuren Signaturproblemen/Exceptions.

Wenn Android absolut keinen JDBC Treiber unterstützt, wieso funktioniert es denn mit MYSQL?

Gute Frage, welche Lib verwendest du? Wenn man so auf Google nach dem Problem sucht, findet man meistens nur Workarounds mit einem Webservice der dann auf die MySQL-DB zugreift und Android welches mit dem Webservice arbeitet. (Sowieso die sauberere Lösung) Weil es (angeblich) keine MySQL Lib gibt.

 

[xvchrisvx]

Sicher nicht, denn dein dex-Problem ist eine Compile-Zeit-Geschichte.

Eben auch wenn es nachher im Endeffekt nicht läuft, müsste das Programm doch wenigstens starten,
so wie es mit dem mysql-connector funktioniert.
Ich habe gerade was von SQLDroid gelesen, allerdings scheint das auch leider den normalen SQllite Android Treiber zu nehmen.
Ich habe schon überlegt, ob man den nicht auf dem Gerät ändern könnte.

 

[schlingel]

Eben auch wenn es nachher im Endeffekt nicht läuft, müsste das Programm doch wenigstens starten,
so wie es mit dem mysql-connector funktioniert.

Wie soll das Programm starten wenn es sich nicht kompilieren lässt?

Der Ablauf ist wie folgt: Aus deinem Projekt werden .class-Files erzeugt. Diese werden dann von dex in das Android-Format kompiliert und in einem APK zusammengeschnürt. Hier hakt es, da dex der Speicher ausgeht. Wie kommst du auf die Idee, dass sich das Programm dann starten lassen sollte?

[...] so wie es mit dem mysql-connector funktioniert.

Welchen verwendest du denn dafür? Bist du dir sicher, dass das tatsächlich JDBC verwendet und nicht ein für Android angepasstes Jar ist?

Ich habe schon überlegt, ob man den nicht auf dem Gerät ändern könnte.

Nein. Das ist in's System eingebacken, ca. so einfach wie die TCP/UDP-Implementierung vom Android-System zu ändern. Erstens nicht praktisch, zweites setzt das ein gerootetes Handy voraus, drittens haut das so ziemlich alle anderen Apps zusammen.

Wenn die Seite von SQLDroid nicht lügt hackt es ganz einfach an der Lib die du verwenden willst. Wenn das mit dem Xms/Xmx nicht hinhaut, wirst du die Lib nicht verwenden können. Das Dex seinen Job macht ist Voraussetzung.

 

[xvchrisvx]

Welchen verwendest du denn dafür? Bist du dir sicher, dass das tatsächlich JDBC verwendet und nicht ein für Android angepasstes Jar ist.

Den ganz normalen Connector von der Oracle Seite:
http://dev.mysql.com/get/Downloads/...or-java-5.1.22.zip/from/http://cdn.mysql.com/
Wenn der im /libs Ordner liegt, gibt es keinen Fehler vor dem Programmstart.

Ich will keine wirkliche APP programmieren sondern nur ein paar Tests durchführen, dass das Handy gerootet werden muss, dabei Apps vlt. kaputt gehen wäre nicht allzu tragisch.
Aber ich seh schon, ich habe mich noch nicht ausreichend mit Android beschäftigt. Also gibt es keine Möglichkeit eigene Libraries irgendwie auf das Handy zu bekommen, ohne dass die durch den Compiler müssen?

 

[schlingel]

Also gibt es keine Möglichkeit eigene Libraries irgendwie auf das Handy zu bekommen, ohne dass die durch den Compiler müssen?

Jein. Bei einem JAR ist das meines Wissens nach unmöglich. Wenn du allerdings ein C-Projekt hättest für SQLite, könntest du dieses für ARM Cross-Compilen und das dann über NDK einbinden.

Alleine beim Schreiben dieser Zeilen steigen mir die sprichwörtlichen Grausbirnen auf. Ich würde das lassen und mit den Leuten sprechen, die die Anpassungen gemacht haben ob Sie hier nicht eine Android freundlichere Lib machen könnten.

 

[xvchrisvx]

Ich gebs dann jetzt auch so auf, das hat keinen Sinn.

Ich würde das lassen und mit den Leuten sprechen, die die Anpassungen gemacht haben ob Sie hier nicht eine Android freundlichere Lib machen könnten.

Das versuch ich, Danke!