我们是否混淆了商业Java代码？
我想知道是否有人在自己的商业产品上使用了商业/免费的Java混淆器。我只知道一个项目在发布的ant构建步骤中实际上具有混淆步骤。
你会混淆吗？如果是这样，为什么还要混淆？
这真的是保护代码的一种方法，还是对开发人员/管理人员来说是一种更好的感觉？
编辑：好的，我的意思是确切的：我们是否为保护IP(算法，产品中投入的工作)而感到困惑？我不会出于安全原因而感到困惑，这感觉不对。因此，我只是在谈论保护应用程序代码不受竞争对手的侵害。
@staffan有一个好处：
The reason to stay away from chaining code flow is that some of those changes makes it impossible for the JVM to efficiently optimize the code. In effect it will actually degrade the performance of your application.
解决方案
回答
我想这实际上取决于Java代码的用途，它的分布方式以及客户是谁。我们不会混淆任何事情，因为我们从来没有发现过特别出色的东西，而且它往往带来的麻烦超过其价值。如果某人可以访问我们的JAR文件，并且具有能够在其中进行嗅探的知识，那么与剥夺我们的源代码相比，他们可以做的事情要多得多。
回答
我将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)文件中的开销就越大。
回答
如果进行混淆，请远离混淆器，这些混淆器会通过更改代码流和/或者添加异常块来修改代码，从而使它们难以反汇编。为了使代码不可读，通常只需更改方法，字段和类的所有名称即可。
避免更改代码流的原因是，其中一些更改使JVM无法有效地优化代码。实际上，它实际上会降低应用程序的性能。
回答
我今年花了一些时间尝试各种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) != $)
{
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并强烈推荐它。尽管混淆确实可以保护代码不受偶然攻击者的侵害，但是它的主要好处是将删除未使用的类和方法以及将所有标识符缩短为1或者2个字符的影响降至最低。
回答
我认为在大多数情况下，混淆是没有意义的：即使使用完整的源代码，通常也很难弄清楚到底是什么意思(假设没有注释，并且没有局部变量的有意义的名称，当从字节码生成源)。混淆只是装饰蛋糕。
我认为开发人员，尤其是他们的经理往往会过分夸大有人看到源代码的风险。好的反编译器可以生成漂亮的源代码，但使用它并不是一件容易的事，并且相关的成本(更不用说法律风险)高得足以使这种方法很少有用。我只是反编译用于调试闭源供应商产品的问题(数据库抽象层中的死锁，呃)。
我认为字节码实际上是令人困惑的，但尽管如此，我们仍然发现了潜在的问题-这是一个实际的设计问题。
