Native compliation of EJB deployments


Performance and scalability: Native compliation of EJB deployments

  1. Native compliation of EJB deployments (5 messages)

    On the topic of performance, products such as TowerJ ( enable you to natively compile an entire application server, along with the beans inside of it, into a high-performing binary. The binary is platform-specific, but the code remains portable.

    This IMHO is one of the EJB industry's best-kept secrets.

    1) Performance increases. The code is no longer interpreted.

    2) In theory you can actually reduce the cost of your deployment, because the code is not interpreted, therefore you need to purchase fewer processors, which means fewer application server licenses.

    I am looking for some comments on this idea, and/or war stories about using such native compilers.
  2. Native compliation of EJB deployments[ Go to top ]

    Seems to me that big, smart companies like BEA and IBM wouldn't ignore this option if it were real. My understanding is that WebSphere App Server, per ejemplo, requires a particular JVM, and thus would not be compatible with TowerJ, which brings its own? But treat this as supposition, because I have not tried it or asked IBM Engineers about it.
  3. Native compliation of EJB deployments[ Go to top ]

    hello Ed,

    In the case of such native compilers, the question I have is what happens when deploying new beans. Would it be possible to do incremental compiles and add to an existing binary? Do an entire recompile would doubtless take a humungous amount of time. I have battled with this problem in previous C++ projects where each time we invoked the HP-C++ compiler to create the Application server binary the guys would go out for a coffee and smoke. We need the equivalent of the DLLs here in the Java world as well.

  4. Native compliation of EJB deployments[ Go to top ]

    To answer your question, yes, they can compile incrementally. They can package Java classes in DLLs that get dynamically loaded into the EXE. Even if you forget some classes, they will be loaded as normal.

    Remember that even this (IMHO) should not truly be necessary in most deployments, because you will only really use the native compiler as a final post-processing before going live.

    As far as JDKs, you'd have to check with your native compiler vendor for those answers.

  5. In the whitepaper it says "TowerJ supports all the standard enterprise Java API's such as JNI, RMI, JDBC, Servlet, Enterprise JavaBean and JavaServer Page..."

    Does this mean that all app server logic is included (doubtful) or TowerJ will compile existing app server into native code?
  6. Does anybody know some another native compilers for x86 ?
    TowerJ may be great, but it is too expensive and evaluation version expires too fast to evaluate something.

    Btw, one of my applications got WORSE performance after compiling it with TowerJ.