Wednesday, March 26, 2008

Flex Conditional Compilation with Clipboard

A particularly handy use of Flex's conditional compilation is to control when debugging information is output or otherwise handled. I discussed placement of fault information on the clipboard in a previous blog entry. In that blog entry, I included a call to place fault information on the clipboard (flash.system.System.setClipboard(<<yourFaultString>>)) in the standard ActionScript fault handler method I had written. The only downside to doing it this way is that fault information would also be placed on all users' clipboards during production use of this code. The virtue of conditional compiling in this case is clear -- we can use conditional compiling to only include the flash.system.System.setClipboard call when in development mode or debugging mode.

Here is an example of using Flex's conditional compilation to only place fault information on the clipboard when in debugging mode. This example is a simple example of a fault handler method that might be used and which will only place the fault information on the clipboard when in debugging mode.


/**
* Generic failure/fault handler.
*
* @param aEvent Failure/Fault event to be handled.
*/
function handleFault(aEvent:FaultEvent):void
{
const mName:String = "handleFault(aEvent)";
const fault:Fault = aEvent.fault;
const messageString:String =
"faultCode: " + fault.faultCode + "\n\n"
+ "faultString: " + fault.faultString + "\n\n"
+ "message: " + fault.message + "\n\n"
+ "rootCause: " + fault.rootCause;
trace( mName + ": " + messageString );
Alert.show(messageString);
CONFIG::debugging
{
flash.system.System.setClipboard(messageString);
}
}


The lines 17-20 above emphasize the conditional compiling and the call to setClipboard that will only occur when CONFIG::debugging is true.

With that code created, the next step is to set the value of CONFIG::debugging. This is set by using the -define compiler flag for the mxmlc compiler.

The next code snippet shows how this might be accomplished in Ant (Flex Ant tasks could also be used and are available from Adobe Labs for Flex 2 and are built-in to Flex 3).


<exec executable="mxmlc">
<arg value="${dir.app.flex}/FlexSlidesExamples.mxml" />
<arg line="-debug=${flex.debug}" />
<arg line="-define=CONFIG::debugging,${flex.debug}" />
<arg line="-use-network=${flex.network}" />
<arg line="-output ${dir.app.build}/${file.swf}" />
</exec>


For convenience, I set the flex.debug property in the build.properties file as either flex.debug=true or flex.debug=true. Note that this value is the same value I use to control whether the .swf compiled file will support debugging.

In a real application, of course, you'd probably want to use conditional compiling as shown here to limit even what is shown on the Alert.show pop-up because it is not likely you want to expose all of those details to users who mostly don't want to see them either.

UPDATE (22 April 2008): As asked in the comment section below and as I responded, conditional compilation appears to be a feature unique to Flex 3 (or, at least, Flex 2 doesn't support the Flex 3 mxmlc compiler option as shown in this blog entry). The two screen snapshots below show conditional compilation with Flex 3's and Flex 2's mxmlc command. As the screen shots show, it compiles successfully for Flex 3, but does not recognize the -define option for Flex 2.

Successful Conditional Compilation with Flex 3


Unsuccessful Conditional Compilation with Flex 2


I have one other update to this blog entry (also updated on 22 April 2008). When one adds the CONFIG::debugging label to the Flex code, it must thereafter be provided to the mxmlc compiler. The next screen snapshot demonstrates the error message seen if this is not passed into the mxmlc command with the -define option.

Monday, March 24, 2008

Online JMX Resources

As I stated in a previous blog entry on aging JMX books, the most popular JMX books are each several years old and are therefore somewhat dated. There have been many advancements in the world of JMX since these books were published. Fortunately, there are many good online resources on JMX and I list some of them here. Although this blog entry is being originally created and posted on 24 March 2008, I plan to add additional resources to this entry as I come across them or remember them. I probably won't add a new date for each new entry.


GENERAL

Java Management Extensions
http://java.sun.com/javase/technologies/core/mntr-mgmt/javamanagement/

Java SE Monitoring and Management Guide
http://java.sun.com/javase/6/docs/technotes/guides/management/toc.html

Understanding JMX Technology
http://java.sun.com/developer/EJTechTips/2005/tt0222.html

Getting Started with Java Management Extensions: Developing Management and Monitoring Solutions
http://java.sun.com/developer/technicalArticles/J2SE/jmx.html

JMX 1.4 Specification
http://java.sun.com/javase/6/docs/technotes/guides/jmx/JMX_1_4_specification.pdf

Java Tutorial: JMX Trail
http://java.sun.com/docs/books/tutorial/jmx/index.html

Java Management Extensions (Dr. Dobb's)
http://www.ddj.com/java/184405718

Instrumenting Applications with JMX
http://www-128.ibm.com/developerworks/java/library/j-jtp09196/index.html

JMX Accelerated How-to
http://admc.com/blaine/howtos/jmx/jmx.pdf

Managing the Unmanaged
http://mxdj.sys-con.com/read/44696.htm

Enabling Component Architectures with JMX
http://www.onjava.com/pub/a/onjava/2001/02/01/jmx.html?CMP=AK

An Introduction to JMXRemote
http://today.java.net/lpt/a/251

JMX Mail Forum
http://forum.java.sun.com/forum.jspa?forumID=537

Using the JMX API for Monitoring and Management
http://www.javapassion.com/handsonlabs/jconsole/docs/jmx-intro.pdf
http://www.nejug.org/2004/include/JMX_NEJUG_081204.pdf

Creating Manageable Systems with JMX, Spring, AOP, and Groovy
http://developers.sun.com/learning/javaoneonline/2007/pdf/TS-1106.pdf

What is JMX?
http://blogs.sun.com/jmxetc/entry/what_is_jmx

Superior App Management with JMX
http://www.javaworld.com/javaworld/jw-06-2001/jw-0608-jmx.html

MXBeans in Java SE 6: Bundling Values Without Special JMX Client Configurations
http://java.sun.com/developer/technicalArticles/J2SE/mxbeans/



JCONSOLE

Using JConsole to Monitor Applications
http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html

Monitoring Local and Remote Applications Using JMX 1.2 and JConsole
http://www.onjava.com/pub/a/onjava/2004/09/29/tigerjmx.html?CMP=AK

Using JConsole
http://java.sun.com/javase/6/docs/technotes/guides/management/jconsole.html

Monitor Your Applications with JConsole - Part 1
http://www.componative2.com/content/controller/developer/insights/jconsole1

Monitor Your Applications with JConsole - Part 2
http://www.componative2.com/content/controller/developer/insights/jconsole2

Monitor Your Applications with JConsole - Part 3
http://www.componative2.com/content/controller/developer/insights/jconsole3

JMX, JConsole, and You
http://java.sun.com/developer/JDCTechTips/2005/tt0315.html#2



JMX IN ENTERPRISE APPLICATIONS

Using JMX to Manage Web Applications
http://www.theserverside.com/tt/articles/article.tss?l=JMXWebApps

Designing Manageable Java EE Platform-Based Applications with JMX API
http://developers.sun.com/learning/javaoneonline/2006/coreenterprise/TS-1956.pdf



BEST PRACTICES AND DESIGN PATTERNS

JMX Best Practices
http://java.sun.com/javase/technologies/core/mntr-mgmt/javamanagement/best-practices.jsp

Apply JMX Best Practices
http://javapro.texterity.com/javapro/200501/?pg=14

Best Practices and Design Patterns for JMX Development
http://conferences.codegear.com/article/32535

Making Optimal Use of JMX in Custom Application Monitoring Systems
http://jdj.sys-con.com/read/478333_2.htm
(Also appears to go by title Practical Considerations When Instrumenting Applications with JMX)

Design Patterns for JMX and Application Manageability
http://www4.java.no/javazone/2005/presentasjoner/JustinMurray/Justin_Murray-DesignPatternsForJMX_javazone2005.pdf



JMX SPECIFICATIONS

Summary of JMX-Related Specifications
http://marxsoftware.blogspot.com/2008/03/jmx-specifications-overview.html



JMX BLOGS

My Blog
http://marxsoftware.blogspot.com/search/label/JMX

Luis-Miguel Alventosa's Blog
http://blogs.sun.com/lmalventosa/

Mandy Chung's Blog
http://weblogs.java.net/blog/mandychung/

Jean-Francois Denise's Blog
http://blogs.sun.com/jmxnetbeans/

Daniel Fuchs's Blog
http://blogs.sun.com/jmxetc/

Eamonn McManus's Blog
http://weblogs.java.net/blog/emcmanus/



RELATED JMX PRODUCTS

OpenDMK
https://opendmk.dev.java.net/

ws-jmx-connector
https://ws-jmx-connector.dev.java.net/

jManage
http://www.jmanage.org/

MC4J
http://mc4j.org/confluence/display/mc4j/Home

MX4J
http://mx4j.sourceforge.net/

Glassbox
http://sourceforge.net/projects/glassbox

VisualVM
https://visualvm.dev.java.net/

Saturday, March 22, 2008

Comparing Unix/Linux, PowerShell, and DOS Commands

The following lists some of my favorite Unix commands and maps the associated PowerShell and DOS commands, if any. If there is one Unix command I would love to have in PowerShell, it is the grep command with its regular expression support. I have noticed significant improvement in Vista's search capabilities compared to earlier versions of Microsoft operating systems that I have used and I would love to see that harnessed in PowerShell so that I could use it from the command line. The table appears a ways down, so scroll down to it.

UPDATE (24 March 2008): Note that I have updated this table with information on a grep equivalent and on the availability of less as an extension. Thanks to Kirk Munro for pointing both of these out (see Comments) and to Jeffrey Snover for his write-up of Select-String at http://blogs.msdn.com/powershell/archive/2008/03/23/select-string-and-grep.aspx.
Thanks also to Marco Shaw for pointing out that start-transcript (which can be closed with stop-transcript) provides functionality like Unix's script command. Thanks to Jonathan for mentioning tasklist as an alternative to ps and mentioning F7 for a graphical presentation of history commands.
























Unix/LinuxPowerShellWindows Vista DOS
lsls
dir
dir
cpcp
copy
copy
mvmv
move
move
rmrm
del
del
netstatnetstatnetstat
manman
help
help
psps
tasklist
tasklist
fingerfingerfinger
script
(stop with CTRL-D)
start-transcript
(stop with stop-transcript)
 
clearclear
cls
cls
catcat
type
type
history / hhistory / h
F7
F7
unzipunzipunzip
zipzipzip
teetee 
grepSelect-String 
moremoremore
lessless (extension) 
editeditedit
killkill
taskkill
taskkill


Type ‘man’ without any options in PowerShell command-line
to see long list of supported commands and scripting keywords.



The Windows PowerShell Quick Reference and Getting Started with Windows PowerShell are also useful resources.

Thursday, March 20, 2008

NetBeans 6.1: A JavaScript IDE

I have started using NetBeans 6.1 (beta) and have found its JavaScript support to be welcome and helpful. JavaScript and DOM differences among the major browsers have long been a source of deep consternation for web developers and NetBeans does much to deal with browser idiosyncrasies. In this blog entry, I will demonstrate some of these NetBeans JavaScript functions.

One frustration of working with JavaScript and DOM across different browser implementations is the availability of objects and methods in one browser but not another. NetBeans auto-completion feature for JavaScript/DOM really helps here. The next screen snapshot (click on all screen snapshots to see larger versions) displays the auto-completion popup for the document object and the getElementById method that returns a Document.



The line through the getElementById method may look familiar to Java developers as used to indicate a deprecated Java method. In this case, it indicates that one or more of my targeted web browsers does not support this method. The auto-completion popup clearly shows that Internet Explorer 5.5 and Internet Explorer 6 are my "targeted browsers" that do not support this particular method.

The "targeted browsers" idea is useful because there may be situations in which we have the luxury of knowing which browsers we must support or, better yet, which we don't need to support. If we don't need to support a particular browser, that is one more source of potential inconsistency we do not need to worry about.

It is easy in NetBeans 6.1 to specify the targeted browsers. This is done by selecting Tools -> JavaScript Browser Compatibility from the top menu bar of NetBeans. This is shown in the next screen snapshot.



With a click on "JavaScript Browser Compatibility" from the "Tools" drop-down, one is taken to the "Choose Supported Browsers" window. The next screen snapshot shows this window, which indicates that Microsoft Internet Explorer 5.5 and later versions are targeted browsers. If I select "7 and later" (as shown in the next screen snapshot), then Microsoft Internet Explorer 5.5 and 6 are no longer considered my targeted browsers.



With the targeted browsers now only including Microsoft Internet Explorer versions 7 or later, the same auto-completion for document.getElementById no longer shows the method struck out and also does not list any targeted browsers not supporting it. This is because I removed the browser versions that did not support this method from my targeted browsers. See this in the next screen snapshot.



In the process of demonstrating the ability of NetBeans to provide browser compatibility information, my examples also showed how easy it is to use JavaScript method completion in exactly the same way one would use Java method completion in NetBeans.

Another advantage we take for granted with Java IDEs is color-coded syntax. NetBeans 6.1 provides this for JavaScript as shown in the next Hello World example.



With Java IDEs, we have become accustomed to the IDE warning us about problems that may not break compilation, but are likely not what we really want either. NetBeans 6.1 brings this ability to JavaScript. In the next screen snapshot, we can see that NetBeans warns us about an assignment operator that is most likely supposed to be an equality comparison.



Another example of one of these warnings follows, this time demonstrating a warning that the given function will return a value in some cases, but not in all cases.



Of course, while warnings about things that compile but are probably not intended is nice, but it is also nice to know about syntax problems before trying to run the JavaScript application. A JavaScript IDE may never be able to do this as well as a Java IDE due to Java's static typing, but NetBeans 6.1 does provide feedback on definitive errors that cannot be due to dynamic typing. This is demonstrated in the next screen snapshot that shows a curly brace missing. It is nice to see this before trying to run the web application using this JavaScript.



My final example for this blog entry shows a double message with an error message about using a reserved keyword ("double") and a warning message about a declaration that doesn't do anything ("no side effects").



There are many reasons that I have always preferred Java over JavaScript and one of these has been the vastly superior tooling (especially IDEs) for Java. However, with NetBeans 6.1, that gap has been narrowed considerably. With NetBeans 6.1, development of Ajax/DHTML applications and other web applications should be considerably easier. I also look forward to taking advantage of this NetBeans 6.1 JavaScript support with my OpenLaszlo development.

More details on NetBeans 6.1's new JavaScript support features can be found in this NetBeans wiki.

By the way, as you've likely heard by now, there is a NetBeans IDE 6.1 Beta Blogging Contest that ends on April 19. This blog entry has been submitted as an entry into that contest.

Wednesday, March 19, 2008

A Standard is Only As Good As Its Implementations

There are many potential advantages in software development when adhering to standards. These advantages include the ability to shift between implementations of a standard, the ability to connect two disparate pieces of software together when both meet a standard, a greater pool of developers with knowledge and skill from working with different implementations of the standard, and greater access to literature and other resources on the standard. I called these potential advantages earlier because they are not always realized. In fact, most of these advantages can only be gained if there are multiple implementations of high quality and high degree of standard conformance.

For example, if there is only one good implementation of a standard, then there is no real ability to switch between implementations of that standard. You have no more freedom in such a case than if you used a non-standard approach. Likewise, if there is only one or two strong implementations of a specific standard, you are less likely to enjoy the benefits of a larger skill set and greater availability of related literature than a popular non-standard product might enjoy.

So why does all of this matter? Because too many developers (and I have made this mistake myself before) say things like, "I know its not the best, but it's the standard." I do like to work with standards when possible, but not at the cost of many other positive features and characteristics, especially if I cannot really enjoy the benefits of standardization because there is only one or a very small number of decent implementations of that standard.

In fact, de facto standards can be just as useful if they are widely popular. For example, Ant, Maven, Struts, and the Spring Framework are not themselves standards, but they enjoy many of the benefits discussed above (wide developer talent pool, wide literature set, etc.). Many of these products, especially Spring, are heavily standard-based even if they are not themselves standardized.

The DHTML debacle that is the effort to write Ajax/DHTML applications for highly incompatible major browsers (due to lack of HTML/CSS/DOM/ECMAScript standards implementation) is evidence that standards and standards compliance do matter and do make our lives as software developers easier. It would be nice if the major browsers were all more standards-compliant (and Microsoft Internet Explorer 8 may help with this), but until then I prefer using Flex or OpenLaszlo so that I don't have to worry about browser standardization. It is more important for me to enjoy the benefits of standard code provided by Adobe (Flash) or Laszlo Systems (Flash/generated DHTML) than to cling to a claim of using web development "standards" that really aren't so standard. The problem of the incompatible browsers really comes down not to problems with the underlying specifications, but rather is such a big problem because of the lack of compliance of the major implementation of those standards.

Unfortunately, standards can only be as good as their implementations and the most dominant implementations are not always the best or even good implementations of these standards.

EclipseLink Will be JPA 2.0 Reference Implementation

Oracle Corporation provided TopLink Essentials as the JPA 1.0 reference implementation. Two days ago (17 March 2008), it was announced that EclipseLink was selected as the JPA 2.0 reference implementation. The GlassFish announcement on this states that EclipseLink essentially includes most of Oracle's full-fledged TopLink product.

Because Oracle did provide TopLink Essentials as the Java Persistence API 1.0 reference implementation and because Oracle has been an ardent supporter of JPA, it is not too surprising that the Oracle-led EclipseLink project will be the JPA 2.0 reference implementation.

Monday, March 17, 2008

UnsupportedOperationException and OperationNotSupportedException

I have seen several cases when OperationNotSupportedException is used when UnsupportedOperationException is the better choice. In this blog entry, I outline some of the key differences between these two similar sounding exceptions.

While the names of the exceptions OperationNotSupportedException and UnsupportedOperationException sound very similar, the Javadoc descriptions for each class indicate that they definitely have different intended uses.

The javax.naming.OperationNotSupportedException is a checked exception in the naming package that extends javax.naming.NamingException (which extends java.lang.Exception) and has been available since J2SE 1.3. As part of the java.naming package, it is not surprising that this exception is specifically related to naming services. Specifically, as the description for this class states, this exception is intended for situations in which a particular naming Context implementation does not support the invoked method (operation).

For situations other than those described above for OperationNotSupportedException, the better choice for a standard exception to indicate an unsupported method or operation is the UnsupportedOperationException. The UnsupportedOperationException is an unchecked exception in the java.lang package that (as an unchecked exception) extends java.lang.RuntimeException and has been available since J2SE 1.2.

As part of the more general java.lang package, UnsupportedOperationException definitely seems more general in nature than javax.naming.OperationNotSupportedException. The description for this class states that this class is part of the Collections Framework.

The NetBeans IDE uses UnsupportedOperationException when it automatically implements methods for a newly created class implementing an interface. This is useful because it allows NetBeans to implement methods of defined in the interface so that the code will compile. At runtime, however, the unchecked exception UnsupportedOperationException will be thrown when these methods are implemented. The UnsupportedOperationException allows the implementation class to be generated and compile, but does not hide the runtime issue of nothing actually being implemented in case a client calls that method.

The NetBeans example described above demonstrates a potentially appropriate use for UnsupportedOperationException, but there are many situations in which its use is inappropriate. For the Collections Framework, there are valid reasons for its use, but in our own designs it can often be a "code smell" of design problems. As stated in Peter Williams's blog entry Why Java is Not My Favorite Language - Reason 16, it is sensible that any method that is important enough to be defined in an interface should generally be implemented in advertised implementations of that interface. This excerpt from Effective Java covers the primary use of UnsupportedOperationException (an implementation does not implement a method in its interface that other implementations do implement).

A useful forum thread on UnsupportedOperationException is available at http://forum.java.sun.com/thread.jspa?threadID=633028&messageID=3665440. Another useful resource related to UnsupportedOperationException is the Java Collections API Design FAQ (see #1 and #2).