【IT168 技术新闻】最近John Raynolds提出这个问题：“为什么Java开发者憎恨BPM?”

从自己和他人的经验中，他得出这样的结论：

BPM套件[……]抢走你的创意并指挥你如何开发应用软件。BPM套件让编程成为一件烦人的事。它们迫使你使用点击拖放工具来设计过程图、数据模型和窗体。

更糟的是它们竟然鼓励业务人士自己去构建过程模型和设计窗体……
他声称：

Java开发者（大多数）宁愿使用像Struts和Spring这样的框架，也不愿承受来自BPM套件的限制……用Spring或Struts，你可以构造几乎所有东西（如果你已经掌握了Java的错综复杂）。它们是轻量级的、敏捷的，而且在你的履历中看起来很迷人。

我们已经用Java构建了不少工具，这些工具使得通晓Java本身变得并不那么重要。同时也使那些没有学习Java多长时间的人们与我们展开了竞争。

我们成了自己成功的受害者……这正让我们蒙受损失。

这也就是Java开发者憎恨BPM的原因。
读者们也表达了其他不同的理由。例如下面这个读者憎恨BPM是因为：

坦白说，我不认为BPM会是一个有所作为的应用工具……——NetBeans有免费的BPM工具，但它看起来仅仅像一个简单的Web Service自动化工具。它对我所遇到的业务需求和关注问题完全没有用处。即便是更为花哨的工具，例如花哨的高级过程脚本工具，也没能提供多大价值。——没有一个好的BPM套件是免费提供给开发者们使用的，所以很难对之进行试验。它们价钱不菲，我的老板是不会买它们的。

哪里有成功的案例？我非常乐意倾听：给我看一下这种技术在现实中的应用吧。
另一位则认为：

我们憎恨BPM，原因是我们不应当去使用它。BPM的[……]观念是让业务人士去做建模任务，但事实上业务人士并不用它，因此最终我们[在]用。
这位读者对于经常宣传的貌似简单的“点击运行”并不买账：

现实情况是即使给出最简单的过程，那些过程实际上还是在计算机上运行。而电脑……只懂得“做我说的”，而不会“做我的想要的” 。

不管那些线框图表示什么，都需要对这些线框组合所代表的现实有一个基本的了解。很多很微妙的细节包含在“张贴发票（Post Invoice）”泡沫中，并且这些细微之处将突显并影响它们周围的内容。

最终，需要创造这些图表的人还是需要了解电脑和计算技术。这些人是程序员，而且编程要求特定的思路和技术知识。

……所以，虽然在图上可能只显示为一个单一的盒子，但你最好真正了解这"100行J2EE代码"实际在干什么。不管这个小盒子的颜色或形状是什么样的，复杂度依然存在。

作为一个开发者，我……迷惑不解，“什么时候我的系统变得足够大，值得将这一大堆基础设施放入其中——我需要一个本身占用1G内存的脚本语言解释器和运行时” 。

长期以来，抽象很明显已经让我们所有人过得更好。从二进制代码到汇编程序到C再到Java。“一行Java代码代表10行Java字节码，代表100行机器语言指令”。但最好的Java程序员能了解这100行机器语言指令是怎么运行的。新手程序员则因对此不了解而时常受到惩罚。