yourfanat wrote: I am using another tool for Oracle developers - dbForge Studio for Oracle. This IDE has lots of usefull features, among them: oracle designer, code competion and formatter, query builder, debugger, profiler, erxport/import, reports and many others. The latest version supports Oracle 12C. More information here.
Cloud Expo on Google News
Cloud Expo & Virtualization 2009 East
Smarter Business Solutions Through Dynamic Infrastructure
Smarter Insights: How the CIO Becomes a Hero Again
Windows Azure
Why VDI?
Maximizing the Business Value of Virtualization in Enterprise and Cloud Computing Environments
Messaging in the Cloud - Email, SMS and Voice
Freedom OSS
Stairway to the Cloud
Sun's Incubation Platform: Helping Startups Serve the Enterprise
Cloud Computing & Enterprise IT: Cost & Operational Benefits
How and Why is a Flexible IT Infrastructure the Key To the Future?
Click For 2008 West
Event Webcasts
Performance in J2SE 5.0
What's new and what's faster

If you're a Java developer like me you ask two questions about every major J2SE release. What's new, and what's faster (or slower). Tiger includes a large number of well-publicized, high-profile features like generics, annotations, or the full new API for concurrent programming.

But the adoption of new features usually takes time, and until your J2EE product is updated to the new JRE; your corporate clients' admins let the new JREs pass; large teams get acquainted with new features, or complex systems are carefully redesigned to take advantage of such features. But even in these situations, it's always possible to move to the new J2SE as an optional deployment platform, just for the "free lunch" benefits of better performance or, as in J2SE 5.0, the JVM management features.

My approach here is to look at J2SE 5.0 as an improved runtime for existing apps. I'm sure that all the hard-working people at Sun and the many Tiger JSRs will be mad if developers don't hurry to all those cool new APIs and language features, but using J2SE 5.0 as "just a better runtime" is a good kick-in-the-door to push Tiger - remarkably inside more conservative shops where the rule of "if it ain't broken, don't fix it" drives advanced developers crazy. My personal answer is simple; if it's slow, then it is broken, and if the new JVM is faster, then the old is slow and therefore broken, and so are all my apps! But some facts are needed to substantiate this argument.

While J2SE updates always bring new optimizations and performance enhancements, it's also true that major new versions of any software (remarkably dot-zero ones) are often suspect of being "big bloated new version," and Java's no exception. Before proving that J2SE 5.0 is any faster than 1.4.2, we must first show that it's not slower, obeying the Hippocratic rule "First do no harm." So we'll approach each aspect of Java performance critically, first checking whether Tiger risks making anything worse, and only then looking at the possible gains.

New Features
New APIs are often bigger and more sophisticated than their predecessors (like Swing in Java 2 compared to the old AWT). This is what makes people cry, "Bloat!" (Until they can't live without the new API.) The good thing is that you only bother about the resource requirements of a new API, or about its performance, relative to previous alternatives. On the other hand, any performance advantages won't be collected before the new API is used. In short, existing apps shouldn't be affected, for better or worse, if deployed unchanged with the new runtime.

J2SE 5.0 adds some big new APIs, but they are useful to a narrow audience.

The new instrumentation, management, and debugging/profiler APIs are good for developing or monitoring scenarios. They have a performance impact, but only if active. If you're debugging, profiling, or monitoring a JVM instance via JMX or SNMP, you're obviously going to pay a price, but otherwise you shouldn't notice any difference because these features are available.

The new concurrency API, one of my Tiger favorites, can be used directly by advanced application developers, but most programmers writing business apps will only use this API indirectly once their middleware (like J2EE containers) are updated to exploit the new APIs. The good news is that when it happens, existing applications will benefit from more efficient concurrency (better performance and scalability) without any change.

J2SE 5.0 adds many small APIs, like those for formatting/scanning, but these won't have a significant impact in the footprint or other performance measures of most applications except perhaps in specialized apps that make heavy use of such APIs - e.g., some ETL tool that's rewritten to use java.util.Scanner to parse monster-sized text files.

Unlike the AWT Swing transition, there won't be a rush to port application code to a major new API from Tiger because there are no new APIs that are as broadly appealing. All the new Tiger features that should become "pop hits" are language-level features, even though some of them are supported by new improved APIs.

Generics have no performance (dis)advantages. That's part of the erasure deal; javac uses the generic types to do static validations, then discards these types, so the bytecodes produced are the same as usual (including typecasts). Classes and methods supporting generic parameters will grow a bit because javac will generate extra signature metadata in the .class files. But there's no impact at all on code that only uses generic types, either in the traditional way (e.g., declaring an ArrayList) or with the new generic syntax (e.g., declaring an ArrayList<String>).

Annotations tell a similar story. New metadata can be stored in the .class files, and be available through reflection. If you consider the amount of metadata that's already hacked into J2EE descriptiors, javadoc tags (especially with annotation-like tools such as Xdoclet), and the large number of new JSRs currently in development to define annotations for everything (servlets, EJB, Web Services, JDBC, and so on), it feels like a possible source of lots of space overhead. Fortunately, the Java annotation facility lets these overheads be controlled. The meta-annotation "Retention" ranges from SOURCE (zero overhead) to CLASS (it only makes classfiles bigger) and RUNTIME (annotations are available for reflection inspection, which consumes memory).

Other language enhancements like enhanced for, static import, autoboxing, and enums, have no direct performance impact good or bad. These features are mostly "syntax sugar." Indirectly, however, these features create some opportunities to change your performance. Autoboxing makes it all too easy to work with wrapped primitive values, e.g., to put integers inside collections. New code can use autoboxing carelessly in situations where one could work a bit harder (e.g., using primitive arrays instead of collections). On the other hand, when autoboxing replaces old code that used wrapper classes, the result should be more efficient. Autoboxing doesn't use wrappers' constructors (e.g., new Integer(99)), it uses new factory methods (Integer.valueOf(99)) that return cached objects for the most frequent values (like ints from -128 to +128). (You can also invoke these new methods manually.)

Updated Features
Updated APIs are a gray area. They may impact your performance even if you don't use the new or improved features. Even if you don't use any new methods, footprint and speed can be impacted when the improvements involve architectural changes to the APIs. There are some "suspects" in this category for J2SE 5.0.

The Unicode spec was updated in version 4.0, including characters that don't fit anymore in the 16-bit char type, requiring a pair of values for some extended characters. APIs for Strings, text formatting, and regex had to be updated for full compatibility with this new standard, breaking some assumptions that we thought cast in stone - e.g., String.length() still returns the number of chars in the string, but not necessarily the number of lexicographical units. This is now only assured by the new String.codePointCount() method. If you're a heavy user of core string classes (including the new StringBuilder), don't worry; the existing methods don't do anything to support Unicode 4.0; that's why there are new methods for this. But if you're a heavy user of higher-level text processing APIs, like java.util.regex.Matcher, their performance may have changed even if your app doesn't use the new Unicode characters, because the latter APIs will need to use the newer String methods anyway to be safe just in case the text contains Unicode 4.0 characters.

About Osvaldo Pinali Doederlein
Osvaldo holds an MSc in software enginnering and works as technology architect at Visionnaire S/A, developing J2EE technology-based applications.

In order to post a comment you need to be registered and logged in.

Register | Sign-in

Reader Feedback: Page 1 of 1

Latest Cloud Developer Stories
At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools availabl...
Isomorphic Software is the global leader in high-end, web-based business applications. We develop, market, and support the SmartClient & Smart GWT HTML5/Ajax platform, combining the productivity and performance of traditional desktop software with the simplicity and reach of the ...
92% of enterprises are using the public cloud today. As a result, simply being in the cloud is no longer enough to remain competitive. The benefit of reduced costs has normalized while the market forces are demanding more innovation at faster release cycles. Enter Cloud Native! C...
Financial enterprises in New York City, London, Singapore, and other world financial capitals are embracing a new generation of smart, automated FinTech that eliminates many cumbersome, slow, and expensive intermediate processes from their businesses. Accordingly, attendees at th...
Where many organizations get into trouble, however, is that they try to have a broad and deep knowledge in each of these areas. This is a huge blow to an organization's productivity. By automating or outsourcing some of these pieces, such as databases, infrastructure, and network...
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
Click to Add our RSS Feeds to the Service of Your Choice:
Google Reader or Homepage Add to My Yahoo! Subscribe with Bloglines Subscribe in NewsGator Online
myFeedster Add to My AOL Subscribe in Rojo Add 'Hugg' to Newsburst from CNET Kinja Digest View Additional SYS-CON Feeds
Publish Your Article! Please send it to editorial(at)!

Advertise on this site! Contact advertising(at)! 201 802-3021

SYS-CON Featured Whitepapers
Most Read This Week