使用字节码生成的框架是否会造成抽象漏洞？
我的观点是，如果你不理解框架的抽象，你仍然可以反编译它并理解它，因为你了解这种语言，例如Java。但是，当发生字节码生成时，您甚至必须了解较低级别 - JVM 级别的字节码。 我真的害怕使用任何这样的框架，因为这样的框架有很多。大多数时候，我认为字节码生成的原因只是缺乏元编程等语言功能。你同意？你的观点和论据是什么？您如何解决这些框架中抽象泄漏的问题？
My point is, if you don't understand the abstraction of a framework, you can still decompile it and understand it, because you know the language e.g. Java. However, when byte-code generation happens, you have to understand even a lower level - JVM level byte-codes.
I am really affraid of using any of such frameworks, which are many. Most of the time I think the reason for byte-code generation is simply lack of language features such as metaprogramming. Do you agree? What is your opinion and argument? How do you take over the problem with leaky abstractions in those frameworks?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
首先简单回答：谨慎使用这些框架，不要每一个也不要太多。
您的假设是正确的，字节码生成通常是为了解决语言限制（例如依赖注入）。解决这些限制提供了强大的工具（spring、guice、hibernate），但归根结底，它不再是纯 Java（仍然是纯 JVM），因此带有一点魔力。
只要您只使用这些工具中的一种，您就可以不用太深入地了解内部结构。但如果你开始混合它们，你需要更多地了解它们。
唯一的帮助因素是以前的使用情况；如果其他人已经成功集成了更多这些框架并对其进行了记录，那么您可能不需要太深入地研究。
当你想使用某种工具时，问问自己：
每次添加工具都会增加复杂性。每次添加复杂的工具（例如，使用字节码生成）时，复杂性都会增加。
例子：
在工作中我们使用spring + hibernate。
这是对 EJB (< v3) 的改进，并且该组合众所周知可以工作并且有详细记录。
在一个玩具项目中我使用 Guice。这使得一些解耦成为可能，但要求我的库的每个用户都使用 Guice。出于这个原因，我可能会通过吉斯出去。
Simple answer first: use these frameworks carefully, not every and not too many.
You are correct in your assumption that byte-code generation is usually about working around language limitations e.g. dependency injection. Fixing these limitations provides powerful tools (spring, guice, hibernate) but when it comes down to it it is no longer pure Java (still pure JVM) and thus comes with a bit of magic.
As long as you use only one of these tools you are probably ok in not looking too deep into the internals. But if you start mixing them you need to understand a bit more of them.
The only helping factor is previous use; if other people have successfully integrated more of these frameworks and documented it you might get away with not looking too deep.
When you want to use some tool ask yourself:
Every time you add a tool you add complexity. Every time you add a complex tool (e.g. with byte-code generation) you multiply complexity.
Examples:
at work we use spring + hibernate.
This is an improvement over EJBs ( < v3) and the combination is well known to work and well documented.
in a toy project I use Guice. This makes some decouplings possible but requires every user of my libs to use Guice. For that reason I might through Guice out.