在过去的几周中，我一直在疯狂地寻求基于基于Eclipse框架的Java客户端的开源代码为AWIPS2-EDEX服务器构建本机Android客户端。
感兴趣的特定回购协议：https://github.com/unidata/awips2-core（及其依赖项，https://github.com/unidata/awips2-core-foss）。
我最终设法获得了足够多的awips2内核，可以作为基于Gradle的模块在Android Studio中进行构建（请参见https://github.com/jskubick/awips2core-android上的github fork）。庆祝完构建成功后，我着手在一个实际的Android应用程序中实际使用它……然后看着构建失败，因为awips2-core依赖于JAXB，而JAXB已在其他地方详尽记录为：与Android（*）根本不兼容。
我现在正试图消除该模块对JAXB的依赖性，但是这让我开始思考...那里有更多未爆炸的地雷在代码中等待我绊倒...可以编译为“直的Java”，但是会在特定于Android的应用引用它们时炸毁吗？
是否有任何工具可以抓取库.jar文件，并确定其中不存在Android不能满足的任何依赖关系？
更新：我试图直接在Android中使用awips2-core的项目已死。经过进一步调查，发现awips2核心广泛使用Apache Camel的含义沉入其中，我意识到，尝试以当前形式直接由Android使用awips2核心是没有希望的。据我了解，Camel在运行时动态地构建和编译自己的类……这在Android上是完全不可能的，但在“常规” Java的允许下。
这并不意味着我已经放弃了编写Android awips2-EDEX客户端的目标，但是确实看起来像我的目标是重用awips2-core中的现有代码来编写EDEX的Android客户端是一个失败的原因，我将不得不从头开始编写自己的Android EDEX客户端。
（*）所谓“根本不兼容”，是指尚无已知的方式来构建它，以使其能够使用未修改的JAXB（使用为Android构建的通用Java代码）来工作。这是由于至少两个问题造成的：
命名空间问题。认为：BouncyCastle对SpongyCastle。显然，Android出于自身目的劫持了一些JAXB命名空间，而Dalvik / ART的类加载器不允许您使用相同的命名空间使用自己的代码覆盖它。
仅限Dalvik / ART的自省功能。基本上，“真正的” Java具有运行时自省功能，这些功能与不真正Dalvik / ART的注释相关，Java不支持...并且JAXB的某些功能依赖于此。
根据我所读的内容，在过去约7年中，各个人都发现了1或2的部分解决方法，但两者的共同一二重击最终导致了每个试图找到解决方案的人要么扔掉毛巾，然后将问题解决为棘手且绝望的事情，要么对其进行修改，以使其能够满足他们最初所需的一切并每天解决。