One of the nice new features in the latest draft of JSR-299 is the ability to inject a reference to all beans of a certain type, for example:
@Any Instance<Connection> anyConnections;
There's actually nothing very special about this injection point. @Any is a built-in binding that is defined to be supported by all beans. Instance<T> is an interface which is implemented by a built-in bean that uses InjectionPoint to inspect the binding types of the injection point. (You could implement Instance<T> yourself if the container didn't come with one.)
Now, Instance<T> extends Iteratable<T>, so we can iterate over anyConnections to do something to all beans that implement Connection:
for (Connection c: anyConnections) c.close();
We can narrow the set of connections we're interested in either dynamically:
Connection userDatabaseConnection = anyConnections.select( new AnnotationLiteral<UserDatabase>() {} ).get();
Or using an annotation at the injection point:
@UserDatabase Instance<Connection> userDatabaseConnection;
Of course, we've now got a way to iterate over every bean:
@Any Instance<Object> anyBeans;
for (Object bean: anyBeans) doSomething(bean);
But also, it looks like it's too easy to use incorrectly.
Does the @Any annotation return all the instances in the same classloader?
So for example, would I be able to reference beans I shouldn't?
1) Suppose someone drops a JAR which is loaded by the application server while the application runs.
2) This JAR has code like the above in some static initializer.
3) The code uses these instance references to "steal" data, wreak havoc, etc.
I mean, where's the limit?
If they can a jar, they can a war with a servlet that queries the database and displays the data. Which is a bit more direct, right?
That sounds logical, but it's not true in all scenarios. I have seen situations where the database connection and any direct data operations (where the login and password to the database are known) take place at another semi-isolated tier. The Java server where the malicious JAR is deployed does not necessarily have direct access. You do have a point though, that this might not be very relavant.
But let me express some other concern: When working with many teams, or with very big teams, sometimes teams from many different companies over which you have no control: Don't you think this can help the careless programmers to mess with objects they are not supposed to have access to in the first place? Granted: Thinking about the ones is not the way to go (there are many other ways to mess up), but unfortunately, the company I work for is full of careless programmers and code gets out of control too easily unless a couple of good programmers make sure to go over EVERYTHING every day, which is not practical. This is just too powerful in my opinion :D
Anyway, thanks for the heads up :)