you forget a very important argument with AOP, you can execute code in an orthogonal way: to a class, a package, or any pattern you’d like there’s no need to actually call the code whether that’s a good thing or not, i don’t judge i know the current trend is to assume explicit is better and yes, to reveal the code by clicking on the function is a good thing yet, i’m a bit more nuanced than your article

AOP is very popular

... mmmmh

Surely it depends on your definiton of very, but I consider it being quite popular.

for example, aop lets you apply logging/authorization to code outside your scope

And you very limited here (in case of runtime AOP without java agent), since only top-level objects can be processed. Like you have 3rd party class

Foo

with method

doThings

, and

doThings

creates new instance of

Bar

inside, so

Bar

methods will not be intercepted

Both approaches have their merits, the "functions" one is frequently overlooked though, while AOP is arguably the default (thanks, frameworks). So this article is a good reminder it exists, especially for new Kotlin devs.

@elizarov When was last time you heard something positive about pointcuts? Or actually even heard anything about the concept at all? Or AspectJ? Or Aspectwerkz? What AOP frameworks are you thinking of? AOP has been dead for a solid decade now.

@cedric except for Spring which plasters everything with annotations. I don't know any non-Spring users actually using AOP

@janvladimirmostert you might update your view on spring... with java 5, every lib/framework started over-using annotations latest spring versions offer a functional path, either in plain java or with kotlin DSL

@nfrankel care to give an example? I've last used Spring3, abandoned Spring when the upgrade path to Spring4 and then Spring5 had too many breaking changes.

this is the pinnacle (don’t use it in production yet) of what they want to achieve:

class Application {
	
  private val httpHandler: HttpHandler
  private val server: HttpServer
  private var nettyContext: BlockingNettyContext? = null
  
  constructor(port: Int = 8080) {
    val context = GenericApplicationContext().apply {
        beans().initialize(this)
        refresh()
    }
    server = HttpServer.create(port)
    httpHandler = WebHttpHandlerBuilder.applicationContext(context).build()
  }

  fun start() {
    nettyContext = server.start(ReactorHttpHandlerAdapter(httpHandler))
  }
	
  fun startAndAwait() {
    server.startAndAwait(ReactorHttpHandlerAdapter(httpHandler),
        { nettyContext = it })
  }
	
  fun stop() {
    nettyContext?.shutdown()
  }
}

fun main(args: Array<String>) {
  Application().startAndAwait()
}

not a single annotation but everything needs to be declared ref: https://spring.io/blog/2017/08/01/spring-framework-5-kotlin-apis-the-functional-way

Spring Boot is horrible, that above snippet you posted actually looks readable. If Spring no longer uses AOP, then isn't AOP practically speaking dead?

😞

Ktor, VertX, ... lets met start a project in minutes too, i've created three complete standalone services in the last 2 days. Spring Boot requires extensive training to know where you can touch and shouldn't touch, how to configure it and sometimes you hit problems where Spring Boot gets in your way. Discussing Spring though is off-topic since we're discussing AOP in this thread and not the pros / cons of Spring.

you introduced spring in this thread, not i 🙂 as for aop, i’ll repeat my arguments above it lets you execute code as an after thought in a consistent way the logging example is a great one asking developers to log arguments and return values in debug/trace is doomed to fail because it’s too easy to forget while a simple aspect can automate it transactions is a bit more far-fetched, i admit but because transactions are meant to be on the “service” layer why not make every

@Service

function transactional as well? using aop, it’s a no-brainer setting it explicitly, not that much - whether by annotation or by calling it through a function you want to measure the execution time of a function call chain? aop dynatrace, introscope, etc. they are all based on aop

@cedric I did not use the “pointcut” term for a reason — nobody neither knows nor uses it. Yet people use AOP all over the place in JVM ecosystem when they work with annotation-based frameworks.

@nfrankel I've seen code where somebody was "smart" and made every service call

@Transactional

, that code ended up deadlocking the database since developers weren't aware that the service calls were all transactional. I can see limited use for it in Java, in Kotlin for the majority of use-cases, there's a more elegant way of doing it that doesn't hide code. @elizarov does Hibernate use AOP or is that just regular annotation scanning?

@janvladimirmostert i think our main point of disagreement is that:

doesn’t hide code

it’s very trendy now but the balance shifts every now and then

@janvladimirmostert That depends on your definition of AOP.

We’re probably quibbling over definitions, but to me AOP implies pointcuts: generic descriptions of code location where some code is automatically inserted. If a solution doesn’t supply this, it’s not AOP. Not saying it’s a good or a bad thing.

The

@Transactional

vs

transactional{}

is not a super strong argument IMO. Most people do not annotate each method, they annotate their Repo or Service classes. The advantage with annotating the class is that your developers always know the default transactional behavior by which layer the class lives in.

Here is the cutting edge of functional non-aop spring boot: https://github.com/spring-projects/spring-fu/blob/master/kofu/README.adoc

but no production-ready yet and you must embrace reactive programming

Yep. But it is an exciting direction

Ha. Just found this thread. I have a confession... I've been using AspectJ in my Android apps since about 2010. 🧌 ...the Transform API changes during Gradle 2-4 made this a labour of love and I've never advocated it's use at work... ...but... ...I've used AOP to do some pretty cool things. The usual db transactionality a la hibernate/spring's

@Transactional

(as someone mentions above - yes - it is AOP), but also method tracing for ID'ing frozen frames (ever tried actioning those frozen frame metrics in Android Vitals? You're gonna need to get you logging on... everywhere and report the Framemetrics in via something like Firebase Perf). And most recently, Analytics! Much of my event based analytics code is now woven in via Aspects...I'm not sure still how I feel about this. I've never liked seeing Analytics code in the mainline and I've had problems in the past of events going missing in releases which were annoying. Aspects kind of help here and I can unit test by asserting the class/method meta-data which is awesome... especially when adding events to legacy (read: hard to test) code