Keith Wiley wrote:
> Not easily.  I already tried to narrow it down by removing .java files
> from the build compilation to .class files.  The JXL library has
> hundreds of files and they are relatively tightly coupled.  There
> aren't many .java files in it that can be removed such that the
> remaining files fully build without lost references.  I could try it
> at a later stage, letting it build all the .class files and then only
> passing subsets to dx for dex conversion, but I would expect similar
> problems, i.e., missing references.

Ah, sorry, I thought this was something smaller.

> I will have to figure out how to build android code outside Eclipse.
> I admit I haven't looked very hard yet, it isn't an approach I have
> relished.  I'll look for some resources online.

Step #1: Run android create project to generate the necessary files.

Step #2: Run ant debug to build.

Step #3: There is no step #3, though you're welcome to fill in "have a
beer" or something if you'd like.

> In the meantime, the following is the full contents of the file
> mentioned in the error shown in a prior post.  The specific method
> that triggers the exception is trimInvalidChars(String).  It all looks
> very basic to me.

Since your short-term goal is a compile, versus a run, try commenting
out some of the stuff that seems strange, to see if you this file past
the problem. The biggest thing in the affected method that leaps out at
me is:

>       // The string is dodgy.  Find the first valid char
>       firstHash = firstHash == -1?firstHash =
> Integer.MAX_VALUE:firstHash;
>       firstZero = firstZero == -1?firstZero =
> Integer.MAX_VALUE:firstZero;

That is tortured Java syntax. Methinks somebody gave a Perl coder access
to the JXL source tree... ;-)

You should be able to comment out that block and still compile, AFAICT.
If it works, that suggests a possible problem in dexing intertwined
ternary operators and assignments.

My hope is that there's some coding convention, like the above, that JXL
uses that Dalvik just wasn't tested against. If true, you then at least
have the option of patching the JXL code to be less, um, icky. Plus,
it'll provide nice test cases to attach to a b.android.com issue to help
out a possible repair.

-- 
Mark Murphy (a Commons Guy)
http://commonsware.com | http://twitter.com/commonsguy

Android Training in Germany, 18-22 January 2010: http://bignerdranch.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to