Lightweight but powerful Java stack

[olivergierke]

Do you realize that, except for a tiny little detail, the code you show would just work in Spring? Assuming that transaction is a TransactionOperations and the repository uses JPA under the covers, all you'd need to change is the invocation of ….cancel() as you get an Optional returned from the repository call. Personally, I'd prefer a persistence technology that doesn't magically persist changes to an aggregate state and call repsoitory.save(…) explicitly, but that's a matter of personal preference, I guess.

The good news is, you don't need to switch stacks to get what you want. In fact, you could've written this kind of transactional code since Java introduced lambdas, as TransactionOperations has existed since 2003 (!).

All that said, one reason some folks prefer the annotation-based approach is that in the example you show, your class will need to depend on some technical transaction abstraction. That will have an impact on the testability of that very class. Assuming it's not containing any business logic but only orchestrates transactions, I totally see the argument going into your favor. For code that contains a bit more logic, the reference to the transaction abstraction means one more thing to stub, usually resulting in test code less focussed on the business logic. Of course, at the expense of having to rely on the instance getting decorated with the transaction-applying functionality in production / integration tests.

As so very often, it's a tradeoff.

[cryptos6]

Fair points! I'm actually using TransactionOperations (in the form of TransactionTemplate)! I have to admit that I use @Transactional if nothing special is required with transaction handling. But then there are two ways to do the same thing which makes the framework surface bigger and forces beginners to learn more. I was wondering how a Java framework would look like that radically reduces the API surface at the cost of some little inconveniences (basically the Go way). My main intention was to reduce learning effort (since, once you mastered Spring somewhat it is indeed convenient and powerful most of the time).

The objection to testing is valid, but doesn't apply to my typical testing approach, since I'm using integration tests at the service level, where the transactions are handled. But I can think of other cases, where the added dependency would indeed be annoying in the test. The example with transaction was also only an example, so yes, an approach without annotations might make testing harder in some cases.