Several good points, and so much to comment on. I will restrict myself to repeat that Java already has several mechanisms to enforce capabilities, and that this

Several good points, and so much to comment on. I will restrict myself to repeat that Java already has several mechanisms to enforce capabilities, and that this is mainly an exercise in API design. However, the article fails to recognize that Log4j (and probably other libraries) have different capability requirements at different points in time and in code. At startup and when reloading configuration, only access to some severely restricted JNDI lookups should be allowed. Core message formatters and lookups should have minimal privileges. Appenders require access to network and filesystem APIs though! The capability style presented by TA requires the ability to use of Dependency Injection to properly inject handles that permit access to restricted APIs. This is quite fine in the case of Log4j, which allows programmatic configuration, but it would force developers to give more cababilities than strictly required to more monolithic components!