Help understanding class loading

[ebowman]

Hi,

I've undertaken the slightly ambitious, it seems, task of getting a
full-blown ShadowParcel and ShadowBundle implementation working in 1.0-
RC2.

I'm struggling to unparcel my own objects, though, because of an issue
with (my understanding of) RobolectricClassLoader.

What's happening is, my ShadowParcel instance is trying to get ahold
of the CREATOR field of a (non-Robolectric) class I'm unparceling in a
test. When I call parcel.readParcelable, I pass in the classloader of
the class I'm trying to load, but that turns out to be the
RobolectricClassLoader even though this is not a class known to
Robolectric, and when it tries to load my class using that classloader
inside ShadowParcel (in order to grab CREATOR via reflection), the
class is a funky "I-don't-have-a-shadow-implementation" stub class,
instead of the real class which does happen to be hanging around.

It seems that if the class named started with "org.junit" or
"org.hamcrest", it might work (didn't try that yet...), so maybe the
fix is to extend RobolectricClassLoader so that tests can add more
packages to the list of packages to ignore?

Any thoughts?

Thanks,
Eric

[Tyler Schultz]

I'm not able to clearly understand what is going on, but it sees like a reasonable feature to add.  I'm curious to know what is happening inside of com.xtremelabs.robolectric.bytecode.AndroidTranslator#onLoad(ClassPool, String) when the bad thing happens.  Have you debugged in there at all?

--Tyler

[ebowman]

Ok, I found the problem ... my understanding of what was going wrong
was a little bit off... ;)

Seems to work pretty nicely to parcelize/unparcelize most things via
Robolectric. Not IBinder...

I'm wondering, is anyone particularly attached to the ShadowBundle
that's there? This changeset will replace it.

Anyhow I need to tidy a few loose ends, then I hope to push it to my
fork on github; I'm quite curious to see are there any issues or
objections to pulling to the pivotal fork.

cheers,
Eric

[ebowman]

I've got a push request now with SparseArray, Parcel, Bundle, and
Signature support: https://github.com/pivotal/robolectric/pull/56

Thanks,
Eric

[ebowman]

Curious what you guys think of this approach? I'm actually starting to
depend on it somewhat, so it would be nice to know if there are likely
to be obstacles to getting it merged.

[ebowman]

Is there any chance of getting SparseArray/Parcel/Bundle support
merged? Or should I assume the worst here?

Thanks,
Eric

[Tyler Schultz]

Hi Eric, 

We've been busy and haven't been able to find time to get through all of the pull requests. So sorry. We're working on them in submit order, so you'll have to hang in there.  We merged in several pull requests yesterday (Thank you submitters!).  Assuming your code is solid and you have tests for the added functionality, I don't see there being any problem.  We'll get in touch with you if we think there's a problem, so we can work out the kinks. We want your contributions!

THANK YOU for taking the time to submit a pull request.

--Tyler

[ebowman]

Hi Tyler,

Not to make life too much more complicated, but I also pushed full
Address support, which shows up automatically in the pull request.

https://github.com/ebowman/robolectric/commit/1275a28ad5a9f10801a87977b3a66713354d563d

cheers,
Eric