JavaOne 2010 has so many presentations that I want to see that even my current alternatives list ("My Interests" in Schedule Builder) is full of presentations that sound compelling.  The following presentations are currently in "My Interests" because I have (as of today) selected another presentation at the same time to "Enroll" in.  I think this list speaks for itself.  Of course, it is likely that I will change my mind several times between now and JavaOne and it's almost certain that I'll attend some of these.  For now, though, these are the presentations I wish I could attend, but currently think I'll have to miss because there's something else also scheduled at the same time.

[CS] - [S318719] MySQL Performance Tuning Best Practices
[CS] - [S318720] You Know Databases, So How Hard Can MySQL Be?
[CS] - [S313185] Writing Stunning Cross-Platform Applications Using LWUIT
[CS] - [S314273] Groovy: To Infinity and Beyond
[CS] - [S314588] Java Context Dependency Injection and OSGi to Help with Modularity
[CS] - [S313657] Tips and Tricks for Building JavaFX Applications
[CS] - [S313504] Project Coin: Small Language Changes for JDK 7
[CS] - [S313431] Java Persistence API 2.0: An Overview
[CS] - [S314629] HTML5 and Java: Opening the Door to New Possibilities
[CS] - [S315885] Ten Easy Ways to Improve Java EE Performance
[CS] - [S314362] Time to Improve: JSR 310 Date and Time API
[CS] - [S314039] Google Web Toolkit (GWT) Cloud Applications: Fast, Fun, and Easier Than Ever
[CS] - [S312988] Unit Testing That's Not That Bad: Small Things That Make a Big Difference
[CS] - [S313520] Funky Java, Objective Scala Available 2:30-15:30 Parc 55, Cyril Magnin III
[CS] - [S313839] Using the File System API in JDK 7
[CS] - [S314492] Java Persistence API (JPA) 2.0 with EclipseLink
[BOF] - [S314416] The Collections Connection: Special "It Goes Up to the 11th" Edition
[BOF] - [S314190] The Better RESTful Web Services Framework: Jersey or Spring Framework
[CS] - [S313557] The Java EE 6 Programming Model Explained: How to Write Better Applications
[CS] - [S317739] Java Persistence API: Tips, Patterns, and Best Practices
[CS] - [S313248] Creating Lightweight Applications with Nothing but Vanilla Java EE 6
[CS] - [S314395] WebSockets Versus Comet: What Are the Differences, and Why Should I Care?
[CS] - [S312989] Comparing Groovy and Jruby
[CS] - [S313831] Breaking Up Is Hard to Do: Modularizing the JDK and Lessons Learned
[CS] - [S313189] Complete Tools Coverage for the Java EE 6 Platform
[CS] - [S314168] What's New in Enterprise JavaBean Technology
[PAN] - [S315029] Java API for Keyhole Markup Language
[CS] - [S314408] Java Puzzlers: Scraping the Bottom of the Barrel
[CS] - [S314696] The Secret Power of JavaFX Script
[CS] - [S314286] Dual-Pivot Quicksort and Timsort, or Sorting on Steroids
[CS] - [S314665] A Journey to the Center of the Java Universe
[CS] - [S314256] Securing RESTful Web Services in Java
[CS] - [S314491] Effective XML: Leveraging JAXB and SDO
[CS] - [S314424] Polyglot Programming in the Java Virtual Machine (JVM)
[BOF] - [S314475] 10 Years of The Java Specialists' Newsletter
[CS] - [S314822] Myths, Misconceptions, and Hidden Gems in Java Platform Security
[CS] - [S313960] JavaFX Graphics
[CS] - [S313501] The Merging Point of Android and Swing
[CS] - [S314405] Google Web Toolkit Versus Rich Ajax Platform: Which Java-Based Ajax Is for You?
[HOL] - [S313277] Beginning with the Java EE 6 Platform
[HOL] - [S313674] Building a JavaFX-Based Monitoring App, Using the GlassFish REST Monitoring API
[CS] - [S314403] Java Transaction API Caching: Consistent, Distributed, and Coherent
[CS] - [S314385] Ninety-Seven Things Every Programmer Should Know
[CS] - [S313005] Domain-Specific Language Versus Library API Shootout
[CS] - [S314359] Remote Compiling and Performance Analysis Using the NetBeans IDE
[CS] - [S313819] What's Happening with My Application?: Java Virtual Machine Monitoring Tool
[CS] - [S314154] Writing Domain-Specific Languages (DSLs), Using Groovy
[CS] - [S314334] Static Analysis in Search for Performance Antipatterns
[CS] - [S314226] SomeSQL: Combining NoSQL Technologies with Existing RDBMS Architectures

The first acronyms listed on each line in square braces have the following meanings: BOF (Birds of a Feather), CS (Conference Session), ESS (Executive Solution Session), GS (General Session), HOL (Hands-On Lab), KEY (Keynotes Session), and PAN (Panel).

The alternative sessions listed above are the result of my first run-through with the Schedule Builder and that list does not even include potential OracleDevelop presentations of interest related to subjects such as Oracle Fusion, JDeveloper, Java in the Oracle Database, Oracle ADF, etc.

There are so many interesting-sounding presentations to choose from at JavaOne 2010 that it is very difficult to decide on which to attend.

For any conference that one attends, one of the difficult decisions is which presentations to attend.  This is particularly problematic when there are some really interesting-sounding presentations held during the same hour.  I find that I often change my plans for which presentations to see based on earlier presentations in the same conference.  A presentation (often an opening keynote) may stir my interest in a topic I had entered the conference not knowing or not caring much about.  On the other hand, an early presentation could equally dissuade me from attending further presentations on the same topic because I may realize that the subject is not as relevant to me as I thought it would be.

I am already struggling with this for JavaOne 2010, particularly when it comes to JavaFX presentations.  On the one hand, there are some abstracts for JavaFX-related presentations that look interesting.  On the other, I am still a little bitter about my time wasted looking into JavaFX after 2007 JavaOne and 2008 JavaOne.  I realize that I can only blame myself for any wasted time on a third failed attempt at learning to love JavaFX.  JavaOne 2010 gives me the opportunity to learn more about JavaFX in a potentially optimized way, reducing the risk of time wasted.  That being said, I could end up pretty disappointed if I miss some really good presentations to attend JavaFX presentations and then realize either during the conference or (even worse) realize later that JavaFX does not have a future.

This isn't to say that I wouldn't attend a presentation on something I don't know a lot about, because I would.  I feel that one of the best things about attending a conference is the ability in an hour or two to quickly identify whether something is worth further effort.  JavaFX, though, is different because I've already been burned by what I believe was hyperbole.  It's one thing to spend an hour in a session learning about something and realizing it has no immediate benefit for me.  That's actually positive because I only needed to spend an hour to learn that.  For JavaFX, I already have incurred a large tab for the time spent learning about it with little satisfaction.  There has been a huge net opportunity cost associated with time spent with JavaFX so far.

Max Katz, in his blog post JavaFX... does it have a future? (Sys-Con Media version), provides significant additional information for me to consider as I try to resolve the dilemma of deciding how much time to spend on JavaFX at JavaOne.  It is obvious from the tone and content of the writing in this post that Katz is an advocate of JavaFX.  Perhaps even more significantly in terms of considering JavaFX presentations to attend at JavaOne 2010, Katz is presenting at JavaOne 2010 on Enterprise JavaFX Applications with CDI (JSR299).  With all of this in mind, I found some quotes in this blog post particularly interesting.  I look at some of them in detail here in the context of trying to determine what number of JavaFX presentations to attend and which ones to attend.

First off, I appreciate that Katz is a realistic.  Some evangelists for a particular technology can see no wrong (or at least not admit any wrong) with their favorite technology.  This is, of course, ridiculous because nothing is perfect, everything has its flaws, everything has problems it fits better than others, and the natural difference of human beings' opinions means that nothing will ever be "perfect" for everyone.  In my opinion, this early quote from Katz's blog post provides him some credibility:
Don’t get me wrong, JavaFX is very far from perfect. It has it’s problems and challenges (listed below) and its future is hanging on life support right now.I believe my previous blog posts on JavaFX prove that I am in agreement here.  This is precisely why it's difficult for me to justify time spent on JavaFX (including in JavaOne presentations): I just cannot be sure that it's going to be around (at least in a form acceptable to me) for more than the near-term future.

Katz lists several benefits (the good) of JavaFX (such as "power" and "ease of use") first and states:
I have been working with JSF (JavaServer Faces) since its inception and I can tell you that using JavaFX Script to build the UI is probably simpler than using JSF.I have no doubt that this is true, but unfortunately being simpler than JavaServer Faces is the purview of just about every Java-based framework out there and non-Java Flex/ActionScript is, in my opinion, significantly less complicated than JSF.

Katz fairly addresses one of JavaFX's best known problems (the bad): deployment issues. He covers this pretty thoroughly and says exactly what needs to be done to remedy this: "Make it as simple and transparent as running a Flash application."  Well said.

I agree with Katz when he states that developers today need to learn new things all the time, so learning JavaFX Script as a new language should not be a big deal.  As long as everyone understands it is a new language, I think this is a fair statement.  My problem has been when anyone has pushed JavaFX as "Java."  You cannot have it both ways.  Is it Java or is it something else?  It may be Java in the same sense that JRuby and Groovy are Java, but Groovy is significantly more Java-like in syntax than is JavaFX Script.  Because it's not Java in terms of syntax and because there's no JSR (that I'm aware of) for it, its last hold on "being Java" seems to be the ability to run in the JVM, but every language and its brother seems to be doing that these days.

Katz makes several good points that I am skipping here (but I recommend reading his entire blog post if you have any interest in JavaFX whatsoever).  His conclusion, I believe, is objective and spot-on:
There is still time to make JavaFX successful, but the time is running out. First, fix the deployment issue as soon as possible.  ...  Second, Oracle needs to make it very clear what its plans are for JavaFX (maybe at JavaOne 2010?).  ...  I think Oracle has 6-12 months at the most to try and revive JavaFX. If nothing happens by then (which would be about 4 years since the technology was announced), we just might as well close the door on JavaFX. There's nothing I can add to that.  Probably the only debatable piece is the timeframe he provides of 6  to 12 months.  It might be longer (say 18 months), but it could be that Katz is right on.  With the seemingly increasing negative news regarding JavaFX and the strengthening of its competitors' positions, I do think there is a limited window for Oracle to turn things around for JavaFX in terms of it ever being mainstream popular.  There's always a possibility that it's already too late.

Katz's blog post increased my interest in attending his JavaOne 2010 presentation.  The two main reasons that I might not attend it are that there are several really good presentations of high level of interest to me and his topic is not really focused as much on the introduction to and examination of the future of JavaFX as I probably need and want.  Katz's presentation is scheduled for Monday, September 20, at 1 pm, at Golden Gate 2 in the Hilton San Francisco.  I currently have "Advanced Java API for RESTful Web Services (JAX-RS)" scheduled for that slot.  It's still a difficult dilemma because I am now really interested in Katz's presentation, but I think it's safer to bet my time and attention of JAX-RS and REST than it is on to bet them on JavaFX.  I am fairly confident what I learn from a JAX-RS/REST presentation will be of benefit for some time to come.

I hope that JavaOne 2010 provide some direction that allows us to be comfortable knowing how much time and effort to invest in it.  If I have a better idea of what JavaFX is going to become, then I can better make the decision about how much time to invest in JavaFX and what projects to build around it.

I previously posted that I was looking forward to JavaOne 2010 and this is even more true today.  Like Mitch Pronschinske, the trouble now is determining which presentations to attend.  This "problem" is complicated by the coexistence of Oracle OpenWorld and Oracle Develop with JavaOne 2010.  There are roughly 2400 different options for sessions, conferences, keynotes, Birds of a Feather (BOF) sessions, and so forth between the three simultaneous conferences.  Although I'm likely to attend JavaOne presentations the majority of the time, there are several Oracle Develop presentations that have caught my attention and I may even attend a few Oracle OpenWorld presentations.  It was a very pleasant surprise when I went to view the Content Catalog this afternoon and saw that it had been replaced by the Schedule Builder!  I received a few hours later stating its availability.

There originally was a single online Content Catalog tool for all three conferences.  At first this catalog only had the sessions without dates and times and then dates and times were added.  When I selected the "JavaOne" stream on the online Content Catalog, it reported the availability of 249 conference sessions, 111 BOFs, 19 hands-on labs, 8 panels, and two JavaOne-specific keynotes.

The first keynote specific to JavaOne is Thomas Kurian's (Oracle) and Doug Fisher's (Intel) "JavaOne Keynote" on Monday, September 20, from 5:45 pm to 7:15 pm.  The other JavaOne-specific keynote is called "The Java Frontier" and will be held Thursday, September 23, from 9 am to 10:30 am.  Other interesting streams that were displayed on the Content Catalog included MySQL Sunday (which seems to imply Oracle has more interest in MySQL's future than some had feared), Oracle Develop, and the several OpenWorld streams.

Even with the dates and times available, it was still difficult to get my head around which sessions were conflicting.  Fortunately, ScheduleBuilder is now available for "registered attendees of Oracle OpenWorld, JavaOne, and Oracle Develop 2010 to pre-enroll in conference events."  Once you log in to Schedule Builder with the username and password used during JavaOne registration, you can click on the link "Start Building my Agenda."  In the "Stream/Track" drop-down, you can select the "JavaOne" stream or a particular track in JavaOne.  When I set the "Search Criteria" to "JavaOne" (Stream/Track) for "All" (Events) and view "Session" (View), there are 395 matching results.  While Content Catalog had only allowed a person to see 50 results at a time, Schedule Builder allows one to see up to 200 results at a time.

I have started enrolling in presentations that look most interesting to me.  I'm already finding many of my most anticipated presentations at the same time.  The Schedule Builder tool identifies when a newly chosen ("Enroll") presentation is in conflict with one that is already scheduled and provides flexible choices as to which to keep (previously enrolled or newly enrolled) and what to do with the one not scheduled (either remove altogether or add it to one's interests).  I am particularly interested in the REST-related presentations and the JVM languages presentations and have already found many of them in conflict with one another.

I may post my tentative agenda once it is assembled along with the presentations saved in my interests section.  However, I never actually attend exactly the same presentations as originally planned so it will almost certainly change some.

One of the commands that I miss most from Linux when working in Windows/DOS environments is the split command.  This extremely handy command allows one to split a large file into multiple smaller files determined by the specification of either by number of lines or number of bytes (or kilobytes or megabytes) desired for the smaller files.  There are many uses for such functionality including fitting files onto certain media, making files "readable" by applications with file length restrictions, and so on.  Unfortunately, I'm not aware of a split equivalent for Windows or DOS.  PowerShell can be scripted to do something like this, but that implementation is specific to PowerShell.  There are also third-party products available that perform similar functionality.  However, these existing solutions leave just enough to be desired that I have the motivation to implement a split equivalent in Groovy and that is the subject of this post.  Because Groovy runs on the JVM, this implementation could be theoretically run on any operating system with a modern Java Virtual Machine implementation.

To test and demonstrate the Groovy-based split script, some type of source file is required.  I'll use Groovy to easily generate this source file.  The following simple Groovy script, buildFileToSplit.groovy, creates a simple text file that can be split.

#!/usr/bin/env groovy
//
// buildFileToSplit.groovy
//
// Accepts single argument for number of lines to be written to generated file.
// If no number of lines is specified, uses default of 100,000 lines.
//
if (!args)
{
   println "\n\nUsage: buildFileToSplit.groovy fileName lineCount\n"
   println "where fileName is name of file to be generated and lineCount is the"
   println "number of lines to be placed in the generated file."
   System.exit(-1)
}
fileName = args[0]
numberOfLines = args.length > 1 ? args[1] as Integer : 100000
file = new File(fileName)
// erases output file if it already existed
file.delete()
1.upto(numberOfLines, {file << "This is line #${it}.\n"})

This simple script uses Groovy's implicitly available "args" handle to access command-line arguments for the buildFileToSplit.groovy script.  It then creates a single file of size based on the provided number of lines argument.  Each line is largely unoriginal and states "This is line #" followed by the line number.  It's not a fancy source file, but it works for the splitting example.  The next screen snapshot shows it run and its output.


The generated source.txt file looks like this (only beginning and ending of it is shown here):

This is line #1.
This is line #2.
This is line #3.
This is line #4.
This is line #5.
This is line #6.
This is line #7.
This is line #8.
This is line #9.
This is line #10.
     . . .
This is line #239.
This is line #240.
This is line #241.
This is line #242.
This is line #243.
This is line #244.
This is line #245.
This is line #246.
This is line #247.
This is line #248.
This is line #249.
This is line #250.

There is now a source file available to be split. This script is significantly longer because I have made it check for more error conditions, because it needs to handle more command-line parameters, and simply because it does more than the script that generated the source file. The script, simply called split.groovy, is shown next:

#!/usr/bin/env groovy
//
// split.groovy
//
// Split single file into multiple files similarly to how Unix/Linux split
// command works.  This version of the script is intended for text files only.
//
// This script does differ from the Linux/Unix variant in certain ways.  For
// example, this script's output messages differ in several cases and this
// script requires that the name of the file being split is provided as a
// command-line argument rather than providing the option to provide it as
// standard input.  This script also provides a "-v" ("--version") option not
// advertised for the Linux/Unix version.
//
// CAUTION: This script is intended only as an illustration of using Groovy to
// emulate the Unix/Linux script command.  It is not intended for production
// use as-is.  This script is designed to make back-up copies of files generated
// from the splitting of a single source file, but only one back-up version is
// created and is overridden by any further requests.
//
// http://marxsoftware.blogspot.com/
//

import java.text.NumberFormat

NEW_LINE = System.getProperty("line.separator")

//
// Use Groovy's CliBuilder for command-line argument processing
//

def cli = new CliBuilder(usage: 'split [OPTION] [INPUT [PREFIX]]')
cli.with
{
   h(longOpt: 'help', 'Usage Information')
   a(longOpt: 'suffix-length', type: Number, 'Use suffixes of length N (default is 2)', args: 1)
   b(longOpt: 'bytes', type: Number, 'Size of each output file in bytes', args: 1)
   l(longOpt: 'lines', type: Number, 'Number of lines per output file', args: 1)
   t(longOpt: 'verbose', 'Print diagnostic to standard error just before each output file is opened', args: 0)
   v(longOpt: 'version', 'Output version and exit', args: 0)
}
def opt = cli.parse(args)
if (!opt || opt.h) {cli.usage(); return}
if (opt.v) {println "Version 0.1 (July 2010)"; return}
if (!opt.b && !opt.l)
{
   println "Specify length of split files with either number of bytes or number of lines"
   cli.usage()
   return
}
if (opt.a && !opt.a.isNumber()) {println "Suffix length must be a number"; cli.usage(); return}
if (opt.b && !opt.b.isNumber()) {println "Files size in bytes must be a number"; cli.usage(); return}
if (opt.l && !opt.l.isNumber()) {println "Lines number must be a number"; cli.usage(); return}

//
// Determine whether split files will be sized by number of lines or number of bytes
//

private enum LINES_OR_BYTES_ENUM { BYTES, LINES }
bytesOrLines = LINES_OR_BYTES_ENUM.LINES
def suffixLength = opt.a ? opt.a.toBigInteger() : 2
if (suffixLength < 0)
{
   suffixLength = 2
}
def numberLines = opt.l ? opt.l.toBigInteger() : 0
def numberBytes = opt.b ? opt.b.toBigInteger() : 0
if (!numberLines && !numberBytes)
{
   println "File size must be specified in either non-zero bytes or non-zero lines."
   return
}
else if (numberLines && numberBytes)
{
   println "Ambiguous: must specify only number of lines or only number of bytes"
   return
}
else if (numberBytes)
{
   bytesOrLines = LINES_OR_BYTES_ENUM.BYTES
}
else
{
   bytesOrLines = LINES_OR_BYTES_ENUM.LINES
}

def verboseMode = opt.t
if (verboseMode)
{
   print "Creating output files of size "
   print "${numberLines ?: numberBytes} ${numberLines ? 'lines' : 'bytes'} each "
   println "and outfile file suffix size of ${suffixLength}."
}
fileSuffixFormat = NumberFormat.getInstance()
fileSuffixFormat.setMinimumIntegerDigits(suffixLength)
fileSuffixFormat.setGroupingUsed(false)
filename = ""
candidateFileName = opt.arguments()[0]
if (candidateFileName == null)
{
   println "No source file was specified for splitting."
   System.exit(-2)
}
else if (candidateFileName.startsWith("-"))
{
   println "Ignoring option ${candidateFileName} and exiting."
   System.exit(-3)
}
else
{
   println "Processing ${candidateFileName} as source file name."
   filename = candidateFileName
}
def prefix = opt.arguments().size() > 1 ? opt.arguments()[1] : "x"
try
{
   file = new File(filename)
   if (!file.exists())
   {
      println "Source file ${filename} is not a valid source file."
      System.exit(-4)
   }

   int fileCounter = 1
   firstFileName = "${prefix}${fileSuffixFormat.format(0)}"
   if (verboseMode)
   {
      System.err.println "Creating file ${firstFileName}..."
   }
   outFile = createFile(firstFileName)
   if (bytesOrLines == LINES_OR_BYTES_ENUM.BYTES)
   {
      int byteCounter = 0
      file.eachByte
      {
         if (byteCounter < numberBytes)
         {
            outFile << new String(it)
         }
         else
         {
            nextOutputFileName = "${prefix}${fileSuffixFormat.format(fileCounter)}"
            if (verboseMode)
            {
               System.err.println "Creating file ${nextOutputFileName}..."
            }
            outFile = createFile(nextOutputFileName)
            outFile << new String(it)
            fileCounter++
            byteCounter = 0            
         }
         byteCounter++
      }
   }
   else
   {
      int lineCounter = 0
      file.eachLine
      {
         if (lineCounter < numberLines)
         {
            outFile << it << NEW_LINE
         }
         else
         {
            nextOutputFileName = "${prefix}${fileSuffixFormat.format(fileCounter)}"
            if (verboseMode)
            {
               System.err.println "Creating file ${nextOutputFileName}..."
            }
            outFile = createFile(nextOutputFileName)
            outFile << it << NEW_LINE
            fileCounter++
            lineCounter = 0
         }
         lineCounter++
      }
   }
}
catch (FileNotFoundException fnfEx)
{
   println System.properties
   println "${fileName} is not a valid source file: ${fnfEx.toString()}"
   System.exit(-3)
}
catch (NullPointerException npe)
{
   println "NullPointerException encountered: ${npe.toString()}"
   System.exit(-4)
}

/**
 * Create a file with the provided file name.
 *
 * @param fileName Name of file to be created.
 * @return File created with the provided name; null if provided name is null or
 *    empty.
 */
def File createFile(String fileName)
{
   if (!fileName)
   {
      println "Cannot create a file from a null or empty filename."
      return null
   }
   outFile = new File(fileName)
   if (outFile.exists())
   {
      outFile.renameTo(new File(fileName + ".bak"))
      outFile = new File(fileName)
   }
   return outFile
}

This script could be optimized and better modularized, but it fulfills its purpose of demonstrating how Groovy provides a nice approach for implementing platform-independent utility scripts.

The next screen snapshot demonstrates the script's use of Groovy's built-in CLI support.


The next two screen snapshots demonstrate splitting the source file into smaller files by line numbers and by bytes respectively (and using different suffix and file name options).  The first image demonstrates that three output files are generated when split into 100 lines (250 lines in source file).  The -a option specifies that four integer places will be in the filename.  Unlike the Linux split, this script does not guarantee that the user-provided number of integers is sufficient to cover the number of necessary output files.


The second image (next image) shows the script splitting the source file based on number of bytes and using a different filename and only two integers for the numbering.


As mentioned above, this script is a "rough cut."  It could be improved in terms of the code itself as well as in terms of functionality (extended to better support binary formats and to make sure file name suffixes are sufficiently long for number of output files).  However, the script here does demonstrate one of my favorite uses of Groovy: to write platform-independent scripts using familiar Java and Groovy libraries (SDK and GDK).

In the post O JavaFX, What Art Thou? I publicly posted questions about JavaFX that largely pertain to its future.  As I stated in that post, I had felt somewhat deceived by Sun's overhasty JavaFX marketing at 2007 JavaOne and 2008 JavaOne and wasted more time than I like to waste looking into what JavaFX was (or in most cases, was supposed to become).  I have hesitated to really invest time and effort into it a third time until I feel better about its future.  Since posting O JavaFX,What Art Thou? there's been little to make me feel more optimistic about JavaFX's future.  This week, there was a major piece of bad press for JavaFX.

In his blog post JavaFX is a Train Wreck, Kirill Grouchnikov expresses frustration at JavaFX not delivering on early promises to make it easy for developers and designers to work together to build compelling user interfaces with JavaFX.  His feeling is that there are next to no good examples of real JavaFX applications that take advantage of designer skills and asserts that JavaFX seems to be of some interest to developers but is not very interesting to designers.  Kirill is not the first to express dissatisfaction with JavaFX.  However, his critique is especially significant because of his obvious experience developing user interfaces and because he seems to have really wanted JavaFX to be something special.  This blog post apparently hit a nerve as it quickly soared into the DZone Top Links after I initially saw it featured on Java.net's "Java Today" section (for July 15) and other bloggers have referenced it.


JavaWorld blogger Josh Fruhlinger observed that Kirill's post and the user feedback to his post provide a summary of the trouble with JavaFX, in one tidy blog comment thread.  Fruhlinger points out that the feedback comments provide a nice overview of various problems Java developers (and any designers who have tried it) have run into when using JavaFX (such as bitterness about Sun reallocating people from working on Swing to working on JavaFX [mentioned in a different Kirill Grouchnikov post]).

In How Can Oracle Make JavaFX More Popular, James Sugrue also references the JavaFX is a Train Wreck post and asks what Oracle can do to improve JavaFX's popularity.  This post is a question intended for developers to answer and the feedback is insightful.  Many want to simply "kill" JavaFX and have Oracle reallocate resources to Swing or other technologies.  Others want to see it open sourced.  Based on the feedback to both the original Train Wreck post and to this Sugrue post, it seems that Java developers in general do not have a positive perception of JavaFX or its future.  That's daunting news because it means a reputation is being established that may be difficult to tear down.

Shai Almog has posted a poll based off the just-mentioned DZone poll specifically targeted at mobile developers.  Similarly called How Can Oracle Make JavaFX More Popular, Shai asks how JavaFX can be more popular among mobile developers and I think Ryan de Laplante's answer in the feedback probably sums up the answer best: "JavaFX Mobile needs to be available. Where is it? Not on Android. Not on iPhone. Not on BlackBerry. Not on Palm Pre."  I admit that I'd probably be more likely to get into JavaFX if it worked on my Droid.  This is what I was poking at when I asked Does JavaFX Have a Niche?

Being called a "Train Wreck" wasn't JavaFX's only exposure this week.  The two top DZone links as I write this are related to a petition to Oracle requesting that JavaFX be open sourced: Stephen Chin's Petition to Open Source JavaFX (both comments so far favor Pivot over JavaFX) and the original Petition to Open Source JavaFX.  Open source success depends heavily on community involvement and/or a strong sponsoring organization, so I'm not certain that open sourcing JavaFX would improve its future.  As I stated in the post O JavaFX, What Art Thou?, JavaFX cannot make the argument that it's standard or any more "Java" than other open source frameworks such as Pivot.  Being open source does not magically save projects.  Oracle could open source JavaFX as it has done with TopLink Essentials/EclipseLink and ADF Faces (Apache MyFaces Trinidad) and several other projects, but my current speculation (and that's all it is) is that JavaFX is more likely to be taken the same direction as Oracle's Application Developer Framework (ADF).

It wasn't all negative this week for JavaFX.  Early in the week, the Sun Developer Network (AKA java.sun.com) featured the article Stylin' with JavaFX.  There is a small number of ardent JavaFX proponents in the blogosphere and the author of this article, Jim Weaver, may be at the top of that list.  The article's introduction talks about JavaFX's CSS support that is meant to "encourage this collaboration" between "designers and developers."  The irony, of course, is that it is the lack of greater support for collaboration between designers and developers that led to the "Train Wreck" post.

Despite the enthusiastic and valiant efforts of a seemingly small number of developers who like to use JavaFX, the momentum seems to be moving away from JavaFX.  Perhaps it never had momentum because it took so long to deliver anything of real value from its initial announcement at 2007 JavaOne.  For now, I cannot justify spending any more time or effort learning JavaFX.  Perhaps things will turn around for JavaFX and it will be worth a third look, but I wouldn't bet much on that at this time.  JavaOne 2010 may be the next serious look I give to JavaFX, if it's fate is not sealed by then.

The attractive full-color Spring 2010 edition of the RMOUG SQL>Update newsletter arrived this week and I read several things in it that I felt were worth mentioning in this blog post.  The three technical articles featured in this edition are the second part of Mark Molnar’s “Oracle & Excel – Why Fight It?”, Mark Rittman’s “Integrating Oracle GoldenGate and Oracle Data Integrator for Change Data Capture”, and Dan Hotka’s “Index Quality.”  Besides these three technical articles this edition also features RMOUG
member Bern Bray and RMOUG Board Member Carolyn Fryc.  In the remainder of this post, I highlight some of the things I found most generally interesting in these articles and member highlights.

As is usual with these RMOUG newsletters, the cover of this edition features a photograph of a beautiful Rocky Mountain area scene.  In this case it is a Bern Bray photograph of Rock Cut Bloom in Rocky Mountain National Park.  My family and I try to get to Estes Park, Grand Lake, and Rocky Mountain National Park often and the scene in this photograph is very familiar.  Unfortunately, this beautiful cover does have a typo: it indicates that the GoldenGate/Data Integrator article is by Mark Ritter instead of Mark Rittman.  With all the Marks in this issue, this typo is more understandable.

From a technical standpoint, the articles focusing on RMOUG members are intentionally and not surprisingly typically far less interesting than the technical articles.  Their focus, after all, is more on the “soft skills” than on technical insight.  That being stated, I particularly enjoyed reading a couple of Bern Bray’s comments in his self-written “Member Focus.”  In that, Bray writes, “Like many younger engineers, my early days found me doing technical stuff on my own at night.  It paid off, as I was able to advance my career and choose what I liked to work on.  Several years ago, I started to feel that my life was out of balance.”

Later, in concluding, Bray states his “little nugget of wisdom”: “Work hard during working hours, but at quitting time, put the keyboard down and walk away… You will be a fresher and better worker when you come back in the morning.  Besides, everyone knows that you get your best ideas in the shower.”  I liked these statements because they reflect that there are career advantages to technical work done on one’s own time, but that it is also useful to take a break.  This is my excuse for the less frequent and more intermittent blog posts this summer!

In the second (of two) part of his “Oracle & Excel – Why Fight It?” series, Mark Molnar demonstrates with extensive code samples and screen snapshots how to create flat files of usefully formatted data via Excel and an Oracle database.  In his words, his examples show “how to take data out of the database, via Excel, and produce flat files in the format desired.”  At first reading this, I wondered why one would do such a thing when it is easy to read from a database in a language like Java or Groovy using JDBC and write out flat files.  However, I found the article informative because of its extensive coverage of using Visual Basic with Excel and use of 7-Zip from the command line.  Even if I’d probably solve the problem of the example in this article with a Java-based approach, I enjoyed learning some details of using Visual Basic with Excel and Molnar’s coverage of some low-level details involved in that.  He specifically references the URL
http://en.wikibooks.org/wiki/Visual_Basic/External_Processes as a source of useful details regarding use of Visual Basic with external processes.

Dan Hotka provides a code listing in his article “Index Quality” that contains the source code for a script he calls Index_Info.sql.  According to the “description” included in the script’s comments, this script is an “SQL*Plus script to display Index Statistics in relation to the clustering factor.”  Hotka writes that this script is available on his website and discusses background details of the script and why it’s useful in this article.

I’m significantly more developer-oriented than DBA-oriented, so Rittman’s article on integrating GoldenGate and Data Integrator was largely outside of my core areas of interest.  However, it also meant that I learned plenty from reading the article, even though it was more difficult because I lacked the requisite knowledge in the two products he was demonstrating integrating.  At the end of this article, Rittman states, “For a more
detailed, step-by-step version of this article that also describes the process to set up Oracle GoldenGate on the Microsoft Windows platform, an article is available on my website at: http://www.rittmanmead.com/2010/03/22/configuring-odi-10-1-3-6-to-use-oracle-golden-gate-for-changed-data-capture/”

Oracle OpenWorld (OOW) is mentioned more than once in this edition of the newsletter.  In “RMOUG Board Focus,” Carolyn Fryc writes about her first Oracle OpenWorld (2005) and talks about the focus of that OOW being Fusion (likely a major theme every year since then as well).  Dan Hotka’s training advertisement also mentions that he will be at Oracle OpenWorld September 19-23.  I’ve never attended Oracle OpenWorld, but will likely attend at least portions of it this year when I attend JavaOne 2010 and Oracle Develop 2010 which are being held simultaneously in the same city.

In this blog post, I’ve attempted to outline some facets of the Spring 2010 edition of the RMOUG SQL>Update newsletter that I thought had some general interest.  According to RMOUG President Peggy King’s “From the President” column, RMOUG Training Days 2011 is scheduled for 15-17 February 2011 at the Colorado Convention Center.

After having spent several years developing primarily in C++, I missed having an enum in Java until it was finally introduced with J2SE 5.  The long wait was worth it because the Java enum is much more useful and powerful than its C++ counterpart.  Although the Java enum can be used with any Java collection, its full power is best leveraged when used with the EnumMap and EnumSet.

Why would I use an EnumMap rather than a HashMap?  The primary reasons boil down to some inherent advantages of Java's enum as stated in the Javadoc documentation for EnumMap: "Enum maps are represented internally as arrays. This representation is extremely compact and efficient." Later in the same Javadoc documentation, there is an "Implementation Note" that states: "All basic operations execute in constant time. They are likely (though not guaranteed) to be faster than their HashMap counterparts."

The Javadoc documentation states similar advantages for the EnumSet over the HashSet:
Enum sets are represented internally as bit vectors. This representation is extremely compact and efficient. The space and time performance of this class should be good enough to allow its use as a high-quality, typesafe alternative to traditional int-based 'bit flags.'  ... Implementation note: All basic operations execute in constant time. They are likely (though not guaranteed) to be much faster than their HashSet counterparts. Even bulk operations execute in constant time if their argument is also an enum set.Compact and efficient, these enum-powered collections are also easy to use as demonstrated in the following code listings.  First, an example enum is provided in ColorEnum.  Then, the class EnumCollections.java provides some simple demonstrations of EnumMap and EnumSet in action.  In particular, the code listing demonstrates different ways to instantiate instances of these (using constructors for EnumMap and static initialization factories for EnumSet).

ColorEnum.java

package dustin.examples;

import java.awt.Color;

/**
 * Enum representing colors.
 *
 * @author Dustin
 */
public enum ColorEnum
{
   BLACK("#000000", Color.BLACK, new RedGreenBlue(0, 0, 0)),
   BLUE("#0000FF", Color.BLUE, new RedGreenBlue(0, 0, 255)),
   CYAN("#00FFFF", Color.CYAN, new RedGreenBlue(0, 255, 255)),
   GRAY("#808080", Color.GRAY, new RedGreenBlue(128, 128, 128)),
   GREEN("#00FF00", Color.GREEN, new RedGreenBlue(0, 159, 107)),
   MAGENTA("#FF00FF", Color.MAGENTA, new RedGreenBlue(255, 0, 255)),
   ORANGE("#FF8040", Color.ORANGE, new RedGreenBlue(255, 127, 0)),
   PINK("#FFC0CB", Color.PINK, new RedGreenBlue(255, 192, 203)),
   RED("#FF0000", Color.RED, new RedGreenBlue(255, 0, 0)),
   WHITE("#FFFFFF", Color.WHITE, new RedGreenBlue(255, 255, 255)),
   YELLOW("#FFFF00", Color.YELLOW, new RedGreenBlue(255, 205, 0));

   /**
    * Parameterized constructor.
    *
    * @param newHtmlHex HTML hex code for this color.
    * @param newJavaColor Color from java.awt package.
    */
   ColorEnum(
      final String newHtmlHex,
      final Color newJavaColor,
      final RedGreenBlue newRgb)
   {
      this.htmlHexCode = newHtmlHex;
      this.javaColorCode = newJavaColor;
      this.rgb = newRgb;
   }

   /** HTML hexadecimal code for this color. */
   private final String htmlHexCode;

   /** java.awt.Color code. */
   private final Color javaColorCode;

   /** RGB. */
   private final RedGreenBlue rgb;

   /**
    * Provide the java.awt.Color code for this color.
    *
    * @return The java.awt.Color code.
    */
   public Color getJavaColorCode()
   {
      return this.javaColorCode;
   }

   /**
    * Provide the HTML hexadecimal code for this color.
    *
    * @return HTML hexadecimal code for this color.
    */
   public String getHtmlHexadecimalCode()
   {
      return this.htmlHexCode;
   }

   /**
    * Provide RGB representation of this color.
    *
    * @return RGB representation of this color.
    */
   public String getRgbRepresentation()
   {
      return this.rgb.getRgbString();
   }

   /**
    * Represents RGB.
    */
   public static class RedGreenBlue
   {
      /** Red portion of RGB. */
      private final int redValue;

      /** Green portion of RGB. */
      private final int greenValue;

      /** Blue portion of RGB. */
      private final int blueValue;

      public RedGreenBlue(
         final int newRedValue, final int newGreenValue, final int newBlueValue)
      {
         this.redValue = newRedValue;
         this.greenValue = newGreenValue;
         this.blueValue = newBlueValue;
      }

      /**
       * Provide the red value of my RGB.
       *
       * @return Red portion of my RGB.
       */
      public int getRedValue()
      {
         return this.redValue;
      }

      /**
       * Provide the green value of my RGB.
       *
       * @return Green portion of my RGB.
       */
      public int getGreenValue()
      {
         return this.greenValue;
      }

      /**
       * Provide the blue value of my RGB.
       *
       * @return Blue portion of my RGB.
       */
      public int getBlueValue()
      {
         return this.blueValue;
      }

      /**
       * Provide my RGB settings in String format: (r,g,b).
       *
       * @return String version of my RGB values: (r, g, b).
       */
      public String getRgbString()
      {
         return "(" + this.redValue + ", " + this.greenValue + ", " + this.blueValue + ")";
      }
   }
}

EnumCollections.java

package dustin.examples;

import java.util.EnumMap;
//import java.util.HashMap;
import java.util.EnumSet;
import java.util.Map;
import java.util.Set;

import static java.lang.System.out;

/**
 * Simple demonstration of EnumMap and EnumSet.
 *
 * http://download.oracle.com/docs/cd/E17409_01/javase/6/docs/api/java/util/EnumMap.html
 * http://download.oracle.com/docs/cd/E17409_01/javase/6/docs/api/java/util/EnumSet.html
 *
 * @author Dustin
 */
public class EnumCollections
{
   /** Preferred form feed/carriage return/line feed. */
   private static final String NEW_LINE = System.getProperty("line.separator");

   /** Demonstrate the EnumMap in action. */
   public static void demonstrateEnumMap()
   {
//      final Map<ColorEnum, String> colorsAndCauses = new HashMap<ColorEnum, String>();
      final Map<ColorEnum, String> colorsAndAwarenessRibbons = new EnumMap<ColorEnum, String>(ColorEnum.class);
      colorsAndAwarenessRibbons.put(ColorEnum.BLUE, "Bipolar");
      colorsAndAwarenessRibbons.put(ColorEnum.GRAY, "Diabetes");
      colorsAndAwarenessRibbons.put(ColorEnum.PINK, "Breast Cancer");
      colorsAndAwarenessRibbons.put(ColorEnum.RED, "Acquired Immunodeficiency Syndrome");
      colorsAndAwarenessRibbons.put(ColorEnum.YELLOW, "Support the Troops");
      displayMap("Awareness Ribbons Colors", colorsAndAwarenessRibbons);

      // The EnumMap can also be constructed by passing another EnumMap to one
      // of its constructors or by passing a general Map to one of its
      // constructors.
   }

   /** Demonstrate the EnumSet in action. */
   public static void demonstrateEnumSet()
   {
      // instantiate empty EnumSet and fill it individually
      final Set<ColorEnum> denverBroncosColors = EnumSet.noneOf(ColorEnum.class);
      denverBroncosColors.add(ColorEnum.BLUE);
      denverBroncosColors.add(ColorEnum.ORANGE);
      displaySet("Denver Broncos Colors", denverBroncosColors);

      // instantiate EnumSet with single value
      final Set<ColorEnum> orangeFruitColor = EnumSet.of(ColorEnum.ORANGE);
      displaySet("What Color is an Orange?", orangeFruitColor);

      // instantiate EnumSet with two values
      final Set<ColorEnum> greeceFlagColors = EnumSet.of(ColorEnum.BLUE, ColorEnum.WHITE);
      displaySet("Colors of Greek Flag", greeceFlagColors);

      // instantiate EnumSet with three values
      final Set<ColorEnum> usFlagColors =
         EnumSet.of(ColorEnum.RED, ColorEnum.WHITE, ColorEnum.BLUE);
      displaySet("Colors of United States Flag", usFlagColors);

      // instantiate EnumSet with four values
      final Set<ColorEnum> googleIconColors =
         EnumSet.of(ColorEnum.BLUE, ColorEnum.RED, ColorEnum.YELLOW, ColorEnum.GREEN);
      displaySet("Google Icon Colors", googleIconColors);

      // instantite EnumSet with five values
      final Set<ColorEnum> olympicsRingsColors =
         EnumSet.of(ColorEnum.BLUE, ColorEnum.YELLOW, ColorEnum.BLACK, ColorEnum.GREEN, ColorEnum.RED);
      displaySet("Olympics Rings Colors", olympicsRingsColors);

      // place all enum choices in this Set
      final Set<ColorEnum> allColors = EnumSet.allOf(ColorEnum.class);
      displaySet("All Available Colors", allColors);

      // Instantiate Set of ColorEnums that are complement to EnumSet of GRAY
      // Note that the graySet passed to the complementOf method must be an
      // EnumSet specifically rather than the more general Set.
      final EnumSet<ColorEnum> graySet = EnumSet.of(ColorEnum.GRAY);
      final Set<ColorEnum> allButGrayColors = EnumSet.complementOf(graySet);
      displaySet("All Colors Except Gray", allButGrayColors);

      final EnumSet<ColorEnum> btogColors = EnumSet.range(ColorEnum.BLACK, ColorEnum.GREEN);
      displaySet("'B' Colors to 'G' Colors", btogColors);
   }

   /**
    * Display the provided Map by writing its contents to standard output with
    * a separating header that includes the provided header text.
    *
    * @param header Header text to demarcate the output.
    * @param mapToDisplay Map whose contents should be written to standard output.
    */
   private static void displayMap(
      final String header, final Map<ColorEnum, String> mapToDisplay)
   {
      out.println(buildHeaderSeparator(header));
      for (final Map.Entry<ColorEnum, String> entry : mapToDisplay.entrySet())
      {
         final ColorEnum color = entry.getKey();
         out.println(color + " is used to represent " + entry.getValue());
         out.println(
              "  (and it is represented in HTML as "
            + color.getHtmlHexadecimalCode() + " and in RGB as "
            + color.getRgbRepresentation() + ".");
      }
   }

   /**
    * Write the provided Set to standard output along with the provided header.
    *
    * @param header Header to be displayed before the set being printed.
    * @param setToDisplay Set to be displayed by writing to standard output.
    */
   private static void displaySet(final String header, final Set<ColorEnum> setToDisplay)
   {
      out.println(buildHeaderSeparator(header));
      out.println(setToDisplay);
   }

   /**
    * Provide a separating header based on the provided header String.
    *
    * @param header The string to be placed in the header.
    * @return Header separator with provided String and separation marks.
    */
   private static String buildHeaderSeparator(final String header)
   {
      return
           NEW_LINE
         + "=================================================================="
         + NEW_LINE
         + "= " + header
         + NEW_LINE
         + "==================================================================";
   }

   /**
    * Main executable function.
    *
    * @param arguments Command-line arguments; none expected.
    */
   public static void main(final String[] arguments)
   {
      demonstrateEnumMap();
      demonstrateEnumSet();
   }
}

As the code demonstrates (or describes in the comments), instances of EnumMap are acquired via one of the overloaded constructors (one of three shown in the example) while instances of EnumSet are acquired via one of the overload static initialization methods (most of which are demonstrated in the example).  In all cases, the specific enum being used is supplied at instantiation time.  As their names imply, EnumSet implements Set and EnumMap implements Map, so they can generally be used anywhere those interfaces apply and generally support the methods and contracts of those interfaces.

Many fellow Java developers have blogged on the virtues of EnumMap and EnumSet.  These include the blog posts Fun with EnumSet, Playing with EnumSet, and Java's EnumSet: Fun for the Whole Family.

It seems to be human nature to want to be "the center of the universe." It's no wonder astronomers thought for hundreds of years that the Earth is the center of the universe. From their perspective on seemingly solid, seemingly unmoving ground, everything else (planets, the sun, other stars) were the things doing the moving. We see other manifestations of this "center of the universe syndrome" in various facets of life such as daily life, business, and software testing. In this post, I look at how "center of the universe syndrome" can at least partially explain many of the bad decisions and dysfunctional behaviors software developers witness and/or commit.


There's No Team in 'I'
If we are to believe the resumes of software developers, everyone software developer is a team player. If I'm the center of the universe, then others should do what I want and do things the way I want. When they do this, they're team players. When they try to do it differently than my way, they are not good team players. As the center of the universe, I must be, by definition. a team player. After all, it's all about me.

I'll work only on what I want to work on. It doesn't matter if my skills and fellow team members' skills would be better used in a different configuration. It's only about me and what I want to do and what I think is worth doing.

The Customer's Always Right ... if (s)he agrees with Me
Customers are correct when they want things I know they need. When a client wants something that I know is unnecessary or not worth the effort required, it is the client's fault.

I am the Direction
If I'm the Center of the Universe, I'm also it's director. I don't need direction from leads, mentors, management, clients, etc. Everything should go the way I say it should go.

Resume-Driven Development
As the Center of the Universe, the most important part of my current project is development skills for the next job. It doesn't really matter if it's what's best for my client, my team, or my organization. I'll use whatever tools and techniques make my resume look better.

Ignoring Code Conventions
If I'm the Center of the Universe and I don't like or agree with a particular coding convention, the rest of the universe (other developers) need to come to my way of thinking.

There's Nothing Left for Me to Learn
As the Center of the Universe, if I think I know something, then that's how it is. Anyone who would tell you differently is simply wrong. Hopefully, they'll "get it" later. There's no reason for me to even consider that I'm incorrect or might need to change my mind. I'm the expert.

I Can Do No Wrong
If someone tells me I need to improve or finds fault with my work (including during code reviews or testing), then either that person is at fault or I have been mistaken for someone else, or I am taking the blame for someone else's misdeeds.

Everything's a Conspiracy: The Victim Mentality
As the Center of the Universe, it's unthinkable that I'd lose a job, not get a bid for consulting work, or otherwise not have everything my way. If I did get laid off or not win a consulting bid, it must be for some reason other than the fact that others considered were better fits or were cheaper or simply made a better impression. Only some type of conspiracy or discrimination could explain my not getting the bid or not being laid off.

Code Reviews are Necessary for the Others
As the Center of the Universe, I don't need code reviews, but I may be magnanimous enough to review others' code and set them straight. Actually, now that I think about it more, I probably won't even do that because I don't really care if they improve or learn new things. I'll just complain about how crappy their code is.

Instant Gratification
As the Center of the Universe, it's about me getting stuff slung out as quickly as possible so that I can move onto the next thing. I don't need to bother with things that slow me down and are mundane (testing various paths, testing at all, writing maintainable code, etc.). Give me credit for finishing the task quickly and let me move to the next fun things. Testing and maintenance can be left for others to do. The important thing is that I get to work on new, cool, and fun things.

My Task is Inherently the Most Valuable
It would make no sense to assign the most important tasks to anyone but the Center of the Universe. Therefore, my assignments and tasks are necessarily the most important. With this in mind, I should interrupt anyone and everyone to make sure my task gets accomplished as quickly as possible. Yes, I may distract others and delay their progress, but they're working on less important tasks anyway.



Conclusion

The software developer who acts as if he or she is the Center of the Universe is more likely to not see the big picture and to not understand the true significance of his or her role in the greater scheme of things. This developer is more likely to suspect conspiracy theories and invoke victim mentality when things don't go well than to try to learn and improve and do better the next time. The Center of the Universe is less likely to work well with others and to be open to new (and possibly better) ideas and concepts.

Unfortunately, it seems human nature to desperately want to believe and behave as if we are the Center of the Universe. We can't all be the Center of the Universe, so I propose that we simply agree that I'm the Center of the Universe and make it easier on everyone.

Many of us have wondered if Oracle would contribute to and support three Java IDEs. Before Oracle's acquisition of Sun, Oracle was already a contributer to the open source Eclipse (EclipseLink, for example) and already had its own free (but not open source) Java IDE in JDeveloper. With the acquisition of Sun, Oracle now has NetBeans in its fold. So far, Oracle seems to contribute and support all three. The following screen snapshot taken tonight demonstrates this (orange circles around the IDE names were obviously added to snapshot for emphasis).



As the screen snapshot above indicates, the Oracle Technology Network (OTN) main page features download-related links for all three of these Java IDEs. Just-released NetBeans 6.9 (15 June 2010) is featured in the right column of "New Downloads" and JDeveloper 11g is featured as a "free product" in the left "Top Downloads" column.

The Oracle Enterprise Pack for Eclipse (OEPE) is also featured on the main OTN page as a "Top Download." OEPE provides significant add-on functionality for Eclipse, including functionality covered in the articles Build a Java Application with Eclipse, Spring, and Oracle WebLogic Server, Web Services Support in Oracle Enterprise Pack for Eclipse, and Introduction to Oracle Enterprise Pack for Eclipse 11g JPA Workbench.

This year's JavaOne will be the first in which Oracle is in charge. Several presentations are NetBeans-oriented as documented in NetBeans at the JavaOne 2010 Conference, which lists eleven sessions that the "NetBeans team recommends."

Whereas JavaOne tends to be more general Java and less product specific, Oracle OpenWorld 2010 and Oracle Develop 2010 are being held in conjunction with JavaOne 2010 and offer numerous JDeveloper (especially Application Developer Framework) presentations. I'm not aware of any Eclipse-specific presentations at any of these conferences, but Oracle has shown significantly more interest in Eclipse in recent years than Sun did.

Oracle expressed interest in supporting the JDeveloper IDE, the NetBeans IDE, and the Eclipse IDE in their lengthy 27 January 2010 webcast. A concise summary of their stated plans for the three IDEs is available in the "NetBeans" section of the online post Oracle's Roadmap for Sun Technologies.

Although there are many other text/code editors out there and even other Java IDEs out there, Oracle seems to own or contribute heavily to three of the four "big ones" (IntelliJ IDEA being the lone major Java IDE without significant Oracle affiliation). The Java IDE I "grew up with" in the sense of first learning Java, (Borland at the time) JBuilder, is no longer the force it once was. JDeveloper has some JBuilder heritage, though it has obviously changed significantly since those days.

Based on Oracle's declarations regarding the roadmap for Sun products and based on the products advertised on the OTN page, it appears that the current plan is to continue providing support for JDeveloper, NetBeans, and Eclipse. I admit that I didn't think they'd continue supporting all three, but so far it seems that they intend to do just that.

In my last blog post, I looked at using a simple Java application to determine which characters would work as desired for splitting a String with String.split. Simple utilities like this one are often a perfect fit for Groovy and in the blog post I show a Groovy script version of the Java class featured in the previous post. I also demonstrate one Groovy gotcha.

Here is the Groovy script ported from the Java class detailed in the last blog post.

#!/usr/bin/env groovy

import java.util.regex.PatternSyntaxException

/**
 * This simple script accepts a String as a potential regular expression token
 * and demonstrates how this provided String work work as a token in a 
 * {@code String.split} invocation.
 */

NEW_LINE = System.getProperty("line.separator")

if (args.length < 1)
{
   println "${NEW_LINE}No argument was provided.  A candidate String token must be provided.${NEW_LINE}"
   System.exit(-1)
}

String candidateToken = args[0]
println "Provided token is: ${candidateToken}"

stringWithCandidateToken =
   "Java${candidateToken}has${candidateToken}regular${candidateToken}expression${candidateToken}support${candidateToken}."
println "String with candidate token is: ${stringWithCandidateToken}"

try
{
   splitStrings = stringWithCandidateToken.split(candidateToken)
   splitStrings.each()
   {
      println it
   }
}
catch (PatternSyntaxException badRegExpPatternSyntax)
{
   println "Unable to parse ${stringWithCandidateToken} on token ${candidateToken} using String.split method - ${badRegExpPatternSyntax.toString()}"
}

Although Groovy doesn't require exception handling even for checked exceptions, I intentionally caught the PatternSyntaxException (an unchecked/runtime exception) so that I could print out a little nicer error message than the normal stack trace.

The Groovy script writes out the same results as the simple Java application, so I won't show all the same screen snapshots shown in the previous blog post. However, there is one character that does behave differently with the Groovy script than it did with the Java application. When an asterisk (*) is provided as the candidate regular expression token for the Groovy script, the results are different than when it's provided to the Java application. In the Java application, the asterisk led to the PatternSyntaxException. In the Groovy script, something different happens:



Although the Groovy script version at first glance appears to have worked better than the simple Java application because it did not result in an exception, the whole point of this script and application was to determine an appropriate character to split on. This is a reminder that while Groovy largely IS Java, there are times when Groovy is different from Java.

In the case of the asterisk, Groovy tried to expand the asterisk first and it so happened that build.xml is the first file listed in the directory in which that script presides. As the screen output above indicates, the Groovy script thought that this file name was the token rather than *. This demonstrates that there are some issues with Groovy's handling of asterisk on the command-line as documented in Command line arguments containing * (asterisk) not passed correctly
and in Issues with the Windows startup batch files.

There are many things I like about Groovy and there are many ways in which it complements and enhances my Java development experience. This blog post has shown how Groovy can be very helpful in helping determine what works best with a Java API, but also demonstrates that there are some differences in Groovy and Java behavior that can mislead one if he or she thinks that Groovy always behaves exactly like Java.

The String.split methods can be very convenient for easily splitting a provided String based on a provided regular expression String. The only trick is figuring out a regular expression token to use to separate strings that are to be split that doesn't exist in the string naturally. For example, "e" would not work well because it is so commonly present in English text naturally. A related challenge in picking the appropriate regular expression token is to ensure that a symbol with special meaning in regular expressions (such as "^" for start of line) is not used.

I have blogged previously on how I like to develop simple Java examples to learn from. One example that has provided me benefit multiple times is a simple Java application that I can run against a String I'm considering as a regular expression token to be used with String.split. It is shown next.

Simple Java Application For Determining Viability of Regular Expression Splitting Token

package dustin.examples;

import java.util.regex.PatternSyntaxException;
import static java.lang.System.out;

/**
 * This simple class accepts a String as a potential regular expression token
 * and demonstrates how this provided String work work as a token in a 
 * {@code String.split} invocation.
 */
public class Main
{
   /** OS-independent new line. */
   public static String NEW_LINE = System.getProperty("line.separator");

   /**
    * Main executable function for running this test.
    *
    * @param arguments Command-line arguments: single argument is expected that
    *    represents the candidate regular expression token.
    */
   public static void main(final String[] arguments)
   {
      if (arguments.length < 1)
      {
         out.println(
              NEW_LINE
            + "No argument was provided.  A candidate String token must be provided."
            + NEW_LINE);
         System.exit(-1);
      }
 
      final String candidateToken = arguments[0];
      out.println("Provided token is: " + candidateToken);

      final String stringWithCandidateToken =
           "Java" + candidateToken + "has" + candidateToken + "regular"
         + candidateToken + "expression" + candidateToken + "support"
         + candidateToken + ".";
      out.println("String with candidate token is: " + stringWithCandidateToken);

      try
      {
         final String[] splitStrings = stringWithCandidateToken.split(candidateToken);
         for (final String splitString : splitStrings)
         {
            out.println(splitString);
         }
      }
      catch (PatternSyntaxException badRegExpPatternSyntax)
      {
         out.println(
              "Unable to parse " + stringWithCandidateToken + " on token "
            + candidateToken + " using String.split method - "
            + badRegExpPatternSyntax.toString());
      }
   }
}

This very simple example accepts a single string from the command line and attempts to use that string as a token for splitting a longer string into pieces. The example builds a generic string with the provided token and then splits on that token. The output of running this simple application tells how well that provided string works as a token.

The remainder of this blog post presents screen snapshots from running this simple application with some potential splitting tokens.

The first screen snapshot demonstrates running this application against a candidate token of "d". This actually works in this example because there's no "d" already in the string, but obviously would not work in most realistic situations.



In the second screen snapshot, the problem of using a common letter such as "e" as the splitting token is demonstrated. The strings do not split as desired because "e" existed in the string before tokens were applied.



The third example uses "^" as the regular expression splitting token. Because "^" has significance in regular expressions (start of line), it doesn't work too well as demonstrated in the next screen snapshot.



The "^" character is not the only token behaving this way. The next screen snapshot demonstrates similar behavior for "$" (end of line).



The "^" and "$" characters were not good choices for a regular expression-based token for splitting strings, but there are even worse choices. This is demonstrated for "*" in the next screen snapshot.



The last example, using "*" as the regular expression splitting token, led to an unchecked (but explicitly caught in my example anyway) exception PatternSyntaxException.

Parentheses also are significant in regular expressions (mark groupings). These don't work well as tokens for string splitting as demonstrated in the next screen snapshot.



As long as the colon (":") or semicolon (";") are not used naturally in the text being split, they work well in this scenario as demonstrated next.



The String.split method is not limited to splitting on a single character. In the next example, I use the three characters of the Groovy Spaceship Operator (<=>) as the token (and it works fine).



Finally, what happens when the "pipe" character ("|") is used for a regular expression token to split a string? Let's see.



The pipe is like an "or" in regular expression parlance and we see that behavior manifested in the example in the just-shown screen snapshot.

The Pattern class documentation (part of the java.util.regex package) documents "regular expression constructs," but the simple application demonstrated in this post provides an easy to way to determine and verify appropriate Strings to be used as tokens in splitting a string. A Groovy script version of this simple Java application is shown in my blog post Groovier Java RegEx Token Determination.

The 2010 edition of JavaOne features numerous presentations of interest to the Java developer in subjects such as JVM languages (Groovy, JRuby, Scala, Clojure), Java concurrency, HTML5 with Java, monitoring Java applications, cloud computing, modularity/OSGi, JDK7, REST/JAX-RS, Java Persistence API, NetBeans, JavaFX, and Java testing/debugging.

JavaOne 2010 is being held in conjunction with Oracle Develop 2010 and Oracle OpenWorld 2010. These major events are being held in simultaneously in San Francisco September 19-23, 2010. It looks like JavaOne 2010 and Oracle Develop 2010 (both developer-focused events) will be held in "The Zone," which is described as "San Francisco's Hotel Nikko, Hilton San Francisco, and Parc 55 hotels and the surrounding area." Oracle OpenWorld is hosted in the well-known (from previous JavaOne and Oracle OpenWorld conferences) Moscone Center.

A JavaOne 2010 Blog RSS is now available. This is useful for updates regarding JavaOne 2010. I'm particularly looking forward to the announcement of the availability of Schedule Builder to help with creation of a schedule of presentations to attend. The JavaOne 2010 Blog RSS feed has already provided an update on the Appreciation Event, which will feature The Black Eyed Peas, Don Henley, and Steve Miller.

I've already noted more presentations that I want to see than there will be time to see. However, with no dates/times yet available for the presentations, hands-on labs, and Birds of a Feather sessions, it is not possible to know yet which I am most likely to attend. The DZone/JavaLobby article JavaOne 2010 Accepted Talks lists some of the presentations, lab sessions, and BOFs accepted for JavaOne 2010, but they are all available (with dates/times "coming soon") on the JavaOne page.

In related news, the current Java.net poll asks, "Which JavaOne 2010 track will draw the greatest interest?" The tracks at JavaOne are all listed, but only one can be selected: Core Java Platform; Desktop Java; Enterprise Service Architectures and the Cloud; Java EE Web Profile and Platform Technologies; JavaFX and Rich User Experience; Java ME and Mobile; Java for Devices, Card, and TV; and The Java Frontier. My guess is that I'll attend many presentations from "Core Java," "Desktop Java," and "Java Frontier." Two of these three ("Core" and "Desktop") are currently leading the votes for most popular among other Java developers as well. Of course, several of the presentations are grouped into more than one track and often the Core, Desktop, and Frontier tracks overlap.

I previously publicly questioned if 2009 JavaOne was the last edition of this conference. Fortunately, it wasn't and I'm looking forward to the wide variety of topics being discussed at JavaOne 2010.

I have written two previous blog posts on movie quotations applied in software development: Classic Movie Quotes Applied to Software Development (referenced in a CNN entertainment article) and More Movie Quotes Applied to Software Development. This blog post focuses on another single movie quote that sometimes is useful to remember during software maintenance and debugging. From my favorite movie of 2009 (Sherlock Holmes) comes this quote from Sherlock Holmes to Dr. John Watson:

Never theorize before you have data. Invariably, you end up twisting facts to suit theories, instead of theories to suit facts.

It is often useful to learn from our own experience and narrow down problems based on similar things we have seen in the past. However, there are times when we can jump to a conclusion too quickly because something looks very similar to what we've seen before. If we're not careful, we can waste significant time and effort chasing a certain possibility only to realize that we've wasted our time and, in the worst cases, perhaps made things worse trying to "fix" something that wasn't really the problem.

The quote referenced above from Sherlock Holmes is a reminder of the dangers of assuming too much before gathering sufficient data. Without sufficient data, it is easy to start seeing what we want to see. If we think something is the problem, we want symptoms to fit our preconceived notion of the proper solution or fix.

This effect is not limited to software development. A similar effect is often seen in a wide variety of things: politicization of science, the phrase "love is blind," and parents' sometimes inability to think their kids can do any wrong.

In most situations, including software development, the best decisions are made with better data. There are times when the cost of obtaining additional data is so high that we're better off starting to make decisions without the additional data, but in cases where it is relatively inexpensive to gain more data about a problem, that small price is usually well worth it. Making a proper decision early in design, in refactoring, and in fixing a problem can often result in a much quicker implementation or resolution.

As alluded to above, the dangers of jumping to conclusions without sufficient data are not limited merely to wasting time on a wild goose chase. In even more costly situations, grasping at straws or desperate fixes for theorized problems can make code unnecessarily verbose, worse performing, needlessly complex, or just plain wrong. Anytime code is changed, there is some potential for breakage. Changing code for no reason other than we think we're fixing a problem that's not really a problem introduces this risk with no benefit.

Making decisions based on previous experiences and applying past experience to current and future work are often beneficial practices that improve or productivity and efficiency. However, these tactics can be detrimental when we decide to design a new system or troubleshoot the existing system solely on previous experience even when the new problem is only remotely related or not related to our previous experience.

The best way to deal with this is to understand well the lessons learned from the past (how and where they apply) and to learn as much as we can about the given problem to know how it's the same and how it's different than our previous encounters with a seemingly similar issue.

Several useful features related to JDBC have been posted on DZone/JavaLobby recently. I briefly reference these here.

JDBC Best Practices: Latest DZone RefCardz

The latest DZone Refcardz to be released is the JDBC Best Practices Refcardz. The DZone overview of this Refcardz states the following:

JDBC Best Practices has something for every developer. This DZone Refcard starts off with JDBC basics including descriptions for each of the 5 Driver Types. This is followed up with some advanced JDBC on Codeless Configuration, Single Sign-on with Kerberos, Debugging and Logging. We even threw in a SQL Quick Reference to round things off.

The ABCs of JDBC

Daniel Rubio has posted a series of articles with the title "The ABCs of JDBC." So far, they are:

• The ABCs of JDBC, Part 1 - Getting Started with JDBC
• The ABCs of JDBC, Part 2 - ResultSets
• The ABCs of JDBC, Part 3 - The JDBC API
• The ABCs of JDBC, Part 4 - Stored Procedures

New Challenges in JDBC Usage Patterns
(Added 14 June 2010)

New Challenges in JDBC Usage Patterns is a video that, according to the DZone link, features "Jesse Davis [giving] us an update on what's happening at the JDBC expert group in the JCP."


Conclusion

I am happy to see that I am not the only one that still sees advantages to learning and using JDBC even in these days of NoSQL and ORM popularity. As I wrote in SQLPhobia: The Irrational Fear of SQL, JDBC can be the appropriate solution in some cases. I especially like how easy it is to use JDBC with the Spring Framework.

I started this blog in October 2007 and have written hundreds of posts with a few that I'm particularly proud of and/or that have been particularly well received. Besides my own blog posts, I read many blog posts each week (particularly if highlighted on JavaWorld, Java.net, or DZone). Over the many years I have been reading software development blogs, I have read many useful and informative blogs and written a few that I like to think fit in the same category. However, five blog posts stick out in my memory as so effective that I wish I had written them; I briefly reference and describe those five here and explain the reasons I wish I had written them.

All of these posts share at least one common trait: they are linked to and referenced from my blog multiple times.


I Couldn't Have Said It Better Myself

I was contemplating writing a blog post about too much simplicity not being a good thing (similar to my post about flexibility being turned from good to bad when applied in excess) when I ran across the post Simplicity is Complicated. As I read this post, I realized that there wasn't much more I could add to this, so I didn't try. Of all the posts on my list, this may be the one I most literally wish I had written.


Bucking the Trend with Substance and Being Correct

Today, EJB's 101 Damnations probably seems like nothing too new. At the time of its publication, however, it was one of those contrarian viewpoints I enjoy so much for challenging the establishment when a challenge is merited. The problem with some contrarian blog posts is that they lack substance behind the assertion that "such-and-such sucks." The "EJB's 101 Damnations" is full of detailed explanations that poke holes in the early problematic EJB specifications. EJB has come a long way, partly due to articles like this one (and also due to external forces such as the Spring Framework).


Changing the Industry

The blog post Ajax: A New Approach to Web Applications had exactly that effect: it ushered in a massive change in how many web applications were and are developed. Many developers have since claimed that they were using the same set of technologies or similar sets of technologies to do the same type of thing before this, but what Jesse James Garrett did with this post was to coin a catchy term and outline the basics and concepts of the approach in a manner that was readily accessibly to the masses. I wish I had written a post like this for purely selfish reasons: it would be something to have this type of effect on our industry. Garrett never claimed to have made up the approach of using existing technologies in such a way to make a more dynamic user experience. Indeed, he even cites two already existing examples (Google search engine's Suggest feature and Google Maps) right off from the start. He and his colleagues simply coined a term and wrote this introductory post that sped up the rate of adoption dramatically.


Generally Helpful

Tom Kyte's post Free Things I Use... is excellent because it pointed me to some products that have made my life much easier since then. He lists many tools he uses that are generally of interest to software developers and database administrators. I have seen similar posts by other authors since then, but this was the first one like this that I recall reading and being a beneficiary of. It's nice to have investment in reading of a particular blog post pay for itself many times over and my time reading this post several years ago has paid for itself over and over and over since then.


Specifically Helpful

These are the types of posts I like to attempt to write most often. These are also the types of posts that motivated me to write that more software developers should write blogs. I have been aided countless times by blog posts and forum threads explaining why I was seeing a strange and unseemly exception or error message or unexplainable behavior. The one post that comes to mind, though, when thinking of a specific, focused post that has made a major difference in my understanding is Common E4X Pitfalls. When I was first learning and using Flex and E4X, I visited this post frequently. This is the type of post that truly epitomizes how software developers can help one another. While most of the information in this post is available in other sources, it's value includes the organization of it all in one location in a concise but thorough presentation. I often don't need blog posts that tell me how to do something (because of the many great how-tos and books already out there) as much as I need something warning me about what not to do or warning me about tricky, less advertised corners. Common E4X Pitfalls does just that for E4X.


Conclusion

There are, of course, hundreds of really good blog posts and thousands of good blog posts out there. There is no way that any developer can read even all of the "good" blog posts. Do you have a favorite blog post that you wish you had written or that you repeatedly reference or have bookmarked, or have even printed out to post near you? I'd love to learn about blog posts that have had this type of effect on fellow developers.

I have read about and started to learn about JavaFX twice and both times have been "strikes" in the sense that there wasn't enough there to really use. Both of these forays into JavaFX occurred at the time of 2007 JavaOne and 2008 JavaOne as a result of the pomp and ceremony at these conferences regarding JavaFX. Both times, I stopped wasting my time because I realized that it wasn't ready for prime time yet. As in baseball, the third strike is a strike-out, so I've been hesitant to investigate JavaFX or spend any more time on it unless I'm convinced it's finally something more than bluster and slideware.

The announced Oracle acquisition of Sun led me to wait for that third try until after Oracle had made its JavaFX-related intentions clear. Oracle has now done that and it sounds positive for JavaFX. Use of JavaFX for this year's Winter Olympics in Vancouver has also been among JavaFX's biggest and most positive recent news.

In most of my posts, I either write about things that I have learned from experience (cogitations/observations) or that I am guessing about (speculations) based on similar experiences in the past. In this post, I am going to postulate a bunch of questions about JavaFX in hopes that someone can authoritatively articulate answers to these questions. These are high level questions that I want to know the answers to before investing any more time or energy into learning JavaFX.

One of the difficulties I have encountered with JavaFX is distinguishing between JavaFX features that are and JavaFX features that are to come. Many of the JavaFX documents seem to be optimistically written about what it will do, but often in terms that are ambiguous as to how much of that is done today and how much of that is still the vision. I hope I can get clearer answers in response to this post.


What is JavaFX's License?

The JavaFX license has always seemed a little complicated, but this is not completely new as some other products have similar complicated licenses. According to the Wikipedia article on JavaFX, the Java FX license is really a collection of "various licenses for the modules that compose the JavaFX runtime" that include the proprietary runtime, GNU GPL, and the "normal" Java-esque dual license of GNU GPL/CDDL.

I'm not the first to wonder about JavaFX's license(s). Related posts on the subject include JavaFX: Sun isn't sure about the license (23 May 2007), The JavaFX Trap (1 August 2008), and The JavaFX 1.0 License - Completely Unreasonable?.


Is JavaFX Open Source?

Partly. As described in the section above on licensing, there is a portion of JavaFX that is open source, but significant portions are not. The openjfx site now forwards one to the JavaFX.com site.

Again, I'm not the first to wonder about the degree of "open sourcedness" of JavaFX. Others have posted questions on this topic in posts such as JavaFX: Open source or not? and the JavaFX forum thread Is JavaFX open-source? I particularly like the latter (the forum thread) because it nicely covers the intricacies of making a product like JavaFX open source.


Is JavaFX Standard?

As far as I can tell, JavaFX is mostly proprietary, was owned by Sun, and is now owned by Oracle. I'm not aware of a standard that multiple implementations can be written to. Despite its problems, the Java Community Process (JCP) has been the process by which "standard" portions of Java (both SE and EE) have evolved. I'm not aware of any Java Specification Request (JSR) for JavaFX? Is there one? I'm similarly not aware of any standard upon which JavaFX is based nor any implementation to compete with it directly (same syntax, etc.). In other words, is there another implementation I can switch to without changing code if I don't like something about the current implementation (similar to switching Java EE application servers or JVMs)?


Is JavaFX Java?

JavaFX certainly has the four letters "J-a-v-a" in it, but so does JavaScript (which is not Java at all). The JavaFX FAQ touts one of JavaFX's advantages being the ability to leverage Java developers' experience and one question/answer in the FAQ talks about running JavaFX applications on any device with a Java Runtime Environment.

I have a difficult time thinking of JavaFX as "Java" for several reasons. First, the syntax of F3-inspired JavaFXScript is not that similar to Java and it is my opinion that a Java developer will have as easy or possibly even an easier time learning JavaScript or ActionScript than learning JavaFXScript. Second, to me, Java is about standards. JavaFX, as far as I can tell, is in no way standard. It might be Java-based (as are Google Web Toolkit, Pivot, and so many other frameworks), but it's not Java. Third, JavaFX integration with Java is not quite as easy as I'd like for something that is "Java" itself. For more details on integrating JavaFX with Java, see Closing the Gap Between Java and JavaFX and Calling JavaFX Classes from Pure Java Code.

On the other hand, JavaFX does seem to enjoy some traits of "Java." One, it shares the four previously mentioned letters. Two, it has the "write once run anywhere" mantra of Java. Three, it makes heavy use of "Java infrastructure" such as the next-generation applet and Java ME. Four, it can use the wealth of Java SDK libraries and third-party libraries and so enjoy advantages enjoyed by languages such as Groovy and Scala.

For me, whether my client-side technology is "Java" is not all that important. What's most important is how well my client side technology interacts with my Java server-side software. This is why I've liked Flex+Java so well. I have benefited several times from the ability to easily swap clients against the same server-side software. JavaFX doesn't feel very "Java-ish" to me, but I also don't consider that to be a significant disadvantage. If JavaFX provides capability to talk to my server-side software via HTTP, SOAP, REST, and JMS like Flex does, then that's good enough.


How Large is the JavaFX Community?

This is a difficult question to answer and it is even more difficult to how large it can become. On the encouraging side, there have been numerous postings online about JavaFX. The trick, of course, is deciding if this is a sample of a large, growing, and vibrant community or is more a matter of a relatively small number of enthusiastic developers.

Java.net polls have provided some indication of how large the JavaFX community is and how large the potential community might become. There was a poll clear back in 2007 as well as a relatively recent poll. I get the feeling that many Java developers still have a "wait-and-see" attitude toward JavaFX. Considering the huge fanfare over JavaFX in 2007 JavaOne and 2008 JavaOne and the long wait after those events to get something tangible, this attitude is to be expected.

Of particular concern is David Herron's comment in his blog post The iPad, the Flash kerfluffle, Applets and JavaFX regarding attendance at the Silicon Valley Web Java Users Group:

How many of you are interested in JavaFX? A meeting of 100+ geeks in Silicon Valley who are associated with a Java User Group, you'd think a few of them would be interested in JavaFX. One person raised their hand. I think that says a LOT.


Does JavaFX Have a Niche?

Related to community size is the question of what JavaFX has to offer that might set it apart from the rest of the crowded field. It is difficult to find a front on which JavaFX doesn't have a mighty competitor to face, often more entrenched than JavaFX. For web-based RIAs, JavaFX is playing catch up with Flex and Silverlight. Many developers choose to not use Flex or Silverlight because they prefer something more standard, but that's not JavaFX (as far as I know -- see question above). Even if JavaFX was standard-based, it would have to compete with several Java-based standards (JSPs/servlets and JavaServer Faces) and with one of the biggest standards of all: HTML. HTML 5 finally seems to be gaining some traction and could be a formidable foe.

Mobile devices seems like a decent niche for JavaFX with wide availability of Java ME. However, the rapidly growing popularity of iPhone and Android-based telephones are making Objective C and Android compelling platforms for mobile devices. The irony here is that Android is arguably "more Java" than JavaFX.

With JavaFX competing for market share on the web against Flex, Silverlight, HTML 5, Google Web Toolkit, and many others and with JavaFX competing for mobile market share with iPhone and Android, the desktop seems like one of JavaFX's best frontiers for success. If JavaFX and Swing were made more easily integrated, this could be a very compelling combination.

One of JavaFX's selling points is the ability to run on all the aforementioned platforms: web, desktop, and mobile. On the surface, this is a really nice feature that could save development time and provide users with consistent experiences. However, given the significant differences in these platforms and in user expectations for applications on these platforms, I'm less sure of the value of this proposition.


Where Does JavaFX Fit with Oracle?

My belief is that the Oracle acquisition of Sun may be the best thing that could have happened to JavaFX in terms of its future viability. Oracle may be able to turn JavaFX into a profitable product and therefore justify continuing heavy investment in it that Sun started.

I think Oracle has provided a model for the likely treatment of JavaFX in the future. Keep in mind, that this is pure speculation (one of the key components of my blog's title). I think that Oracle could treat JavaFX like they have treated the Oracle Application Developer Framework (ADF). As I understand it, a developer can download ADF with JDeveloper for no charge and then purchases runtime licenses on a per processor basis (see Oracle's ADF site for complete and correct details). I've never used ADF, but I understand that it's a convenient framework for simplifying Java EE development. It is most likely not more familiar to more developers (such as me) because of its proprietary nature. It's standards-based, but is not itself a standard.

I personally am not stuck on something being open source. If the best product for my needs is not open source, then it's still the best choice. If all else is equal, I'll typically choose the open source product, but I'm not afraid to carefully use a proprietary solution (especially when it's free or low-cost) when its advantages are obvious and its use is handled correctly (sufficiently isolated and abstracted). I think JavaFX could have a reasonably successful future under the ADF model, but it's unlikely to be as successful (in terms of usage) as it would be if it was free and open source.

No matter what happens with JavaFX under Oracle's stewardship, I think it is important to remember that the much-revered Sun already had JavaFX as a proprietary, non-standard product with some open source pieces before Oracle ever had any rights to the product.


Does JavaFX Have a Future?

Since the Oracle acquisition, I have felt that JavaFX likely will be around 1, 2, and even 5 years from now. That being said, I am still not convinced that it will ever be "the" or even "a" dominant display technology, at least as it stands today. Instead, I see it as a promising alternative that might be the best fit in certain situations (such as when the ability to run on multiple platforms' screens is of vital importance) and not the best fit in many situations where a competing and likely more established technology already provides a better fit.

As I have thought about and written this post, it has felt to me like JavaFX is trying to find itself. I think it's getting closer to finding itself and, when it does, I may have to give it the third try and hope to avoid a strike-out.


Other Questions About JavaFX

Here are some other online postings of questions (and sometimes answers) related to JavaFX.

⇒ JavaFX Frequently Asked Questions

⇒ Ten Questions for JavaFX

⇒ Will JavaFX Ultimately Become a Widely Used Rich Client Technology?

⇒ What I Don't Like on JavaFX

⇒ JavaFX Basic Questions


Conclusion

In this post, I have recorded some of my questions regarding JavaFX along with my best attempt at answering those same questions. However, I'd appreciate any additional and/or corrective details that can be provided for me to better understand what JavaFX is and whether it is something I want to invest more time learning when I have competing interests in other "new things" (such as Android SDK development for my Droid).

There have been a few recent online articles and posts that I think deserve mention here. These are related to Android being good for Java, praise for the field of software engineering, and a sense of what Java developers think of JavaFX.


Software Engineering: High Pay, Low Stress?

A recent Yahoo! Finance posting of a Investopedia article (Five High-Paying, Low-Stress Jobs) list software engineering as one of their five jobs with high pay and relatively low stress. Some of us may not agree with the stress part, but it is not going out on a limb to say most of us do have less stress than a combat soldier (referenced in the article as an example of low pay and high stress). Under "Computer Software Engineer," the article states, "many software engineers can work from home, since their jobs can be done from practically anywhere. Software engineers also bring home steep salaries, normally ranging between $54,000-130,000 a year. There's nothing nerdy about that."

Another position closely related to software development also made this list of five professions proposed to be high pay and low stress: the technical writer. The other three careers on this list are civil engineer, physical therapist, and massage therapist.


Android: Bringing non-Java Developers to the Java Fold

One of the effects of the rapid rising popularity of Android-based telephones is the new entrants into Java's ecosystem of developers from non-Java environments. For example, the author of the blog post Android Development - Debugging Your App starts that post with the sentence clauses, "Coming from a Windows environment, specifically the .NET space," and then goes on to talk about debugging in Eclipse.

The significance of this, of course, is that a whole new group of developers with little or no Java experience are now essentially working with Java itself as they develop Android applications and are using tools of the Java ecosystem such as Eclipse. Java may have originally been targeted at the web browser (applets) and may have in recent years become known as a technology for the enterprise space, but now it appears that it could be the Android-based handsets that bring standard Java (but not Java ME nor JavaFX) a growing base of users. Who would have predicted this before Android?


Java Developers on the Future of JavaFX

A recent Java.net poll asked the question, "Will JavaFX ultimately become a widely used rich client technology?" None of us have a crystal ball and these polls are obviously non-scientific, but I thought the responses were pretty inline with my own opinions based on talking to other Java developers about JavaFX. The respondents seemed to really consider the issue and provide a fair personal assessment. There were also several good comments added.

To the question of whether JavaFX will become widely used as a rich client technology, well over half of the nearly 370 responses were either flat-out "No" (18%) or the little less sure "Probably Not" (a whopping 40%!). About 16% of the responses were the tepid "Maybe" while about the same percentage were more positive and answered either "It's already widely used" (2%) or the much more realistic "The Version 1.3 Improvements Make it Likely" (14%). I don't see how anyone can think that JavaFX is widely used currently (unless the interpretation of "widely used" differs significantly from mine) and the results show that few legitimately believe that to be the case.

There are several observations from this poll. First, JavaFX still has more people thinking it won't become a widely used rich client technology than those who think it will. Second, I think this poll shows once again that the Java development community (or at least the members of the community who read Java.net and participate in the polls) are cognizant of what's happening around them. Third, the comments on this poll are really worth reading. I think they sum up pretty well some of the major concerns the majority of Java developers who think about rich client technologies have about JavaFX.

The May 12 whyjava blog post Reasons for Incompetent Software Developers in India caught my attention. This post, which rightfully earned a Top Links position on DZone, is explicitly aimed at highlighting reasons why some Indian developers are less competent, but what I couldn't help think as I read his reasons is how they have applied to some of the less competent developers I have witnessed working in the United States. In this post, I look at the five reasons outlined in that post from a "western" perspective; some things aren't all that different because we're all humans.


The Importance of Wanting to Develop Code

I have long felt that it is important to really want to develop code to be successful in our industry. The reason for this is that most developers I know do really love what they do and most of us are better and do better at things we enjoy doing. Developers who tolerate but don't really have a passion for development are often at a significant disadvantage. There are many reasons for this, some of which are the nature of a passionate developer: more enthusiastic, more creative, more energetic, more involved, more willing to learn and improve at the craft, and on and on and on.

The author of the post Reasons for Incompetent Software Developers in India points out that many developers in India are "developer[s] by chance not by choice." I think there is some truth to this in the United States, but it is less of an issue now than it was in the mid- to late-1990s. In that time frame, the economic side of the software development community was very similar to what India seems to be experiencing: many projects and clients would take their chances on anyone willing to sling code because demand for software skills and labor exceeded supply. As demand has relaxed, the supply has as well. We've lost some good software developers to this, but a large percentage of those who don't really care much about software development have been affected by this.

It is human nature to follow the money. Many people don't care what the job is as long as it pays well. This may be fine for certain occupations, but it is a big disadvantage in software development.


Problems with the Education of Software Developers

When I read the post's author's primary complaint of higher education in software development in India as "importance is given to marks than to practical learning, students just cram the things and get score but practically they know nothing," the first thing I thought of is that he could have replaced "India" in that sentence with the name of any nation and it still would have been accurate. This seems to be another symptom of human nature: we do what is rewarded. Grades ("marks") are what help us get that first job, so priority one for most of us in college is to get the best grades we can get to land that first job. Of course, actually learning something is of benefit in keeping the job, but we're often (and not surprisingly) more worried about getting the job than keeping it. After all, you don't have to worry about keeping a job you never got in the first place.

Bjarne Stroustrup's article What Should We Teach New Software Developers? Why? (Communications of the ACM) provides a particularly credentialed opinion (in-depth industry experience combined with academic experience) on how computer science education needs to be improved even in the United States. I wrote more about this article in my post Must-Read Software Development Resources for 2009.


The Importance of Continuing Education

One of the stated reasons for the existence of some incompetent developers in India is "developers don’t keep themselves updated." This too applies everywhere and is closely related to the passion I discussed earlier. Most of us want the professionals who impact our lives (doctors, attorneys, real estate agents, dentists, civil engineers, architects, etc.) to stay current in their field and offer cutting-edge service. Users of software are no different than us and want the same from us. It's easier to invest the time and effort to learn more if we have a passion for what we do and if we truly want to master our craft.

Many developers do read blogs and articles and books, do attend conferences, do experiment or learn a new framework or language or library, and so forth, but many do not. Why don't more developers continually learn? There are many blog posts on this subject, but the explanation often boils down to we, as humans, having other interests and sometimes those interests completely dominate the desire or even ability to learn new things outside of the regular work week. The best situation, of course, is to learn new things on the job, but this can also lead to dysfunctional behaviors such as resume-driven development and Not Invented Here syndrome where the real motivation is to learn something new even when not necessary or desirable for the client.


Management is Where It's At?

The first three reasons listed for the existence of some incompetent developers in India were reasons that could be used to explain incompetent developers anywhere, including the United States. The fourth one did surprise me at first. The blog author wrote, "Everybody wants to become a manager." This is certainly not my experience with the majority of software developers in the United States. Many developers do end up in management through coercion (it's the only way to receive compensation past a certain level or to be allowed to make certain types of decisions), but most of the ones I know would stay in development jobs (especially low-level technical lead and architect positions) if the money, prestige, and career advancement were the same.

There are exceptions to any generalization, but I have noticed that, in general, the developers most in a hurry to move to management are those who lack any passion for development. This is sensible: why limit oneself's career growth or compensation for a job that holds no particular appeal over the job that tends to pay more or allows for faster career growth? The best developers generally seem to love development so much that they are willing to not "advance" up the ladder as quickly as they might because they are in no hurry to leave development. I earned an MBA several years ago thinking that I would one day need it. Instead, I've tried to carefully craft my career to allow me to focus on development and design as much as possible with minimal managerial duties as distractions. I truly enjoy being a technical lead and a mentor, but the Microsoft Project stuff and bean counting are not very appealing to me. It is likely that I'll end up in management roles again in the future, but I'm in no particular hurry.

There are exceptions to this, but they still take me by surprise. In a recent blog post, Bruce Eckel (of Thinking in C++ and Thinking in Java fame) stated "My interests have been shifting ... away from software development and towards business." This was surprising at first, but not so surprising when I considered a blog he wrote not too long ago called "Software Development Has Stalled."

It seems to me that software development is a little unique in this regard. In most industries, it is commonplace to want to rise as rapidly in the ranks as possible. Software developers want to rise technically and received recognition and accolades and better compensation, but the desire to "climb the ladder" doesn't seem as embedded in our brains as it is in the minds of others in other industries. I have even had managers (not developers) ask me why I want to stay in a full-time development position rather than move onto management. These individuals cannot understand this. So, again, what was described in that post about Indian software development may not be quite as true in the United States for software development, but it is certainly very true for the typical United States professional position.

I think we all benefit when software development managers have been successful software developers. It's my experience, however, at least in the United States, that many of the best developers I have worked with cannot picture themselves doing anything else but architecting, designing, and building software applications. In fact, as a beneficiary of many good software development managers (I hope to blog on the importance of good development managers in the future), I think it's very important to have qualified people in those roles and they are often important roles; it's just that the best developers often have no interest in those roles.


Giving Back: Open Source/Community Contributions

The fifth and final point of the post explaining the reason for some incompetent software developers in India is "No contribution to opensource community" and the post's author states, "I don’t know any of my friends or friends of friends including me who has contributed to opensource community." If one means actually contributing code to viable open source projects, I don't think the majority of developers in the United States do that either. However, if one means contributing to open source via writing blogs posts and articles, writing bug/enhancement requests, giving presentations, etc., then I think there is a much higher rate of open source contributions in the United States than direct code contributions. Even with the more widely arching definition of "contributing to open source," I think it's very safe to say more developers never or rarely contribute to open source than do contribute to open source.

Human nature yet again explains this phenomenon. Open source is, in some respects, a problem of the commons: we all stand to benefit from it, but it can be tempting to let others do all the work while we realize the same benefit without any contribution. With this in mind, I am always impressed with the time and effort people invest in creating, improving, and teaching open source products. The only explanation I have is that other human characteristics (personal pride, love of challenge, sense of accomplishment, satisfaction from helping others, etc.) come to play and override selfish interests enough to lead to these various types of open source contributions.


Conclusion

While the blog post Reasons for Incompetent Developers in India focuses on possible explanations for a certain percentage of incompetent developers in India, the underlying causes are not unique to Indians, but are part of our human nature. The degree that these are manifest may be different between two areas because of various forces at work (economy, labor supply, etc.), but the underlying principles are part of our shared human nature.

Even the existence of the post is a demonstration of contemporary human thinking. Only an Indian software developer could write the things that were written in this blog post on Indian software development without far more controversy. There are many reasons for this, but it is certainly far more difficult to argue with someone "on the inside" who has practical experience with what he or she is writing about. We seemingly can say derogatory things about our own nationality, culture, gender, race, or other demographic, but it is generally deemed unacceptable to say that about another demographic. It kind of reminds me of the concept of "You better not mess with my brother; that's my job."

I don't know much about the state of software development in India, but I have no reason to doubt that what this blog post author wrote is accurate for a certain percentage of Indian developers because I have seen many of the same explanations nicely fit the few truly incompetent developers that I have worked with (and I've never worked in India).

In the Code Anthem blog post Bad Code is Viral, Amber Shah describes why "writing bad code is viral." This is a great post that reminds me of a pattern I have seen repeatedly: bad code does seem to have a viral nature. Even when the original bad code is rooted out, it is often removed too late and the infection has spread into other pieces of the code. In this post, I look at some of the observations I have made regarding bad viral code and how to contain it and eradicate it.


Why Bad Code is So Viral

There are many reasons why bad code is so infectious and viral. I discuss some of these reasons here. It is often true that code approaches, good or bad, are copied and imitated. When good approaches spread, it's a best practice; when bad approaches spread, it's a virus.


Bad Practices Can Be Learned

The Code Anthem blog post I cited at the beginning of this post mentions one of the reasons bad code can be so viral: "Your code base is the primary training manual for new developers on your team. If they’re learning from crappy code, that’s how they will write code too." We all learn from writing our own code and reading and maintaining existing code. Especially when we don't know better, it is easy to "pick up" new code approaches without regard to how good or bad they are. With experience, we are more likely to recognize bad ideas when we see them. However, even experienced developers can learn bad habits, especially when learning something new to them.


Bad Code Can Be Justified

Most developers don't intentionally write bad code because they enjoy it. They either don't know better or choose to write bad code because they have justified it to themselves. Justifications we might use for knowingly writing bad code include time constraints, lack of resources, and thoughts of replacing it later when there's more time, etc.


Copy-and-paste "Reuse"

There are many problems associated with Copy-and-paste reuse, not the least of which is the greater likelihood of spreading bad code. Of course, if there is a logic problem with the original code or if the code needs to be changed for any reason, it is likely that the same change needs to be made elsewhere as well. Similarly, even if the bad code is completely cleaned up, its effect may remain long after that because of the copied code.


Bad Code is Often Easiest Initial Code

One of the reasons it is easy to write bad code and even easier to copy and use bad code is because bad code often seems easiest at first. There are certain approaches with code that may seem like a good idea at the time or at least like not a bad idea, but then prove to be disastrous in the long run. This is related to the time constraints discussed above when a developer chooses the easiest way for short-term benefit at the price of long-term detriment.


The First Impression is Not Always Correct

I've heard it said that first impressions are often correct. That's increasingly the case as one gains experience, but it's not always true and it's certainly often not true when one lacks experience in a given area. In our rush to deliver, we sometimes go with our first impression because it's "good enough" and we don't want to "undo" anything we've already designed and implemented. This can become very dysfunctional if we start shoehorning a solution into our original concept even when it doesn't really fit. Another developer can be negatively influenced when he or she sees a poorly implemented solution and it becomes his or her "first impression" as well, blocking out other ideas. There is an interesting twist here: even "good code" in one situation might become "bad code" in a different situation. This is one of the reasons I believe it is good to infuse new blood into a development team to bring in new ideas and break people free from first impressions and "that's the way we've always done it" thinking. Individuals can also gain these benefits from choosing to work with different developers.


Ulterior Motives

I have blogged before about how selfish developers can be a real drag on a project's success when they succumb to dysfunctional motivations. Bad code is just one symptom of this and can easily spread if multiple developers are infected by such motivations.


Afraid to Ask

One of the reasons that bad code is introduced into systems is that the person introducing it doesn't know better. Sometimes, this may be due to a lack of knowledge. If that developer is afraid to ask questions or otherwise chooses to go it alone rather than getting help, he or she is more likely to introduce bad code or to spread bad code. Indeed, this is another case where even code that is considered good in one use is bad when misapplied. Asking the author of the original code why it was "good" might help the developer to understand that a similar approach won't work so well in his or her different situation.



Remedies for Bad Code Viruses

Just as with human health, the best protection against the bad code virus is preventative. The following are some of the ideas the doctor ordered for dealing with viral bad code.


Emphasis on Quality and Craft

I doubt that there will ever be a day where we developers don't need to be as efficient as possible and think we have more time than we need to finish a given project. That being said, it is important to instill the concept of software craftsmanship in ourselves and our fellow developers. Long-term considerations make bad code seem more expensive.


Code Reviews

One of the best ways to stop bad code in its tracks before it can spread is to have experienced developers review each others' code and review less experienced developers' code. It is also helpful to have less experienced developers review experienced developers' code not only to learn from what they're reviewing, but also because even experienced developers make mistakes. Indeed, experienced developers who work together for a long time might learn from each other and reinforce each others' bad habits and a less experienced developer might have a fresh perspective. Code reviews may not be my favorite part of the job, but they can be highly valuable.


Maintain Own and Others' Code

I've heard some very experienced developers state that all new developers should be required to maintain large software code bases for at least one year before being let loose to develop new code. Although this would be difficult for many of us to stomach, I do think there's some wisdom in it. I have probably learned as much or more about what makes good code from maintaining my own code (good and not so good) than I have from writing new code. Writing new code helps a developer learn how to be initially productive and solve an initial problem, but code maintenance helps the developer learn to how to write quality code that stands the test of time. Many positive features of software such as extensibility, flexibility, encapsulation, layering, and so forth are far more obvious during maintenance than during initial development. For me, there's no question that the best developers are those who understand the pain of those who will someday be maintaining their code (may be themselves they are helping).


Read and Apply Lessons Learned and Best Practices

Over the years, Josh Bloch's Effective Java has continually improved as a reference for how to write effective Java code. It's amazing that a book with only two editions can change so much, but the more I work with Java, the better that book gets. Books such as Effective Java (there are similar books for many programming languages) provide good ideas on how to write better code and how to recognize existing bad code.


Use The Code Before Committing It

Some code is most easily recognized as "bad" when one tries to use it. Unit tests can help with this as a built-in mechanism for using the code. If the unit tests are difficult to write to use the code, it is likely a problem with the code that will frustrate other users of that code as well. I often wish developers would use their own APIs first before releasing them onto others. If a piece of code seems "okay" or "good enough," an appropriate question might be, "But would I want to use this or call this?"


Be Wary of Comments Hiding Stinky Code

As with most software development controversies, I find that the two extremes (don't write any comments and comment everything profusely) are too extreme for practical large-scale projects. Instead, the best answer lies somewhere between the extremes and where it falls depends on the problem at hand, the language being used, and so forth. Although I think some comments are appropriate, too many comments are often indicate of bad code. It has been said that "comments are the deodorant for stinky code." If it takes many lines of comments to explain relatively few lines of code, there's a good chance that the code is very stinky. In such cases, this code should be refactored or improved so that code speaks better for itself and to prevent the bad code (with or without the comments) from being applied elsewhere in the system.


Mix It Up

All of the above recommendations can be effective in terms of reducing introduction of bad code and reducing and hindering its spread. However, these practices are most effective when used together. For example, reading quality references such as Effective Java is a useful activity, but reinforcing those concepts with practice in terms of development and maintenance makes it more likely that the principles will be understood and remembered.


Conclusion

Good and bad coding techniques tend get copied and to spread. We welcome the spread of best practices and fret over the spread of dysfunctional practices. The problem is that we don't always know how to differentiate between the two. This post has attempted to cover some of the most common reasons for the rapid spreading of bad code and has also outlined some effective practices for reducing the entry of bad code into our system and hindering its spread.

This was another week in which I ran across several blog posts and articles that I thought was particularly interesting and relevant. In this post, I reference these and quickly add my own thoughts on the various subjects. The topics covered by these posts I am referencing are quite diverse, but some common themes do underlie most of them. The individual topics covered include Android development, more on the future of Java, some "current Java" posts, and some insightful posts of software development career development.


Android Development

I recently upgraded to a Droid and have been more interested in Android ever since. There were several reasons for me choosing Droid, one of which was its Android SDK and the ability to leverage my Java experience in Android development as a hobby.

There have been several recent interesting posts on Android development. Besides the obvious sources of information on Android development such as the Android Developers site (including SDK information, The Developer's Guide, the SDK API/Reference, and the Android Developers Blog), there are nice community-oriented sites as well. Android Development Matters is one such site where various articles, posts, and forum messages related to Android development are all collected in one location.

Tim Bray is a prolific blogger and having him on the Android team has led to an influx of Android-related information. For example, his latest post on the Android Developers Blog is called Be Careful with Content Providers and warns Android developers to use undocumented content providers to learn from, but to not base their applications on these. Based on his comments, these undocumented content providers sound similar to classes and packages that Sun included in its Java SDK releases to get things done internally, but did not want developers using directly. Like these Sun examples, the Android internal content providers could change or be dropped at any time.

Although I partially selected Droid because of my interest in creating Android applications at a hobbyist level and although I purchased a book on Android development, I haven't actually started developing my first Android application yet. This in mind, it was nice to read a very quick summary of what one does to create an Android application in Team Pi's A Step-by-Step Guide to Write Your Own Android App. That extremely concise summary boils down the essence of writing an Android application, but for just a little more investment of time, one can go to the original source of this information referenced at the end of the post: How to Write Your First Google Android Application. Of course, the Android Developers Guide section on Application Fundamentals has provides nice introductory information.

In Is the Android truly open source?, Amy Vernon acknowledges that Android "is indeed more open than the iPhone," but is then critical Google for not being as open to outside decisions as they could be. I'm not sure if the author realizes that some of the most successful open source projects have been this way for some time now. SpringSource heavily controls the vision and future of the open source Spring Framework and Sun heavily controlled the decisions related to open source projects such as GlassFish, NetBeans, and so forth. IBM has had similar influence in the earlier years of Eclipse development. Other examples include Google's support of several projects including the Google Web Toolkit and Adobe's sponsoring and guidance of Flex. Even the Apache Software Foundation provides similar guidance and vision for its projects.

Most of us like to think of open source projects as being more than just source that we can view and possibly modify for our own needs. We like to think of the community providing input and coming up with the best results. This has even worked well in some limited cases. However, many of the successful open source projects (including those I just mentioned) seem to have benefited from a single vision of a controlling organization (be that SpringSource, Sun, IBM, Oracle, Apache Software Foundation, etc.). In even more practical terms, organizations like SpringSource and Sun have contributed substantial resources to these projects. Without these contributions, these projects would be nowhere near where they are today. Most of us know the disaster that often follows "designed by committee" (EJB 1.x and 2.x are great examples) and having a single guide for an open source project seems to be a common characteristic of many successful open source projects.

Although I believe that Vernon unfairly minimizes (even as she acknowledges its existence) the gap in "openness" between Android and iPhone, I think one of her statements is particularly important for all developers to remember: "I'm not a developer, so as long as the phone does what I want/need it to, I'm good with it." Too many developers waste time and creative energy arguing over the merits of their favorite operating system, their favorite web browser, their favorite RIA technology (Flash versus HTML5 and Apple versus Flash being among the latest rounds), etc. The sometimes difficult to swallow fact of the matter is that developers' preferences are secondary to the preferences of end users and clients. They don't care how it's implemented as long as it does what they want. No matter how cool or nice a new technology is, it won't necessarily win unless it brings noticeable value to the end user. In Android's case, the end user still typically doesn't care that the development behind Android is more open than it is behind iPhone. However, this difference in openness may ultimately help Android in the sense that more developers will be willing to build their ideas into viable applications on a more open system.


More on the Future of Java

A week ago, I posted a similar post to this one in which I referenced and discussed several posts from the blogosphere that were of particular interest to me. Many of these were related to discussions about the "future of Java." Just after posting that collection, I ran into the insightful post "Java Post Mortem with Gilad Bracha" that summarized two presentations by Bracha at JAX.de 2010. I like this post for a couple reasons. First, it is a nice summary and analysis of Bracha's main points. Second, I think the points are insightful. These include points such as "Java is going to stay but it is going to stay where you don’t want to look" and "Complicated is not a sign that you’re clever. It is a sign that you failed." This summary is well articulated and worth the small investment of time required to read it.

Joseph D. Darcy posted Project Coin: Multi-catch and final Rethrow, a post that looks at the exception handling improvements coming to JDK 7. Based on the comments on this post, the "final" portion seems the most confusing and controversial. Darcy's current (most recent post as of this writing) is Draft of Restarted "OpenJDK Developers' Guide" available for discussion and is specific to JDK 7 as well.

Jens Schauder's post The Question Isn't What is Going on at Oracle and Sun outlines some warning signs to watch for that indicate "that Java is turning into just another kind of COBOL." Schauder points out some ways to transition to other languages when it is time to actively move to languages other than Java if you have not done so already.

Back to Today's Java

Although reading about the future features of Java can be exciting, it is often more practical to learn about what we can do today and to learn from each others' experiences. Along these lines, I found the post How we solved – GC every 1 minute on Tomcat to be interesting. In this post, Sumit Pal discusses the non-standard -XX:+DisableExplicitGC option for the HotSpot JVM. The reader feedback is helpful and adds some background details as well. When I blogged that more developers should write blogs, this was the type of post I had in mind.

In Annotation or Not, the post's author enters the debate regarding when it is appropriate to use and not to use Java annotations. I think most of us welcome annotations to a certain degree and the main part of the controversy now seems to surround what is appropriate for annotations and what is not appropriate for annotations. As I discussed in the article Basic JPA Best Practices, I like how JPA allows you to use annotations but override them via external (XML) configuration as needed.


Software Development Career Development

There were two online resources this past week that I thought were particularly thought-provoking in the area of career development for software developers. In the post 10 Ways to Suck at Programming, Donnie Garvich documents ten things that "are really just things that every good programmer should already know to avoid." Among these ten things, a few of my favorites are "Never, ever remove functionality," "Document NOTHING," and "Catch all errors -- and do nothing with them." These and several others on his list were all too familiar for me (because of others' misbehaviors, of course). As with many of the best posts, the reader comments and feedback messages were also generally useful and interesting and included some additional items that could have made this list.

I have blogged before about my appreciation for posts that require the poster to sacrifice personal pride to provide a lesson from which we all benefit. This happened for me this week in the reddit programming post called I am now practically unemployable by everything I read. Any advice? Although this is somewhat anonymous (its author is unemployed58), it is still admirable that this author was willing to lay some personal career details out there. This post is a reminder that software developers need to stay current. It's a little frightening, though, that this author has stayed current to a degree, at least at the hobbyist level, but has still found himself unemployed for two years.

I often think developers waste a lot of time chasing fads because of dysfunctional motivators such as resume-driven development, the magpie effect, and so on, but this post is a reminder that there are problems on the other end (never doing anything new or different) as well. The post's author ends with, "I apologize for the rant just feeling a little frustrated today." I don't think there's any need for an apology. In fact, I appreciate the fact that this was posted and can be a reminder for all of us. Some of the feedback comments on this post are also useful in terms of ideas for the original poster that might work for all of us to reduce the chance of ending up in that situation and to deal with that if/when it does occur.

In Programmer Tip: Work Less, Stay Focused And Say No To Random Meaningless Slogging, Rajiv Popat points out the need for most developers to creatively solve problems in reasonable amounts of time rather than slogging away for 14 hour days (perhaps a dialect of presenteeism?).


Conclusion

I cannot come even close to reading all the content related to software development that comes out online each week that looks interesting to me. However, the resources that I referenced in this post are ones that managed to grab my attention amid the noise and bustle of the blogosphere and which I can wholeheartedly recommend for busy developers to invest time in reading if the covered topic is of personal interest.