Author: amitman...@google.com
Date: Thu Mar 26 10:52:25 2009
New Revision: 5090
Modified:
wiki/GwtJavaApiCompatibilityChecker.wiki
Log:
Edited wiki page through web user interface.
Modified: wiki/GwtJavaApiCompatibilityChecker.wiki
==============================================================================
--- wiki/GwtJavaApiCompatibilityChecker.wiki (original)
+++ wiki/GwtJavaApiCompatibilityChecker.wiki Thu Mar 26 10:52:25 2009
@@ -106,9 +106,7 @@
= Discussion =
-The !ApiCompatibilityChecker tool uses !TypeOracle to compute the API
differences. !TypeOracle in turn requires access to the java source code.
Thus the tool can only work when Java source is available. An alternative
to !TypeOracle would be to use Java reflection which works on class files,
and would not have required access to the source files. However, because of
three disadvantages, we chose !TypeOracle over Java relfection:
- # One use case for the tool was to make the JRE library support that
GWT offers be compatible to a real JRE implementation. However, the JRE
libraries that GWT currently offers are not complete, and are currently not
offered as class files. The use of Java reflection would have prevented us
from running the tool to compare GWT's current support of JRE with a real
JRE.
- # With !TypeOracle, we could tap into the already existing GWT compiler
infrastructure. We could not find an analogous tool (with compatible
licenses) in case of Java Reflection. (Japize, a tool which uses Java
reflection to check for binary compatibility, could have been suitable,
but the tool was under a GPL license.) With Reflection, everything would
have to be developed from scratch.
+The !ApiCompatibilityChecker tool uses !TypeOracle to compute the API
differences. !TypeOracle in turn requires access to the java source code.
Thus the tool can only work when Java source is available. An alternative
to !TypeOracle would be to use Java reflection which works on class files,
and would not have required access to the source files. However, we
chose !TypeOracle over Java relfection because with !TypeOracle, we could
tap into the already existing GWT compiler infrastructure. We could not
find an analogous tool (with compatible licenses) in case of Java
Reflection. (Japize, a tool which uses Java reflection to check for binary
compatibility, could have been suitable, but the tool was under a GPL
license.) With Reflection, everything would have to be developed from
scratch.
= References =
# http://wiki.eclipse.org/index.php/Evolving_Java-based_APIs
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
