GWT 生成器 - 确定类是否在任何地方被引用
我有 GWT 项目，它使用生成器来创建光动态反射对象。
我想知道是否有人知道一种方法来确定从所有入口点开始的依赖树中是否引用了特定的类。如果我能做到这一点，我就可以避免为永远不会使用的类生成反射数据。
我的理解是，当 GWT 进行编译时，它会执行类似的检查，以便可以减少编译代码的总大小，但我在 TypeOracle 或类似的东西中找不到任何相关方法。
I have GWT project that uses Generators to create light dynamic reflection objects.
I was wondering if anybody knows of a way to determine whether or not a particular class is referenced in the dependency tree beginning at all EntryPoints. If I could do this, I could avoid generating reflection data for classes that will never be used anyway.
My understanding is that when GWT does its compiling, it performs a similar check so that it can reduce the total size of the compiled code, but I haven't been able to find any related methods in TypeOracle or anything like that.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这是实现目标的间接方法。我相信每个 GWT 模块都完全打包成常规的 java 包。您可以使用
来获取 JPackage 实例，并在该实例上使用 findType(String typeName) 来查看该包中是否存在某种类型。如果存在，则很可能在某些文件中引用它并且 GWT 将编译它。
还有一个 getPackages() 方法，它返回该类型 oracle 已知的所有包的数组 - 因此 GWT 编译器可以访问。
您可以在每个包上迭代
findType()来查找该类型是否将被编译。最好的方法是定义一个自定义注释并将您想要生成反射代码的所有类列入白名单。您可以用它注释所需的类，并在为其生成代码之前检查注释是否存在。
我最喜欢的是遵循命名约定而不是注释（我两者都一起做了），从而维护白名单，并使约定（通常是正则表达式）成为可以根据团队需要进行更改的“设置”。
This is an indirect method of accomplishing what you are getting at. I believe each GWT module, is fully packaged into a regular java package. You can use
to get the JPackage instance, and on that instance you use findType(String typeName) to see if a type is present in that package. If present, its likely that it is referenced in some file and GWT will compile it.
There is also this method getPackages() which returns an array of all packages known to this type oracle - therefore reachable for GWT compiler.
You can iteratively
findType()on each package to find if the type is going to be compiled or not.The BEST method is to define a custom annotation and whitelist all the classes that you do want to generate reflection code. You can annotate the required classes with it, and checking for that presence of annotation before generating code for it.
My favorite is to follow a naming convention over annotation, (I did both together), and thus maintain a whitelist, and make the convention (its usually a REGEX) a "setting" that can be changed however the team wants.