[GraphHopper] Alternative to Trove library.

[Alex]

Hi,

I don't know if this has been discussed before, but while developping my
android app with graphhopper support I have hit the infamous dalvik error :
Conversion to Dalvik format failed with error 2
trouble writing output: Too many methods: 72332; max is 65536. By package:

As per stackoverflow and android coummunity this is due to a too large
codebase for my app = too many methods.

The error log gives me a method count per package and it seems the gnu
trove which is used by graphhopper is very greedy in that domain. for
example the error log give me

  446 gnu.trove
  3066 gnu.trove.decorator
     8 gnu.trove.function
    13 gnu.trove.impl
  1139 gnu.trove.impl.hash
  2658 gnu.trove.impl.sync
  3010 gnu.trove.impl.unmodifiable
   404 gnu.trove.iterator
     2 gnu.trove.iterator.hash
   339 gnu.trove.list
   602 gnu.trove.list.array
   674 gnu.trove.list.linked
  1763 gnu.trove.map
   798 gnu.trove.map.custom_hash
  8147 gnu.trove.map.hash
    72 gnu.trove.procedure
     2 gnu.trove.procedure.array
    28 gnu.trove.queue
   175 gnu.trove.set
   396 gnu.trove.set.hash
    56 gnu.trove.stack
   133 gnu.trove.stack.array
     6 gnu.trove.strategy

TOTAL : 23'397 methods just for trove. WOW !



 23'397 methods is almost one third of what is allowed by dalvik VM for a
dex file. So once you app gets a little complex and you want to use
graphhopper the limit can be reached quite easily.


Now my question is : is there a way to avoid trove in graphhopper for
example by replaceing trove collections by standard java collections ?
Or would it be possible to find an alternate lighter (shrinked) )version of
trove or another collections library.
Would there be a huge performace difference ?


Thank you for your help. I'm a bit stuck here.

Cheers,

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/graphhopper/attachments/20140503/04390501/attachment.html>