Desetude noticed that there are some cases where this transformation is
unsafe - for example: `i > i++`. Skipping the transform if _either_ side
of the comparison has a side effect, rather than _both_ sides, makes it
safe.
Our patched copy of Fernflower no longer produces char literals in
inappropriate places (e.g. bit shifts). This removes the requirement for
this option, allowing non-English string literals to read nicely.
I've been thinking about this for a while. On the one hand, using the
"or later" clause means we have to place some trust in the Free Software
Foundation. On the other hand, being able to adopt newer versions of the
license without having to contact all contributors is useful for
compatibility (e.g. Apache 2 and GPLv3).
I recently noticed that Section 14 states that new versions of the
license will be "similar in spirit" to the current version. I think this
reduces the amount of trust we need to place in the FSF, as I'd hope
that if a future license did diverge too much from the original spirit
that a court might not consider it valid.
Furthermore, if the FSF went totally crazy, there are many bigger and
more important projects who would experience the same problem.
This isn't ideal as it's deprecated. However, while Apache Harmony's
unpack200 implementation seems fine, its pack200 implementation doesn't
work with the client and produces invalid output.
I've fixed some of the easy to fix bugs, but tracking down any remaining
bugs will be difficult - it'll involve tracing through the native
unpack200 code.
When Pack200 is removed from the JDK, hopefully someone will take up the
mantle of maintaining it outside of the JDK. If that doesn't happen,
we'll have to consider writing our own Pack200 implementation,
extracting OpenJDK's implementation out of the tree or fixing the bugs
in Apache Harmony.
