8 ms·

getInstrumentableClassLoader() Return a ClassLoader that supports instrumentation through AspectJ-style load-time weaving based on user-defined Cl

getInstrumentableClassLoader() Return a ClassLoader that supports instrumentation through AspectJ-style load-time weaving based on user-defined ClassFileTransformers. Oh man... I admire the people who have invented this. But at the same time I feel sorry for those who have to use this in order to earn their living.

thomk 7y ago
Stuff like that always makes me feel like someone has turned off their logical reasoning and they are just basically creating code that fills in some personal mental gap that somehow 'completes the set' of the things they are working on at the moment.
- smitty1e 7y ago
  I always figured that Java folks were - paid per class - sought to reduce the number of executable lines per class to 1.
  - AmericanChopper 7y ago
    But that’s just OOP in general. You can choose a language that defaults to not using OOP-style abstractions, but then people will question why you choose python/node/ruby over a proper language like Go (or whatever else)
    - mewpmewp2 7y ago
      I will be honest and tell them it is because these are more productive and I enjoy being productive
      - AmericanChopper 7y ago
        How productive you are with any particular tool really depends on what you’re trying to do with it.
    - oreally 7y ago
      > But that’s just OOP in general. Nope, that's OOP taken to extremes rather. Java does that with enforcing things to be classes.
      - AmericanChopper 7y ago
        The OOP paradigm itself requires rather heavy use of abstraction. You can deviate from those patterns to an extent, you can add more polymorphism if you want to, you can be selective in using some design patterns like DTOs. But most of the complaints I hear about Java would apply equally to most of the C# projects I’ve worked on, because those are just the annoying bits of OOP. I’d agree the Java is a bit more inflexible, but it’s not like the other OOP languages aren’t also full of boilerplate and layer upon layer of abstractions.
  - UK-Al05 7y ago
    Tbh that was Alan Kay's vision of object oriented programming. Lots of tiny objects collaborating via messages.
    - goatlover 7y ago
      Was it tiny objects or tiny messages, or both? And I wonder how much of the Smalltalk system was made that way. I think at some point your class needs to handle some complexity that isn't easily broken into smaller classes.
  - overgard 7y ago
    I actually knew a guy that argued that one method per class is ideal. He never quite got that at that point you're really just writing a function with a manual closure (the constructor).
- danielscrubs 7y ago
  Exactly! Almost nothing in the naming based on something with a very precise definition. It's the unruly mind coming up with generalised words.
zerkten 7y ago
The people that use Spring love it, well, at least they did when I was last working with them. They also loved talking about patterns, often didn't have enough traffic to stress the systems built on these relatively heavy object hierarchies, and were relatively comfortable (the only competition was the other half of the company using .NET.)
- therealdrag0 7y ago
  lol. In my experience, in the enterprise world, yes people liked Java/spring, but also where comfortable giving it a ribbing. Everyone loved python but didn't get to use it for main-business code, and the Go and Scala projects have been very conflicted with both lovers and haters. In my ~20 person division, 1 person quit and another transferred with the main reason being their dislike of Scala!
chii 7y ago
It does have it's place. Aspect oriented programming will allow you to write, for example, logging code that are very configurable. It allows you to remove the concern of logging from your classes completely. In fact, any cross-cutting concerns - like transactions, can be done this way. So you can write code that don't care about transactions, but behind the scenes, it is all within a single transaction, and transaction errors are handled centrally. It adds runtime costs of course. And the more you add this way, the more complicated it becomes. And certainly can be abused.
- lmm 7y ago
  Just use a language where it's possible to implement those things in plain old code. When you have higher-kinded types you don't need any bytecode manipulation, you can just have a type that wraps anything that needs to happen in a transaction, and compose together transactional operations in a visible but type-safe way - and you don't even need the runtime cost. How anyone can look at Java as it's actually used and say Scala is too complex is beyond me.
  - quelltext 7y ago
    You can also do it visibly in Java without too much noise IMO. The point of AspectJ is to hide this stuff completely from application code (but it's still visible in its definitions). Whether that makes sense or not I'm not going to debate (I personally don't think AspectJ is particularly great) but arguing that other languages allow you to do that in a more or less visible way is besides the point. AspectJ is a language, these aspects are visible and have their own language abstractions, just separate from the application code. Just like you have monad implementations separate from their uses. So writing aspects is also "plain code". How the weaving happens (at compile time/load time, on source code or on bytecode, etc.) is an implementation artifact Also, AspectJ isn't Java and the problems AspectJ tries to solve and the approach apply to a bunch of languages and variants for functional languages also exist.
    - lmm 7y ago
      > AspectJ is a language, these aspects are visible and have their own language abstractions, just separate from the application code. Just like you have monad implementations separate from their uses. So writing aspects is also "plain code". Code containing aspects is certainly not plain Java code, because the aspect annotations (or, worse, invisible string-name based pointcuts) change the behaviour of the code they're on, breaking the normal rules of the language. You'll see "impossible" behaviour at runtime: call a method and the call stack jumps to a completely different method. A method throws an exception that's thrown nowhere in its body. If you want to say that AspectJ is a language in its own right, then it's a language that breaks all the rules of good language design: it essentially contains COMEFROM as a core language feature. Whereas monad implementations are (generally) plain old code that follows the normal rules of the language. > Also, AspectJ isn't Java It (or other libraries that do much the same thing) is the vast majority of Java as it actually exists in the real world. I've yet to see a substantial Java codebase that wasn't using some form of AOP or reflection (even if only indirectly via these big frameworks).
watwut 7y ago
Spring is not hard to use. It is popular because it is comfortable.
einpoklum 7y ago
Am I a weird person if that one doesn't seem very egregious to me? The class loader is an important entity for a Java app. And you can have more than one (although this is advanced voodoo already). So, an instrumented class loader.
blackrock 7y ago
This reads like a circular definition.

thomk 7y ago

Stuff like that always makes me feel like someone has turned off their logical reasoning and they are just basically creating code that fills in some personal mental gap that somehow 'completes the set' of the things they are working on at the moment.

smitty1e 7y ago
I always figured that Java folks were - paid per class - sought to reduce the number of executable lines per class to 1.
- AmericanChopper 7y ago
  But that’s just OOP in general. You can choose a language that defaults to not using OOP-style abstractions, but then people will question why you choose python/node/ruby over a proper language like Go (or whatever else)
  - mewpmewp2 7y ago
    I will be honest and tell them it is because these are more productive and I enjoy being productive
    - AmericanChopper 7y ago
      How productive you are with any particular tool really depends on what you’re trying to do with it.
  - oreally 7y ago
    > But that’s just OOP in general. Nope, that's OOP taken to extremes rather. Java does that with enforcing things to be classes.
    - AmericanChopper 7y ago
      The OOP paradigm itself requires rather heavy use of abstraction. You can deviate from those patterns to an extent, you can add more polymorphism if you want to, you can be selective in using some design patterns like DTOs. But most of the complaints I hear about Java would apply equally to most of the C# projects I’ve worked on, because those are just the annoying bits of OOP. I’d agree the Java is a bit more inflexible, but it’s not like the other OOP languages aren’t also full of boilerplate and layer upon layer of abstractions.
- UK-Al05 7y ago
  Tbh that was Alan Kay's vision of object oriented programming. Lots of tiny objects collaborating via messages.
  - goatlover 7y ago
    Was it tiny objects or tiny messages, or both? And I wonder how much of the Smalltalk system was made that way. I think at some point your class needs to handle some complexity that isn't easily broken into smaller classes.
- overgard 7y ago
  I actually knew a guy that argued that one method per class is ideal. He never quite got that at that point you're really just writing a function with a manual closure (the constructor).
danielscrubs 7y ago
Exactly! Almost nothing in the naming based on something with a very precise definition. It's the unruly mind coming up with generalised words.

zerkten 7y ago

The people that use Spring love it, well, at least they did when I was last working with them. They also loved talking about patterns, often didn't have enough traffic to stress the systems built on these relatively heavy object hierarchies, and were relatively comfortable (the only competition was the other half of the company using .NET.)

therealdrag0 7y ago
lol. In my experience, in the enterprise world, yes people liked Java/spring, but also where comfortable giving it a ribbing. Everyone loved python but didn't get to use it for main-business code, and the Go and Scala projects have been very conflicted with both lovers and haters. In my ~20 person division, 1 person quit and another transferred with the main reason being their dislike of Scala!

chii 7y ago

It does have it's place. Aspect oriented programming will allow you to write, for example, logging code that are very configurable. It allows you to remove the concern of logging from your classes completely. In fact, any cross-cutting concerns - like transactions, can be done this way. So you can write code that don't care about transactions, but behind the scenes, it is all within a single transaction, and transaction errors are handled centrally. It adds runtime costs of course. And the more you add this way, the more complicated it becomes. And certainly can be abused.

lmm 7y ago
Just use a language where it's possible to implement those things in plain old code. When you have higher-kinded types you don't need any bytecode manipulation, you can just have a type that wraps anything that needs to happen in a transaction, and compose together transactional operations in a visible but type-safe way - and you don't even need the runtime cost. How anyone can look at Java as it's actually used and say Scala is too complex is beyond me.
- quelltext 7y ago
  You can also do it visibly in Java without too much noise IMO. The point of AspectJ is to hide this stuff completely from application code (but it's still visible in its definitions). Whether that makes sense or not I'm not going to debate (I personally don't think AspectJ is particularly great) but arguing that other languages allow you to do that in a more or less visible way is besides the point. AspectJ is a language, these aspects are visible and have their own language abstractions, just separate from the application code. Just like you have monad implementations separate from their uses. So writing aspects is also "plain code". How the weaving happens (at compile time/load time, on source code or on bytecode, etc.) is an implementation artifact Also, AspectJ isn't Java and the problems AspectJ tries to solve and the approach apply to a bunch of languages and variants for functional languages also exist.
  - lmm 7y ago
    > AspectJ is a language, these aspects are visible and have their own language abstractions, just separate from the application code. Just like you have monad implementations separate from their uses. So writing aspects is also "plain code". Code containing aspects is certainly not plain Java code, because the aspect annotations (or, worse, invisible string-name based pointcuts) change the behaviour of the code they're on, breaking the normal rules of the language. You'll see "impossible" behaviour at runtime: call a method and the call stack jumps to a completely different method. A method throws an exception that's thrown nowhere in its body. If you want to say that AspectJ is a language in its own right, then it's a language that breaks all the rules of good language design: it essentially contains COMEFROM as a core language feature. Whereas monad implementations are (generally) plain old code that follows the normal rules of the language. > Also, AspectJ isn't Java It (or other libraries that do much the same thing) is the vast majority of Java as it actually exists in the real world. I've yet to see a substantial Java codebase that wasn't using some form of AOP or reflection (even if only indirectly via these big frameworks).

watwut 7y ago

Spring is not hard to use. It is popular because it is comfortable.

einpoklum 7y ago

Am I a weird person if that one doesn't seem very egregious to me? The class loader is an important entity for a Java app. And you can have more than one (although this is advanced voodoo already). So, an instrumented class loader.

blackrock 7y ago

This reads like a circular definition.