你是否混淆商业Java代码？
我想知道是否有人在自己的商业产品上使用商业/免费的Java混淆器。 我只知道一个项目实际上在发布的ant构build步骤中有一个模糊的步骤。
你混淆了吗？ 如果是这样，你为什么混淆？
这是否真的是保护代码的一种方式，还是对开发人员/pipe理人员来说更好？
编辑：好吧，我确切地说我的观点：你是否混淆保护你的知识产权（你的algorithm，你已经放入产品的工作）？ 我不会因为安全原因而混淆，那是不对的。 所以我只是在谈论保护你的应用程序代码与竞争对手。
@staffan有一个好点：
远离链式代码stream的原因是，其中一些更改使JVM无法有效地优化代码。 实际上，它实际上会降低应用程序的性能。
如果进行了混淆处理，请远离修改代码的混淆器，方法是更改代码stream和/或添加exception代码块等，以使其难以反汇编。 为了使代码不可读，只需更改方法，字段和类的所有名称即可。
远离更改代码stream的原因是，其中一些更改使JVM无法有效地优化代码。 实际上，它实际上会降低应用程序的性能。
我认为混淆的旧（古典）方式正逐渐失去其意义。 因为在大多数情况下，经典的混淆器打破了堆栈跟踪（这不利于支持您的客户端）
现在的重点不是保护一些algorithm，而是为了保护敏感数据：APIlogin/密码/密钥，负责授权的代码（盗版依然在这里，尤其是西欧，俄罗斯，亚洲，恕我直言），广告账号等。
有趣的事实：我们在Strings中拥有所有这些敏感数据。 其实弦乐约占我们应用程序逻辑的50-80％。 在我看来，混淆的未来是“stringencryption工具”。
但是现在“stringencryption”function只能在商业混淆器中使用，例如： Allatori ， Zelix KlassMaster ， Smokescreen ， Stringer Java混淆工具包 ， DashO 。
NB我是Licel LLC的首席执行官。 Stringer Java混淆器的开发者。
我使用proguard进行JavaME开发。 它不仅非常擅长将jar文件制作得更小（对于移动设备来说是非常重要的），而且还可以作为一种更好的设备专用代码方式，而不需要使用IDE等不友好的预处理工具，比如天线。
例如
public void doSomething() { /* Generated config class containing static finals: */ if (Configuration.ISMOTOROLA) { System.out.println("This is a motorola phone"); } else { System.out.println("This is not a motorola phone"); } } 这将得到编译，模糊处理，类文件结束，就像你已经写了：
public void doSomething() { System.out.println("This is a motorola phone"); }
因此，您可以有不同的代码来解决JVM /库实现中的制造商错误，而不会填充最终的可执行类文件。
我相信某些商业混淆器也可以在某些情况下将类文件合并在一起。 这很有用，因为你拥有的类越多，你在zip（jar）文件中的开销就越大。
今年我花了一些时间来尝试各种Java混淆器，而我发现其中一个比其他的要好得多 ： JBCO 。 不幸的是，设置起来有些麻烦，而且没有GUI，但是就产生的混淆程度而言，它是无与伦比的。 你试着给它一个简单的循环，如果你的反编译器没有崩溃试图加载它，你会看到这样的东西：
if(i < ll1) goto _L6; else goto _L5 _L5: char ac[] = run(stop(lI1l)); l7 = (long)ac.length << 32 & 0xffffffff00000000L ^ l7 & 0xffffffffL; if((int)((l7 & 0xffffffff00000000L) >> 32) != $5$) { l = (long)III << 50 & 0x4000000000000L ^ l & 0xfffbffffffffffffL; } else { for(l3 = (long)III & 0xffffffffL ^ l3 & 0xffffffff00000000L; (int)(l3 & 0xffffffffL) < ll1; l3 = (long)(S$$ + (int)(l3 & 0xffffffffL)) ^ l3 & 0xffffffff00000000L) { for(int j = III; j < ll1; j++) { l2 = (long)actionevent[j][(int)(l3 & 0xffffffffL)] & 65535L ^ l2 & 0xffffffffffff0000L; l6 = (long)(j << -351) & 0xffffffffL ^ l6 & 0xffffffff00000000L; l1 = (long)((int)(l6 & 0xffffffffL) + j) & 0xffffffffL ^ l1 & 0xffffffff00000000L; l = (long)((int)(l1 & 0xffffffffL) + (int)(l3 & 0xffffffffL)) << 16 & 0xffffffff0000L ^ l & 0xffff00000000ffffL; l = (long)ac[(int)((l & 0xffffffff0000L) >> 16)] & 65535L ^ l & 0xffffffffffff0000L; if((char)(int)(l2 & 65535L) != (char)(int)(l & 65535L)) { l = (long)III << 50 & 0x4000000000000L ^ l & 0xfffbffffffffffffL; } } } }
你不知道Java有goto的？ 那么，JVM支持他们=）
我使用ProGuard并强烈推荐它。 尽pipe混淆确保了您的代码免受临时攻击者的影响，但其主要好处是可以最小化删除未使用的类和方法的效果，并将所有标识符缩短为1或2个字符。
我认为大多数情况下，混淆是毫无意义的：即使是完整的源代码，通常也很难弄清楚到底是什么意思（假设没有注释，也没有局部variables的有意义的名字 – 从字节码生成源）。 混淆只是装饰蛋糕。
我认为开发人员，尤其是他们的pipe理人员往往过分夸大有人看到源代码的风险。 虽然优秀的反编译器可以产生漂亮的源代码，但是使用它却不是一件容易的事情，相关的成本（更不用说法律风险）足够高，使得这种方法很less有用。 我只反编译debugging闭源供应商产品的问题（DB抽象层的死锁，呃）。 字节码实际上是混淆的，我想，但我们仍然发现了潜在的问题 – 这是一个实际的devise问题。
我想这真的归结于你的Java代码是如何分配的，以及你的客户是谁。 我们不会混淆任何东西，因为我们从来没有发现过一个特别好的东西，它往往比它的价值更麻烦。 如果有人可以访问我们的JAR文件，并且知道能够在里面嗅探，那么比起剥离我们的源代码更令人担心的是他们可以做的事情。
