I agree, things should be straightforward, readable and logical.
The Java people are describing here is alien to me, and I code Java for a living at the moment.
> The Java people are describing here is alien to me, and I code Java for a living at the moment.
you're looking at enterprise java, not regular java
I'm certainly not! You take that back! Yuck!
I'm writing microservices using a relatively lightweight, straightforward and explicit web framework (sparkjava, which is more of a library than a framework really), modern language features and no AOP...
Enterprise... pah!
(Oh, unless you mean the Spring crowd are enterprisey, in which case I take that all back.)
Modern OSes don’t log to simple text files you can grep, tail, watch, open in a text editor, etc.
The requirement was the other way around, that the source can be grepped for an error message and the result be meaningful.
Unix was an improvement on all its successors.
You say that like it's a good thing. When there's a bug to look into grepping strings from the log is one of the first steps, the first step if you don't have a stack trace, I want that string to be where the problem is. Having the logging in with the rest of the code is an inevitability anyway and unless you only want logging at function boundaries.
> In fact, any cross-cutting concerns - like transactions, can be done this way.
That's another thing I want to be explicit, if I have some code that is going to to do a bunch of updates I want it to demand a transaction as part of it's interface. I don't want it hoping it gets executed in the scope of a magic layer that will handle the transaction.
The common theme with AOP is that it takes stupid simple code into an opaque mess spread across a dozen classes that's far harder to maintain.