Discussions

Performance and scalability: Performance of reflection in J2EE

Bookmark and Share Get thread feed

  1. Performance of reflection in J2EE (7 messages)

    • Posted by: Nick Leach
    • Posted on: July 04 2001 10:04 EDT
    Does anybody have any experiences of the use of reflection in J2EE and its performance hit?? We are looking at a sort of implementation of the Generic Attribute Access pattern using reflection. In some seperate tests we found an order of magnitude time hit from calling methods through reflection, however what we don't know is how this scales up to an industrial size environment. And is the performance hit really significant when compared to other J2EE activities?

    Any experiences or thoughts would be welcomed,

    Thanks,

    Nick
    Reply to this

    Threaded Messages (7)

  2. Performance of reflection in J2EE[ Go to top ]

    oh nick,

    this is not a good idea. the ejb-spec doesn't allow it.
    but maybe you will use it outside of ejb's.

    have a look for the jboss sources, they use it heavily.
    and marc is really proud about performance numbers ...

    maybe things will work better for you if you will use code generation. uml -> xmi -> java
    reading/writing attribute values happens often!

    have you done the lookup of the (for example) Method object each time or just once and written it to a satic field to reuse it.

    hope i helped you,
    Markus Liedl


    --- you've got a great j2ee project and search still
    --- the right java-guys? contact me: markus dot lado at gmx dot de
    Reply to this Reply to original

  3. Performance of reflection in J2EE[ Go to top ]

    Thanks you for the links. Yes I did do the static initialisation of methods which improves the performance a lot.

    I am a bit puzzled when you say that reflection is not allowed in EJBs. I checked the spec (EJB2, Draft 2, April 24 2001) and all I could find was that you were not allowed to use reflection to access information that would be otherwise disallowed by the Java security rules (section 24.1.2). So surely using reflection to call public methods is OK, since this does not breach any security restrictions??

    Nick
    Reply to this Reply to original

  4. Performance of reflection in J2EE[ Go to top ]

    no it is not. You are disregarding the restrictions placed by the acess-control (Authorization) in this scenario. I'm not sure however if reflection is a good idea, but then I'm not aware of the scenario you want to use it for. In most cases I've gotten away with using interface-adapter pattern, the performance is certainly better.
    Reply to this Reply to original

  5. Performance of reflection in J2EE[ Go to top ]

    I think there is a slight misnomer here. Nick asked about using reflection in J2EE, and a common mistake is for people to assume that J2EE is the same thing as saying EJB.
    According to Sun, the technologies included in J2EE are:
    EJB, JSP, Java Servlet, J2EE Connector, JNDI, IDL, JDBC, JMS, JTA, JTS, JavaMail, and RMI-IIOP.

    Here is the url to a page listing and briefly describing each technology in the J2EE package.

    http://java.sun.com/products/OV_enterpriseProduct.html

    It has been my experience that reflection can be a very useful tool in J2EE development. I haven't ever used it in EJB's but I regularly use it in Servlets, especially when I'm using an MVC pattern, but I've also used it in other constructs without any performance degradation.

    -Newt
    Reply to this Reply to original

  6. Performance of reflection in J2EE[ Go to top ]

    introspection is pretty expensive, but invocations are not, so it is a good idea to cache instrospection results.
    Reply to this Reply to original

  7. Performance of reflection in J2EE[ Go to top ]

    Actually the CocoBase O/R product uses reflection out of
    the box, and beans generated using CocoBase actually
    outperform hand coded JDBC beans that don't use reflection.

    Reflection is actually a trivial overhead in the context of
    database access (around 1% actually). It's much more
    expensive doing a SQL statement and all of the database
    stuff than it is actually doing any reflection.

    And it does scale up quite nicely. We've had customers
    build EJB deployments with millions of accesses per day,
    so we know it's quite scalable. In fact we've found that
    it's much easier for customers to scale apps using our
    generated entity beans than 'stock' beans generated by
    other ide/modeling tools. A lot of it has to do with
    other optimizations and design patterns that give us an
    architectural edge, but nonetheless the reflection side
    of things doesn't seem to have any significant overhead.

    You can also use Session beans with our product that can
    handle object graphs generically, and we also generate what
    we call State object that can serialize the whole contents
    of an EJB bean's attributes as a single network call, work
    on it locally on the client, and serialize it back in a
    network call. It's extremely efficient for large beans with
    lots of attributes and greatly improves the scalability of
    the ejb server.

    Ward Mullins
    CTO
    THOUGHT Inc.
    Reply to this Reply to original

  8. Performance of reflection in J2EE[ Go to top ]

    We already implemented a product that uses reflection, to generically access the attributes of remote objects.
    If anybody wants to evaluate/buy this product, pl. contact
    mahendrad_us at yahoo dot com

    -Mahendra Dhamdhere
    Reply to this Reply to original