- It's a free download, with IBM devWorks registration (with an id corresponding to your email address.)
- It's a 500K download, with a stated requirement of IBM Java 1.5 - 500K isn't bad, as it includes agents for a lot of runtimes and operating systems. Configuring the agents means unzipping the jar that conforms to your OS/processor configuration, and using the contained files as JVM options. Unfortunately, your Humble Editor doesn't have an IBM system to install the Windows JRE for IBM, and honestly, installing Yet Another Eclipse doesn't appeal, so I couldn't try it out for you. My deepest apologies, as the readme makes it look quite interesting.
- Tools like this are important already - and with the growing number of multi-processor or multi-core systems, they'll become even more important. (Unless you have something like an Azul box, that is, but that's cheating.)
News: Lock Analyzer for Java from IBM developerWorks
Many of today's Java applications use threads to support concurrent programming. IBM Lock Analyzer for Java is a cross-platform tool that provides insight in to how well Java locks are performing in a live Java application, and highlights threads with lock contention that could affect performance. Editor's notes
- Posted by: Ida Momtaheni
- Posted on: September 12 2007 10:54 EDT
Does anyone know why IBM restricts use of their windows JDK to only IBM hardware? I'm mostly curious if there is an underlying legal reason (like some sorta agreement with Sun), or if it just some silly scheme to try to make people buy IBM machines. A little bird told me that if you download a trial of Websphere Application Server for windows, you can get an unencumbered version of the JDK bundled with it.
A little bird told me that if you download a trial of Websphere Application Server for windows, you can get an unencumbered version of the JDK bundled with it.I'm not a little bird, and I can tell you that IBM's distribution of Eclipse uses IBM's JRE, and it's not encumbered either.
In my opinion a much more pressing issue that also needs to be addressed is the lack of ** runtime ** insight into the inter-dependencies between the jobs scheduled across threads via thread pools. Developers are encouraged to partition processing into smaller execution units (Runnables) of work that can be (queued and) executed concurrently across one or more threads to improve efficiency, utilization and responsiveness but at a cost of increased complexity. Todays traditional debuggers and profilers are not contextual - they can only see code (the effect without cause). We have recently adapted our distributed tagging and tracing technology in an attempt (a good attempt I believe) to see whether we could visualize the loosely coupled dependency between the thread queuing work unit and the thread executing the work unit. Blog Entry: Parallel & Remote Tracing http://blog.jinspired.com/?p=144 By the way since version 3.0 (a very long time ago) of our product we have offered thread monitor blocking times for all trace and transactional analysis extensions. http://www.jinspired.com/products/jxinsight/tracing.html regards, William Louth JXInsight Product Architect CTO, JINSPIRED http://www.jinspired.com