commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ola Berg <>
Subject [reflect] Proposals:
Date Sun, 16 Jun 2002 19:51:40 GMT
Dimitri wrote:
>Perhaps I misunderstood what the proposal was all about.  My understanding
>was that it was after introspection rather than pure reflection.  When I
>hear the word \"reflection\", the list of features that comes to my mind is:

No, I don\'t think you misunderstood. Hey, we are trying to make something new here, the limits
aren\'t set, borders ain\'t drawn.

Reflection in JVM is basically set and very low level. What people already do with reflection/introspection
is useful and often very high level. I challenged your proposal by trying to draw a sketchy
level for this new package, placing it somewhere in the middle: make reflection utility for
often-needed mechanisms, thus supporting (as opposed to implementing) a lot of high level

Using Java reflection is straight forward, once you have the right Method objects. I believe
that the low level operations in the package should deal with these two issues:

1) Means to easily select the right set of Methods (hopefully dynamically), and defining groups
or categories of Methods (just like setters are one category of Methods) with some kind of
Method category definition (a Rule, a Predicate, whatever)

2) Caching of the reflection look-up results, for performance issues.

These two are very low-level issues with java.lang.reflect, but I believe important ones.

The second question is how high this package should go (in terms of \"levels\"), still maintaining
a good separation of concerns. Maybe the ideas we come up with will result in different packages
at different levels, who knows? 

Anyway: don\'t limit your thoughts based on anything I come up with. My personal signal-to-noise
ratio is low, I admit that...


0733 - 99 99 17

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message