-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Oh, Java assertions are way, way more "special" than that. They should
never, ever be used under any circumstances. For anything. At all. Ever.
There's no "assert" instruction in the JVM. Assertions are implemented
via desugaring.
Both the Sun and OpenJDK appear to implement assertions exactly as
suggested by JSR-41[2, Appendix IV] - summarised here for comedy value.
A statement of the form:
assert expression message;
Is replaced in the compiler's desugaring step by:
if (!$assertionsDisabled && !expression) {
throw new AssertionError(message);
}
Where $assertionsDisabled is a static field the compiler adds to every
class using assertions with the following definition:
static final boolean $assertionsDisabled =
!ThisClass.class.desiredAssertionStatus();
Where desiredAssertionStatus returns the assertation status for
this class, set by the classloader based on things like
compile-time options to the jvm, or that system property you
mentioned.
This is completely insane.
Each assertion, then, translates into 13 bytes of extra bytecode, plus
the extra size of `expression`/`detail`, plus a 16 byte one-time
overhead for each class using assertions. This adds up quickly if you
use assertions properly (ie. lots), meaning your binaries get huge.
Worse, not only does javac not support stripping assertions for
release builds, neither can Proguard remove them[1] (Understandable,
since deleting the desugared assertions given only the bytecode isn't
trivial).
(Although my optimiser can - woot!)
Then there's the fact that even when assertions are turned off, you're
evaluating that if condition all over the place taking a small
performance hit in interpreted mode. Worse still, because it bloats
the bytecode so much your functions get way bigger, which in turn
makes the JIT more reluctant to go near them... (although when it
finally does it *will* delete this crap if they're turned off - at
least, on HotSpot - unsure about Android).
So. Yes. Under no circumstances ever use the Java assert mechanism for
anything, ever.
Interestingly enough, it seems a few have sneaked into Fennec. I never
mentioned them before because I'd assumed Proguard stripped them...
Whoops.
https://mxr.mozilla.org/mozilla-central/source/mobile/android/base/webapp/EventListener.java#138
https://mxr.mozilla.org/mozilla-central/source/mobile/android/base/webapp/EventListener.java#143
https://mxr.mozilla.org/mozilla-central/source/mobile/android/base/webapp/InstallListener.java#32
Of course, this situation is really dumb, because it means everyone
who wants assertions ends up using a library or creating their own
assert solution like was just done.
A thought: Why not use the JUnit assert API instead? Perhaps not much
point changing now you've got this (it's not like asserts are
complicated to implement anyway).
It'd probably be a good idea to tweak Proguard's config file to make
sure all these swanky new asserts get deleted in release builds...
[1] http://sourceforge.net/p/proguard/feature-requests/124/
[2] https://jcp.org/en/jsr/detail?id=41
On 25/04/14 21:51, Nick Alexander wrote:
> On 2014-04-25, 1:37 PM, James Willcox wrote:
>> Nick,
>>
>> On Apr 25, 2014, at 3:36 PM, Nick Alexander
>> <[email protected]> wrote:
>>
>>> On 2014-04-25, 1:30 PM, James Willcox wrote:
>>>> Greetings,
>>>>
>>>> We don’t have anything like MOZ_ASSERT() in Java land, so I
>>>> added an “Assert” class[1]. Just like MOZ_ASSERT() in C++
>>>> land, these assertions are only active in debug mode.
>>>> Hopefully we can use these to catch some bad stuff.
>>>
>>> I think this is a good thing, thanks for doing it! Is there a
>>> reason we didn't just use Java's assert mechanism [1], and
>>> enable/disable checking at compile time with MOZ_DEBUG and
>>> friends?
>>>
>>> Best, Nick
>>>
>>> [1]
>>> http://docs.oracle.com/javase/7/docs/technotes/guides/language/assert.html
>>>
>>
>>
>>
>>>
That was my first thought as well, but apparently those are only
>> triggered if you set a property on the device, which is less
>> than ideal. More here:
>> http://stackoverflow.com/questions/6176441/how-to-use-assert-in-android
>
>>
> Well, isn't that special. As you were!
>
> Nick _______________________________________________
> mobile-firefox-dev mailing list [email protected]
> https://mail.mozilla.org/listinfo/mobile-firefox-dev
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJTWutTAAoJEDMunsjIwzstc+4P/jw+XuR8d26TdsdanI4qfOYy
Spwa4ETlZLhAWwykZSQlGf12WWTRU0Q8QzPaLcgIsXqOzp32eM/dQY4BBC/cv95x
F9zmGzmv2HdFiGGy5++ns9/Qdambqmk1WbZdM/VuU2XKcmX3oha6Sl8Qoc+YHMJ6
OSPRSTdHDmeLAOwAobFlgs9gM4+zOVI0Ah2ok69TneCs+wKF/ZCIinWK1/Z0itLM
gV5CBnzKAAIivNyjoGwd4uTv+WJrjskcyfsJsbm9QjIhbCx4/95T2m1MdhQbjAmR
oJXAKL7VssWUP0cXbOKGtBRuNRezWLNEl/a0vIQ9t0E/hdyVt8z/KdGBvfpMUei5
JeRNZdNrQLsbFq1fZjcoXIaF1fALTRuxVuU1we1f85Sttzc2O20qHyYbsHyFLV+E
3qWxlHzJL+qM9TDb+0js/OYQ+2e1iB0t2ZadwrdcNFpKLNvxgUIGWPAbPIzLVyrx
g38Q6un01spQw2+/BJ9018LQTd4f4r97ntynTpptkk22d0HQrwTDv+Di2C/EdZ8x
eBPUqAt1f+AdC0NruwyB5cVZRkiH+Yj6WmJozMO8Ry+UTapCKmc9yEQjoUNjduHj
uq9iZd73onhjy6sgD8sr33T1s+EB0DcJn2uJQE6Ec1AJ+6XJ3XwrR/6PouSrLjg9
sH4F0/TbH/Z1QE3XlXDa
=RsX5
-----END PGP SIGNATURE-----
_______________________________________________
mobile-firefox-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/mobile-firefox-dev
