Java 8 is just around the corner and you might wonder if COPPER is ready for Java 8, especially the new language features.

Alas, no! The reason is that we are using the awesome ASM bytecode engineering library to load, modify and store workflow classes from and into the database. The current stable release is 4.2, which is not ready for Java 8 yet.

However, the ASM developers are already working on Java8 compatibility and promise that it’s ready with the next major release 5.0. A beta version is already available, which we are testing right now.

Thus, in short: you cannot use Java8 with COPPER right now. If you really want to use COPPER with Java 8, you can do so, but be very careful to compile all your persistent workflow classes with --source 1.7 --target 1.7. (All your other classes can be compiled without these options.) But that’s probably not what you want, because you cannot use the new language features in your workflows, especially closures.

We will release a new COPPER version with Java 8 support as soon as ASM 5.0-stable hits the scene, so stay tuned!

We moved the source code from Google Code to GitHub: Now it’s here: https://github.com/copper-engine/copper-engine

Google Code served us well one year now, but we found that GitHub has some very attractive features: better issue and release management, free webspace (GitHub pages), a nicer wiki. Plus, of course, the first-class support for Git, the new version control behemoth we all love.

So, we removed all content from the old Google code site and moved it to GitHub. The new issue tracker is here, and all documentation went to our new website.

Please let us know if anything is missing! E-mail to contact@copper-engine.org.

As you can see, we completely revamped our copper-engine.org website. :) Take a look around!

The site is now made with pure Bootstrap 3.0 and is served by the Jekyll templating engine on GitHub pages (more on GitHub in our next post).

Not everything is quite there yet, documentation is still lacking, but we’re working on it! We’ll post it here whenever we make some new content available.

Stay tuned!

COPPER 2.4.3 is the latest stable release. Here’ what’s new:

• New feature: engine.run throws DuplicateIdException if an existing workflow instance id is used - this is also implemented for the transient engine which substitutes throwing an IllegalStateException
• New feature: Default value for property “loadNonWorkflowClasses” in “FileBasedWorkflowRepository” changed from false to true, due to various problems, e.g. Switch-case not working out-of-the-box
• Bugfix: ArrayIndexOutOfBoundsException and other exceptions during workflow instrumentation when extensively using nested blocks and local variables

You can get it here: https://github.com/copper-engine/copper-engine/releases/tag/2.4.3

Some myths never die. Although BPEL clearly is an XML dialect and does not define nor is it meant to be a graphical representaion of processes some people insist of using graphical tools to model the most complex workflows, just because they can. This can lead to absurd monster diagrams like this one (be aware: 710kb, 1866x10826px; use your browser to zoom). No, I’m not making this up. This is a real world workflow from one of our customers which is actually in use. (Ok, I admit it has been anonymized.)

I guess the poor developer who has the questionable honor to maintain this mess might have come to the conclusion, just after adding the 500th arrow somewhere in the lower 30 feet (when printed on fanfold paper), that there’s something gone horribly wrong here. But, of course, it’s not his decision to get rid of it; it had most likely been a management decision to introduce all that fancy UI stuff that looked great on glossy paper. It’s the “if-you-got-one-hammer-everything-looks-like-a-nail” philosophy that went berserk here. We claim that it is system immanent for BPEL tools.

How much better would it have been if this workflow has been described and implemented in Java. Every developer could easily read and understand it. There’s no impedance mismatch.

One often heard argument for graphical notations is that they bridge the gap between development team and business side. That’s true. But it only works on a very basic and abstract architectural level. It’s a misconception that you should use graphical notations for actual implementation, too. The problem is: once you got these fancy UI tools, no one tells you where to stop!

Implementing a workflow is a complicated technical task where the best help is a complex framework that takes the burden from you of caring about all the nasty technical details of persistence, repeatability, reliability etc. and lets you concentrate on the actual business rules. That’s what COPPER is for.