我正处于构建
Java EE应用程序的需求阶段,该应用程序很可能在GlassFish / JBoss后端运行(现在无关紧要).我知道我不应该在需求时考虑架构,但人们不禁开始想象组件是如何全部拼凑在一起的:-)
以下是客户端的一些硬性,非灵活性要求：
(1)客户端应用程序将是一个Swing框
(2)客户端可以免费下载,但将使用订阅模型(因此需要具有服务器端认证/授权的登录机制等)
(3)是的,Java是针对当前问题的最佳平台解决方案,其原因超出了本文的范围
(4)客户端.class文件需要防止反编译
最后(第4个)要求是这篇文章的基础.
我并不是真的担心有人会实际反编译并获取我的源代码：最后,它只是由一些轻量级业务逻辑驱动的Swing控件.
我担心会有人反编译我的代码,修改它以利用/攻击服务器,重新编译并激活它.
我设想了各种令人讨厌的解决方案,但不知道这是否是Java EE开发人员常见解决方案的常见问题.有什么想法吗？
对“代码混淆”技术不感兴趣！
感谢您的任何意见！
