TowerJ 3.9 VM Release Available for Solaris and Linux

Discussions

News: TowerJ 3.9 VM Release Available for Solaris and Linux

  1. Tower Technology has announced the availability of TowerJ 3.9 for Solaris and Linux server. TowerJ is a Java to native code compiler/VM, calling itself a 'ahead-of-time' compiler, that also supports Java's dynamic features. TowerJ 3.9 is Java Certified, and features new threading capabilities, improved garbage collection and other optimizations.

    Check out TowerJ 3.9 (immediate download not available).

    Read the Press Release.
  2. Is there really a market for this stuff any more? Back in the days when the standard VMs performed very poorly, I could see the value in TowerJ. But I have absolutely no complaints about Hotspot's server-side performance these days. It's more than fast enough.
  3. They claim:

    "When properly utilized, TowerJ can provide significant benefits in one or more of the following areas:

    1. Application Performance
    2. Application Scalability
    3. Lower Development Costs
    4. Lower Deployment Costs
    5. Intellectual Property Protection
    6. Simplified Packaging & Distribution"

    (1) seems possible.
    (2) perhaps less of an argument now we have javax.nio.
    (3) and (4) doubtful.
    (5) interesting - they are pushing this a lot more these days on the basis that decompiling executable code is much harder/less useful than decompiling obfuscated bytecode.
    (6) seems doubtful.

    So I think it depends what your program does and whether you believe their claims.
  4. (5) interesting - they are pushing this a lot more these days on the basis that decompiling executable code is much harder/less useful than decompiling obfuscated bytecode.

    Yes but security by obscurity hardly something you would want to rely on. It seems a complicated route is the only benefit is to protect bytecodes. After all you have to make releases for different platforms, something that we got away from with Java.

    I would suggest something like the free Marvin tool does a pretty good job of obfuscation and it can be integrated in Ant as part of the build process. At least you've got real Java code at the end.

    David
  5. Speaking for Tower Technology in response to the "doubtful" Thomas Sedge :-)

    >"When properly utilized, TowerJ can provide significant benefits in one or
    more of the >following areas:

    >1. Application Performance
    >2. Application Scalability
    >3. Lower Development Costs
    >4. Lower Deployment Costs
    >5. Intellectual Property Protection
    >6. Simplified Packaging & Distribution"

    >(1) seems possible.

    As you state below, it is dependent on the nature of your application. We
    make no claim to being a "silver bullet" for all Java performance needs on
    all platforms, but we do continue to work towards broadening the scope of
    applications to which we can provide a performance and scalability benefit.

    >(2) perhaps less of an argument now we have javax.nio.

    "We" may have .nio, but for various reasons, many do not have the option -
    third party product choices, etc. For those who don't, TowerJ often yields a
    scalability benefit even if there is not a substantial performance benefit.
    We will provide .nio support in our upcoming 1.4 compatible release.

    >(3) and (4) doubtful.

    Based on your application and needs, and whether you consider open-ended
    cycles of profiling, tuning, modification and testing as a development
    cost. These cycles can end up introducing more problems in an already
    stable system and end up with a higher cost than using TowerJ. An evaluation
    license of TowerJ is available for free.

    Again, based on your application and specific project needs. With deployment
    expenses consisting of both hardware and the third-party software licensed
    for that hardware, the cost of a "best-of-breed" application server license
    for a SINGLE CPU can easily outweigh the cost of TowerJ for your entire
    deployment. It is likely, especially in today's economic climate, that this
    will have more appeal to your company's CFO (investors and shareholders)
    than being true to the platform independent mantra of a third-party with no
    vested interest in your business.

    >(5) interesting - they are pushing this a lot more these days on the basis
    that decompiling >executable code is much harder/less useful than
    decompiling obfuscated bytecode.

    This push began as an external one, but seems to be in keeping with the
    adoption of Java. ISV's now using Java in the Pacific Rim are very aware of
    the nature of their marketplace, and are looking for protection - and some
    domestic developers won't sell into those markets for fear of having their
    IP stolen. Our most recent IP sale, yesterday, was to an ISV that wanted to
    widely distribute their product demo, but still protect the valuable code
    that it contained. TowerJ also simplifies installation for the evaluator
    (See 6).

    >(6) seems doubtful.

    (See 5) No JVM or specific version required on the installation machine.
    Enduser doesn't have to worry about finding it, installing it, or conflicts
    with other applications on the system.

    >So I think it depends what your program does and whether you believe their
    claims.

    He is absolutely right, and once again we make no claims to being a "silver
    bullet" for all needs. As I can find no record of Mr. Sedge having ever
    evaluated TowerJ, we can assume he has never had a need himself and his
    doubts are understandable.

    For more information or to register for a free download - www.towerj.com
  6. Hi Matthew,

    You are arguing that there are some application for which TowerJ will provide larger performance benefits, and some types for which it is less useful.

    Could you be more specific?

    For what sorts of applications do you see your native-code compiler providing the largest performance advantages?

    thanks,

    Sean
  7. Hello Sean,

    My apologies for the delay in responding to your post.

    >You are arguing that there are some application for which >TowerJ will provide larger performance benefits, and some >types for which it is less useful.

    It wasn't my intent to argue, but to respond to the doubt cast on the viability of our solution.

    >Could you be more specific?
    >
    >For what sorts of applications do you see your native-code >compiler providing the largest performance advantages?

    Many factors can influence application performance and every application is different so it is difficult to be extremely specific.

    The most general statement we can make is that applications that are computationally intensive, or CPU-bound benefit the most.

    A more specific description (for our most current release, of course) would be - a CPU-bound, thread intensive application, with minimal to no dynamic updating, deployed on a multi-CPU Linux or Solaris machine with a high scalability requirement - will see the most significant benefit from native compilation with TowerJ.

    We provide no benefit for I/O bound applications and just a slight efficiency in database bound applications by allowing you to compile your JDBC driver into the executable.

    For more on these types of applications, please visit the following: http://www.towerj.com/products.html

    Regards,

    Matthew
  8. This looks like another great bonus for the Java platform.

    It's because of the maturity of the platform and welth of products like this, that our company is making the swtich from MS only development tools to Java.

    We'll have to wait and see just how good it is, but the fact that it's there is a real benefit.