Slides for many of the 2009 JavaOne technical sessions are now available for download via the Content Catalog. The username and password needed to download the slides are provided on this page as well.
Slides for many of the presentations are also available directly from many of the presenters. Examples of this include Monitoring and Troubleshooting Java Platform Applications with JDK Software, Project Coin (small Java SE 7 changes), and A RESTful Approach to Identity-based Web Services.
Monday, June 8, 2009
Saturday, June 6, 2009
Was 2009 JavaOne the Last?
In April, I wondered aloud if 2009 JavaOne would be the last edition of this conference. I could not, at that time, find another blog or article questioning the future of JavaOne in light of Oracle acquiring Sun, but I was (and still am) sure that many people were wondering about that. Since that time, other posts and articles have started appearing that also question whether this just-concluded 2009 JavaOne was the final edition.
Perhaps the most well-known publication questioning whether this was the last JavaOne is InfoWorld's Could Next Week's JavaOne be the Last? In that article, Paul Krill makes several interesting points including the observation that Moscone Center does not have 2010 JavaOne listed on its Events Calendar (though nothing is listed for June or July of 2010 at this point), the observation of the existence of dates for 2010 JavaOne (June 21-24, 2010) at the Technical Presentations site, and the opinions of select members of the Java community about the future of JavaOne.
In JavaOne 2009's Final Day: Parting Thoughts and Appreciations, java.net managing editor Kevin Farnham speculates on the possibility that Friday was the final day of JavaOne ever, but points out that other large Java-centric conferences will be held in the future.
Tim Bray wrote on day one of 2009 JavaOne and stated "here in the press room, the consensus is that this is JavaOne’s last go-around." Cay Horstmann, in covering the last day of 2009 JavaOne has a different personal conclusion: "My guess is that Oracle will not make any major changes in the near future, and that we will all meet again for Java One 2010 next year."
There are a couple reasons I think Oracle may not want to hold both JavaOne and Oracle OpenWorld every year. First, especially in the current economy, it is difficult to make money on conferences. There is significant evidence of this including the end of long-running SD Conferences and the end of the long-running Colorado Software Summit. Cay Horstmann's blog post for Day 0 of the 2009 JavaOne conference points out that JavaOne ended up offering "early bird" discounts "past the breaking point." Tom Foremski has written that Sun has been trying to get out of JavaOne due to the time and money investment. He argues that JavaOne is not needed anyway.
The second reason that Oracle may not want to continue JavaOne is that they already have many Java-related presentations at their own Oracle OpenWorld. It would not be difficult to expand the Java offerings, even if it meant expanding the conference by a day or two. The 2009 edition of this conference (to be held October 11-15 at the same Moscone Center that houses JavaOne) includes tracks such as Enterprise Java and Oracle WebLogic, Rich Enterprise Applications, and Service-Oriented Architecture.
Although few of us (except perhaps Larry Ellison) really know the future of JavaOne, there are some optimists regarding its future. Masood Mortazavi argues that the reason for JavaOne's existence is "common context." In Is this the Last JavaOne Ever?, Augusto Sellhorn states his reasons for believing this is not the last JavaOne and states: "I don’t think Oracle will 'deprecate' JavaOne." Larry Ellison's comments from the 2009 JavaOne keynote have also been construed as positive regarding the future of JavaOne.
In Swan Song for JavaOne? Better Not, Larry, several people's quotes are used to explain why Oracle should not combine JavaOne with the much larger Oracle OpenWorld (held three times per year in San Francisco, Japan, and Latin America). However, even as this article points out, many of these quoted individuals are asking Oracle to keep its own products in their own conference separate from JavaOne, a separation Sun rarely made for its own products and Java.
It will be interesting to see if there is another JavaOne. I previously thought that 2009 would be the last, then I thought for certain there would be more, and now I've moved back slightly to the guess that there will be a 2010 version, but I doubt that it will go many years past that (perhaps 2011 and 2012). Of course, it is all speculation and I could be wrong for years to come.
Perhaps the most well-known publication questioning whether this was the last JavaOne is InfoWorld's Could Next Week's JavaOne be the Last? In that article, Paul Krill makes several interesting points including the observation that Moscone Center does not have 2010 JavaOne listed on its Events Calendar (though nothing is listed for June or July of 2010 at this point), the observation of the existence of dates for 2010 JavaOne (June 21-24, 2010) at the Technical Presentations site, and the opinions of select members of the Java community about the future of JavaOne.
In JavaOne 2009's Final Day: Parting Thoughts and Appreciations, java.net managing editor Kevin Farnham speculates on the possibility that Friday was the final day of JavaOne ever, but points out that other large Java-centric conferences will be held in the future.
Tim Bray wrote on day one of 2009 JavaOne and stated "here in the press room, the consensus is that this is JavaOne’s last go-around." Cay Horstmann, in covering the last day of 2009 JavaOne has a different personal conclusion: "My guess is that Oracle will not make any major changes in the near future, and that we will all meet again for Java One 2010 next year."
There are a couple reasons I think Oracle may not want to hold both JavaOne and Oracle OpenWorld every year. First, especially in the current economy, it is difficult to make money on conferences. There is significant evidence of this including the end of long-running SD Conferences and the end of the long-running Colorado Software Summit. Cay Horstmann's blog post for Day 0 of the 2009 JavaOne conference points out that JavaOne ended up offering "early bird" discounts "past the breaking point." Tom Foremski has written that Sun has been trying to get out of JavaOne due to the time and money investment. He argues that JavaOne is not needed anyway.
The second reason that Oracle may not want to continue JavaOne is that they already have many Java-related presentations at their own Oracle OpenWorld. It would not be difficult to expand the Java offerings, even if it meant expanding the conference by a day or two. The 2009 edition of this conference (to be held October 11-15 at the same Moscone Center that houses JavaOne) includes tracks such as Enterprise Java and Oracle WebLogic, Rich Enterprise Applications, and Service-Oriented Architecture.
Although few of us (except perhaps Larry Ellison) really know the future of JavaOne, there are some optimists regarding its future. Masood Mortazavi argues that the reason for JavaOne's existence is "common context." In Is this the Last JavaOne Ever?, Augusto Sellhorn states his reasons for believing this is not the last JavaOne and states: "I don’t think Oracle will 'deprecate' JavaOne." Larry Ellison's comments from the 2009 JavaOne keynote have also been construed as positive regarding the future of JavaOne.
In Swan Song for JavaOne? Better Not, Larry, several people's quotes are used to explain why Oracle should not combine JavaOne with the much larger Oracle OpenWorld (held three times per year in San Francisco, Japan, and Latin America). However, even as this article points out, many of these quoted individuals are asking Oracle to keep its own products in their own conference separate from JavaOne, a separation Sun rarely made for its own products and Java.
It will be interesting to see if there is another JavaOne. I previously thought that 2009 would be the last, then I thought for certain there would be more, and now I've moved back slightly to the guess that there will be a 2010 version, but I doubt that it will go many years past that (perhaps 2011 and 2012). Of course, it is all speculation and I could be wrong for years to come.
Wednesday, June 3, 2009
Bing and Google: Searching for Technical Terms
I wondered how Microsoft's recently released and highly advertised Bing search engine would stack up against the renowned Google search engine for searching specifically for technical terms. I planned to try it out on some favorite terms and report here, but then I ran across a link from DZone to a blog posting that has already started down that road. In Bing Survives the Search Engine Achilles Heel: Programmers, Brandon Cannaday ("The Reddest") has beaten me to the punch.
The intention of this post is not to steal The Reddest's Thunder, but is to instead build upon what he has started and show a few of my representative Java-related queries in both the Bing search engine and the Google search engine. Like the Reddest, my past experience has been that no other search engine remotely matches Google for searching for technical terms and concepts.
The only time I have really used a search engine other than Google's is when 15-30 minutes of Googling has not found me the answer and I want a fresh (search engine) perspective. In fact, I like the Google search engine so much for searching for technical and personal things that the Google search engine main page is my home page on my Firefox browser and is the default browser in my Firefox search engine toolbar. Further evidence of my satisfaction in using the Google search engine as a development tool can be found in my blog post Day-to-Day Java Development Tools and Techniques.
Round #1: A Java Exception
What do the respective search engines provides when I query for "StackOverflowError"? The results with top returned queries from both browsers are shown next.
There are a few (I think interesting) observations here. First, Bing's first returned link is to the Sun-hosted Java SE 6 version of the Javadoc-generated API documentation for this Java error whereas Google's first-returned link is to the Sun-hosted J2SE 5 version of the Javadoc-generated API documentation. Because I work mostly with Java SE 6, I like Bing's giving me that version first. It's not difficult to get there myself, but it is a little more convenient.
The second interesting observation is that although I did not include "Java" in the search query, both favored Java. However, Bing seemed to favor Flex more by returning a link to Flex API documentation on the same-named error object. A third and related observation is that Google returned a Microsoft link related to stack overflow errors on Windows in the top several provided links and the Microsoft search engine did not.
Round One goes to Bing.
Round #2: Specialized Java Concept
For my next search results comparison, I try searching for "jmx connector versus adaptor" because this is a common beginning JMX user question (what is the difference between the two and because the spelling issue of adaptor versus adapter can make this one interesting). The screen snapshots of top results from both browsers for this query is shown next.
I try to be unbiased, but it is difficult for me not to give Google significant points and perhaps award them the entire contest for returning one of my blog posts as the first result for this query. However, if I'm forced to be honest, I have to admit that the page the Bing search returns is a very useful one. It is written by one of the members of the Sun JMX team (Daniel Fuchs), provides a nice introduction to Java Management Extensions, and definitely spells out the difference between a connector and an adapter in JMX. Still, I must admit to being a little hurt that my post specifically on the differences between a JMX connector and adaptor does not come up at all in Bing's first several pages worth of query results. That's going to cost them in my assessment. Round 2 goes to Google.
I don't show it here, but changing the "adaptor" to "adapter" is interesting. In Google, the first returned result is the JavaWorld-syndicated version of my same post returned first above. That one letter difference dramatically affects the top results of both search engines. This is evidence of something I've found with search engines; the key to a good search is often knowing the appropriate terms to search by, but we often don't know what those appropriate terms are when we're new to a subject.
Round #3: Not Quite Right Search Terms
For some reason, it seems tricky for many Java developers to remember if the operator known for its question mark and colon syntax is the ternary operator (which it is) or the tertiary operator (which it is apparently not). What happens in these two search engines if I search for "java tertiary operator"?
Bing seems to more closely literally match "tertiary" while Google seems to know that I really mean "ternary." In fact, Google's first returned result is explicitly on "ternary" with the second result using "tertiary." Sometimes I don't want the search engine trying to guess what I really want, but in this case it was beneficial. Round 3 goes to Google.
Round #4: Not Quite Right Search Terms Part 2
REST is very trendy in software development circles these days. What if I wanted to find out more about REST using these two search engines?
The first interesting observation here is that both Google and Bing return identical results for the first two: the Wikipedia REST entry and Building Web Services the REST Way. I was curious where Roy Fielding's PhD dissertation that started the whole REST phenomenon was in the respective search results. It was the 5th result on Google and 8th on Bing. The concept of REST the architectural style is obviously easily confused with the concept of rest. If I was looking for the latter, I'd actually prefer Bing's results because Google's initial page results are exclusively related to REST the architectural style. However, because I am comparing them in terms of technical terms searching, Google's emphasis on this is an advantage.
Two Key Areas Still to Explore
There are two things I use Google heavily for that tend to be unique to or at least more commonly associated with software development. First, I often use Google to search by an error message to find out how that particular problem was solved. Second, I often find myself needing to include some code syntax or syntax-like query term.
For the first item (querying by error message), my minimal comparisons of Google and Bing have so far shown them to return similar items (forums, online e-mail threads, etc.). I suspect I need to wait until my next real-life situation when I need to find an answer based on an unintuitive error message and try both browsers out then.
For the second item (needing to use syntax in the query), I have found that including operators generally is not helpful (operators are ignored or impact the search) with Google. For example including a minus before a word actually instructs Google to search for matches that explicitly do not include the term following the minus sign. Similarly, trying to search for discussions on Groovy's
I don't show the Bing results for the same three queries here because those results are largely the same as Google's.
Conclusion
From my admittedly small sample of tests, I still think Google comes out as the top search engine for software development searches (at least in the Java world and probably outside the .NET world in general). However, Bing has done itself proud in terms of jumping to second favorite search engine on my list ahead of Yahoo!'s search engine. When I need a different search engine's perspective for a particularly difficult to find concept, I will use Bing. While Google does a great job as a search engine, I still look forward to a day when developers can use their programming language's operators and get matches based on the actual use of those operators in source code. I dream big.
Google will remain the main page that comes up when my browser comes up, but Bing has certainly earned its spot on the search engine toolbar selector.
Related Resources
Bing Survives the Search Engines Achilles Heel: Programmers
FAQ: How to Add Some Bing to Your Browser
Bing Isn't All That
Bing: How Useful is Microsoft's New Search Offering?
Why Bing Sucks. Top 5 Reasons
Microsoft, You Got Binged
The intention of this post is not to steal The Reddest's Thunder, but is to instead build upon what he has started and show a few of my representative Java-related queries in both the Bing search engine and the Google search engine. Like the Reddest, my past experience has been that no other search engine remotely matches Google for searching for technical terms and concepts.
The only time I have really used a search engine other than Google's is when 15-30 minutes of Googling has not found me the answer and I want a fresh (search engine) perspective. In fact, I like the Google search engine so much for searching for technical and personal things that the Google search engine main page is my home page on my Firefox browser and is the default browser in my Firefox search engine toolbar. Further evidence of my satisfaction in using the Google search engine as a development tool can be found in my blog post Day-to-Day Java Development Tools and Techniques.
Round #1: A Java Exception
What do the respective search engines provides when I query for "StackOverflowError"? The results with top returned queries from both browsers are shown next.
There are a few (I think interesting) observations here. First, Bing's first returned link is to the Sun-hosted Java SE 6 version of the Javadoc-generated API documentation for this Java error whereas Google's first-returned link is to the Sun-hosted J2SE 5 version of the Javadoc-generated API documentation. Because I work mostly with Java SE 6, I like Bing's giving me that version first. It's not difficult to get there myself, but it is a little more convenient.
The second interesting observation is that although I did not include "Java" in the search query, both favored Java. However, Bing seemed to favor Flex more by returning a link to Flex API documentation on the same-named error object. A third and related observation is that Google returned a Microsoft link related to stack overflow errors on Windows in the top several provided links and the Microsoft search engine did not.
Round One goes to Bing.
Round #2: Specialized Java Concept
For my next search results comparison, I try searching for "jmx connector versus adaptor" because this is a common beginning JMX user question (what is the difference between the two and because the spelling issue of adaptor versus adapter can make this one interesting). The screen snapshots of top results from both browsers for this query is shown next.
I try to be unbiased, but it is difficult for me not to give Google significant points and perhaps award them the entire contest for returning one of my blog posts as the first result for this query. However, if I'm forced to be honest, I have to admit that the page the Bing search returns is a very useful one. It is written by one of the members of the Sun JMX team (Daniel Fuchs), provides a nice introduction to Java Management Extensions, and definitely spells out the difference between a connector and an adapter in JMX. Still, I must admit to being a little hurt that my post specifically on the differences between a JMX connector and adaptor does not come up at all in Bing's first several pages worth of query results. That's going to cost them in my assessment. Round 2 goes to Google.
I don't show it here, but changing the "adaptor" to "adapter" is interesting. In Google, the first returned result is the JavaWorld-syndicated version of my same post returned first above. That one letter difference dramatically affects the top results of both search engines. This is evidence of something I've found with search engines; the key to a good search is often knowing the appropriate terms to search by, but we often don't know what those appropriate terms are when we're new to a subject.
Round #3: Not Quite Right Search Terms
For some reason, it seems tricky for many Java developers to remember if the operator known for its question mark and colon syntax is the ternary operator (which it is) or the tertiary operator (which it is apparently not). What happens in these two search engines if I search for "java tertiary operator"?
Bing seems to more closely literally match "tertiary" while Google seems to know that I really mean "ternary." In fact, Google's first returned result is explicitly on "ternary" with the second result using "tertiary." Sometimes I don't want the search engine trying to guess what I really want, but in this case it was beneficial. Round 3 goes to Google.
Round #4: Not Quite Right Search Terms Part 2
REST is very trendy in software development circles these days. What if I wanted to find out more about REST using these two search engines?
The first interesting observation here is that both Google and Bing return identical results for the first two: the Wikipedia REST entry and Building Web Services the REST Way. I was curious where Roy Fielding's PhD dissertation that started the whole REST phenomenon was in the respective search results. It was the 5th result on Google and 8th on Bing. The concept of REST the architectural style is obviously easily confused with the concept of rest. If I was looking for the latter, I'd actually prefer Bing's results because Google's initial page results are exclusively related to REST the architectural style. However, because I am comparing them in terms of technical terms searching, Google's emphasis on this is an advantage.
Two Key Areas Still to Explore
There are two things I use Google heavily for that tend to be unique to or at least more commonly associated with software development. First, I often use Google to search by an error message to find out how that particular problem was solved. Second, I often find myself needing to include some code syntax or syntax-like query term.
For the first item (querying by error message), my minimal comparisons of Google and Bing have so far shown them to return similar items (forums, online e-mail threads, etc.). I suspect I need to wait until my next real-life situation when I need to find an answer based on an unintuitive error message and try both browsers out then.
For the second item (needing to use syntax in the query), I have found that including operators generally is not helpful (operators are ignored or impact the search) with Google. For example including a minus before a word actually instructs Google to search for matches that explicitly do not include the term following the minus sign. Similarly, trying to search for discussions on Groovy's
?. operator with the phrase "?." are unhelpful. The following three snapshots of Google search engine results for querying on "?.", "?. groovy", and "?. groovy null checking" show that the operator itself doesn't really help and that its the use of "extra" knowledge that the operator has to do with Groovy and with null checking that makes the search successful. When I'm searching something entirely new to me, this extra knowledge may be exactly what I don't have.
I don't show the Bing results for the same three queries here because those results are largely the same as Google's.
Conclusion
From my admittedly small sample of tests, I still think Google comes out as the top search engine for software development searches (at least in the Java world and probably outside the .NET world in general). However, Bing has done itself proud in terms of jumping to second favorite search engine on my list ahead of Yahoo!'s search engine. When I need a different search engine's perspective for a particularly difficult to find concept, I will use Bing. While Google does a great job as a search engine, I still look forward to a day when developers can use their programming language's operators and get matches based on the actual use of those operators in source code. I dream big.
Google will remain the main page that comes up when my browser comes up, but Bing has certainly earned its spot on the search engine toolbar selector.
Related Resources
Bing Survives the Search Engines Achilles Heel: Programmers
FAQ: How to Add Some Bing to Your Browser
Bing Isn't All That
Bing: How Useful is Microsoft's New Search Offering?
Why Bing Sucks. Top 5 Reasons
Microsoft, You Got Binged
No More Colorado Software Summit: The End of an Era
I was saddened and disappointed to learn earlier this week that Colorado Software Summit 2009 has been canceled with no plans for resuming the conference in future years. There had been 17 annual versions of this conference (though under a different name/focus in the early years), but the magnitude of these troubled economic times is evident in the cancellation of this year's conference.
Wayne and Peggy have always held a classy conference and even this cancellation has been done in the classiest way possible. Their main page deals with the cancellation with candor, emotion, and a touch of humor. The e-mail message they sent out to scheduled speakers for this canceled conference was similarly thoughtful and candid. In another class act, they provide a link to all presentations from Colorado Software Summit 2008, all of which have now been posted (including my presentations "Applying Flash to Java: Flex and OpenLaszlo" and "Java Management Extensions (JMX) Circa 2008").
In the four years I had the good fortune to attend this conference (and that is not many opportunities compared to many of their regular attendees), I was exposed to many technologies that would benefit me in the short-term and in the long-term and I was able to see famous "celebrities" of the software development world such as Bruce Eckel and Tim Bray in a relatively small venue.
The Colorado Software Summit offered several unique features and benefits that I have not seen elsewhere. These included the offering of each 90-minute presentation three times during the conference so that you were virtually assured you could see your "top ten" every time (and usually could see many more than that such as top 15). Another feature that was unique, at least for me, is that this is the only conference that I attended where I thought the keynotes were competitive with the regular technical sessions in terms of interest and value to me. Keynotes at many conferences are mildly interesting to me or even useless, but the CSS ones were always thought-provoking and worthwhile. Other relatively unique features included the awesome food, the awesome beauty of Keystone, and the large international contingency for such a small overall attendance target.
It was very disappointing to read Wayne's e-mail message to speakers earlier this week, but I think the disappointment and regret will be renewed and intensified in late October when I am feeling like I should be at the Colorado Software Summit. I have half-joked with colleagues that I'm going to take off work that week anyway and just hang out in Keystone. As much fun as that sounds, it still won't be the same as being in Keystone and being immersed in development topics until the brain cannot take anymore at the same time.
I realize that all good things must come to an end, but that doesn't make it any easier to say goodbye now.
Wayne and Peggy have always held a classy conference and even this cancellation has been done in the classiest way possible. Their main page deals with the cancellation with candor, emotion, and a touch of humor. The e-mail message they sent out to scheduled speakers for this canceled conference was similarly thoughtful and candid. In another class act, they provide a link to all presentations from Colorado Software Summit 2008, all of which have now been posted (including my presentations "Applying Flash to Java: Flex and OpenLaszlo" and "Java Management Extensions (JMX) Circa 2008").
In the four years I had the good fortune to attend this conference (and that is not many opportunities compared to many of their regular attendees), I was exposed to many technologies that would benefit me in the short-term and in the long-term and I was able to see famous "celebrities" of the software development world such as Bruce Eckel and Tim Bray in a relatively small venue.
The Colorado Software Summit offered several unique features and benefits that I have not seen elsewhere. These included the offering of each 90-minute presentation three times during the conference so that you were virtually assured you could see your "top ten" every time (and usually could see many more than that such as top 15). Another feature that was unique, at least for me, is that this is the only conference that I attended where I thought the keynotes were competitive with the regular technical sessions in terms of interest and value to me. Keynotes at many conferences are mildly interesting to me or even useless, but the CSS ones were always thought-provoking and worthwhile. Other relatively unique features included the awesome food, the awesome beauty of Keystone, and the large international contingency for such a small overall attendance target.
It was very disappointing to read Wayne's e-mail message to speakers earlier this week, but I think the disappointment and regret will be renewed and intensified in late October when I am feeling like I should be at the Colorado Software Summit. I have half-joked with colleagues that I'm going to take off work that week anyway and just hang out in Keystone. As much fun as that sounds, it still won't be the same as being in Keystone and being immersed in development topics until the brain cannot take anymore at the same time.
I realize that all good things must come to an end, but that doesn't make it any easier to say goodbye now.
Tuesday, June 2, 2009
Questions Answered: First Day of 2009 JavaOne
I have previously blogged on questions about the effect of Oracle's acquisition of Sun on JavaOne. In that same blog posting, I also postulated that JavaOne might answer some of the questions and publicly wondered if this would be the last JavaOne. Accounts coming in from the first day of 2009 JavaOne attendees suggest that this is NOT the last JavaOne and begin to answer some of the questions about the future of Java.
Thanks to the prevalence of blogging, even those of us not fortunate enough to attend JavaOne can get a pretty good idea of the highlights of the conference by piecing together a composite of blog posts. In this post, I'll summarize some of the common themes covered in blogs today related to JavaOne announcements.
The Future of JavaFX
Because JavaFX has, up until now, seemed to be largely a Sun-centric concept and because Oracle has seemed to favor JavaServer Faces, it is natural to wonder about the future of JavaFX. JavaFX has been heavily promoted and emphasized at the last two JavaOne conferences, so it is perhaps not surprising that this was again heavily addressed today at JavaOne.
Several attendees have reported Larry Ellison, head of Oracle, addressing the future of JavaFX. In Ellison Pits Sun and Oracle Against Ajax and Google, Gavin Clarke writes that Ellison stated that JavaFX will be used to compete with Microsoft and Google. In the post JavaOne Tuesday Morning General Session, Alex Miller writes about "time for JavaFX pumping" and also mentions Ellison's interest in using JavaFX with OpenOffice and mobile devices.
The Future of NetBeans
Although NetBeans appears to not have been mentioned as prominently as JavaFX today, the previously mentioned article Ellison Pits Sun and Oracle Against Ajax and Google points out that Oracle has tended to favor its own JDeveloper IDE and the Eclipse IDE in the past over NetBeans. With NetBeans being the dominant IDE for JavaFX development, it means that Oracle has some work ahead of it.
It is difficult to know what this means exactly for NetBeans because there are still many possibilities. Oracle could take some of the best features of NetBeans, including its JavaFX support, and put them into JDeveloper and/or Eclipse. Another option would be to continue supporting NetBeans, though it is difficult to imagine Oracle wanting to support directly and indirectly three disparate Java IDEs. Finally, Oracle could move from JDeveloper and/or Eclipse to NetBeans, though I don't see this as very likely either.
The Future of Java
I have no doubt that Oracle will be a big supporter of Java. Long before purchasing Sun, Oracle has committed heavily to Java by dedicating several of its major products (Fusion, JDeveloper, OC4J) on Java, by maintaining a large set of Java online resources at Oracle Technology Network's (OTN) Java Developer Center, and by providing tuition-based and free training on Java-related products and technologies.
OTN Editor-in-Chief Justin Kestelyn cites an Ellison quote that reiterates my belief about Oracle's future treatment of Java: "(Oracle) has invested more than anybody else in Java technology in terms of dollars over the years, and we intend to invest -- and accelerate our investments -- going forward." In JavaOne General Session Live Update, Kirk Knoernschild quotes Ellison, "Aside from our database, all of our products are Java based."
Another natural question is how Oracle might treat Java differently now that it has a new role related to Java. Again quoting from Justin Kestelyn's blog post Larry Ellison on the Future of Java: "I don't expect a lot of changes, just expanded investment and a lot of enthusiasm coming from Oracle. ... Look at the past to see the future."
In JavaOne 2009 - Opening and General Session - First Glimpse of Oracle-Sun, Lucas Jellema records some of the same Ellison comments already covered here and adds another quote: "We will do more of the same, no large changes, more investment and enthousiasm coming in from Oracle." Jellema's own interpretation is that "the appearance of Larry Ellison in the general session seemed primarily targeted at assuaging the fear, uncertainty and doubt in the community." I wasn't there, but the many quotations seem to suggest this.
The Future of JavaOne
With Oracle already holding a huge conference in Oracle OpenWorld, there was reason to wonder if JavaOne had a future. According to Lucas Jellema's previously cited blog post, there will be future JavaOne conferences. Of course, I am sure everyone understands that there will be additional emphasis on Oracle products in future versions.
Other Blog Posts of Interest
There were several other blogs posts and articles that discussed this opening session. Tim Bray writes in JavaOne 2009 Notes I that Ellison's "cameo appearance was mostly a Java love-fest" and remarked on Ellison's "extended plug for JavaFX." Burk Hufnagel writes about the opening session and Ellison's comments on Oracle and Java/JavaFX in the DZone/JavaLobby post JavaOne 2009: Day 1: The Beginning.
David Herron's blog post JavaOne 2009 Opening Keynote talks about some of the exciting portions of the keynote, but also covers David's concerns about Sun's and Oracle's open and community treatment of the JDK and related products. He also points out some obstacles to using JavaFX with OpenOffice.
Conclusion
Larry Ellison does seem to have made an effort to assure Java stakeholders that they have nothing to fear. Although there is always the possibility that plans will change or that we're not being told what is actually being planned (perhaps for competitive reasons), I do think it is nice to hear some reassuring words about the future of Java under Oracle.
Thanks to the prevalence of blogging, even those of us not fortunate enough to attend JavaOne can get a pretty good idea of the highlights of the conference by piecing together a composite of blog posts. In this post, I'll summarize some of the common themes covered in blogs today related to JavaOne announcements.
The Future of JavaFX
Because JavaFX has, up until now, seemed to be largely a Sun-centric concept and because Oracle has seemed to favor JavaServer Faces, it is natural to wonder about the future of JavaFX. JavaFX has been heavily promoted and emphasized at the last two JavaOne conferences, so it is perhaps not surprising that this was again heavily addressed today at JavaOne.
Several attendees have reported Larry Ellison, head of Oracle, addressing the future of JavaFX. In Ellison Pits Sun and Oracle Against Ajax and Google, Gavin Clarke writes that Ellison stated that JavaFX will be used to compete with Microsoft and Google. In the post JavaOne Tuesday Morning General Session, Alex Miller writes about "time for JavaFX pumping" and also mentions Ellison's interest in using JavaFX with OpenOffice and mobile devices.
The Future of NetBeans
Although NetBeans appears to not have been mentioned as prominently as JavaFX today, the previously mentioned article Ellison Pits Sun and Oracle Against Ajax and Google points out that Oracle has tended to favor its own JDeveloper IDE and the Eclipse IDE in the past over NetBeans. With NetBeans being the dominant IDE for JavaFX development, it means that Oracle has some work ahead of it.
It is difficult to know what this means exactly for NetBeans because there are still many possibilities. Oracle could take some of the best features of NetBeans, including its JavaFX support, and put them into JDeveloper and/or Eclipse. Another option would be to continue supporting NetBeans, though it is difficult to imagine Oracle wanting to support directly and indirectly three disparate Java IDEs. Finally, Oracle could move from JDeveloper and/or Eclipse to NetBeans, though I don't see this as very likely either.
The Future of Java
I have no doubt that Oracle will be a big supporter of Java. Long before purchasing Sun, Oracle has committed heavily to Java by dedicating several of its major products (Fusion, JDeveloper, OC4J) on Java, by maintaining a large set of Java online resources at Oracle Technology Network's (OTN) Java Developer Center, and by providing tuition-based and free training on Java-related products and technologies.
OTN Editor-in-Chief Justin Kestelyn cites an Ellison quote that reiterates my belief about Oracle's future treatment of Java: "(Oracle) has invested more than anybody else in Java technology in terms of dollars over the years, and we intend to invest -- and accelerate our investments -- going forward." In JavaOne General Session Live Update, Kirk Knoernschild quotes Ellison, "Aside from our database, all of our products are Java based."
Another natural question is how Oracle might treat Java differently now that it has a new role related to Java. Again quoting from Justin Kestelyn's blog post Larry Ellison on the Future of Java: "I don't expect a lot of changes, just expanded investment and a lot of enthusiasm coming from Oracle. ... Look at the past to see the future."
In JavaOne 2009 - Opening and General Session - First Glimpse of Oracle-Sun, Lucas Jellema records some of the same Ellison comments already covered here and adds another quote: "We will do more of the same, no large changes, more investment and enthousiasm coming in from Oracle." Jellema's own interpretation is that "the appearance of Larry Ellison in the general session seemed primarily targeted at assuaging the fear, uncertainty and doubt in the community." I wasn't there, but the many quotations seem to suggest this.
The Future of JavaOne
With Oracle already holding a huge conference in Oracle OpenWorld, there was reason to wonder if JavaOne had a future. According to Lucas Jellema's previously cited blog post, there will be future JavaOne conferences. Of course, I am sure everyone understands that there will be additional emphasis on Oracle products in future versions.
Other Blog Posts of Interest
There were several other blogs posts and articles that discussed this opening session. Tim Bray writes in JavaOne 2009 Notes I that Ellison's "cameo appearance was mostly a Java love-fest" and remarked on Ellison's "extended plug for JavaFX." Burk Hufnagel writes about the opening session and Ellison's comments on Oracle and Java/JavaFX in the DZone/JavaLobby post JavaOne 2009: Day 1: The Beginning.
David Herron's blog post JavaOne 2009 Opening Keynote talks about some of the exciting portions of the keynote, but also covers David's concerns about Sun's and Oracle's open and community treatment of the JDK and related products. He also points out some obstacles to using JavaFX with OpenOffice.
Conclusion
Larry Ellison does seem to have made an effort to assure Java stakeholders that they have nothing to fear. Although there is always the possibility that plans will change or that we're not being told what is actually being planned (perhaps for competitive reasons), I do think it is nice to hear some reassuring words about the future of Java under Oracle.
Monday, June 1, 2009
RESTful Database Access with sqlREST
The sqlREST project enables easier exposure of database data via REST-style web services. The 15-Minute Guide to sqlREST demonstrates how to quickly try out sqlREST simply by copying the sqlREST directory into a Java EE web server's directory and sqlREST-provided database. In this blog posting, I will demonstrate use of sqlREST with GlassFish and an independent database (Oracle HR schema).
sqlREST 1.0 can be downloaded here. The file is currently called sqlrest-1.0.zip and is approximately 1.5 MB in size. For my example, I unzipped the contents of this ZIP file into a directory called
By the way, the
The 15-Minute Guide describes copying sqlREST files into your favorite Java EE web container's web application directory. This is often the easiest way to include a library or framework, but I like to build JARs and include them in my own WAR file's
dustin-build.xml
I named this Ant build file
I now have a JAR containing sqlREST classes that can be easily deployed with any WAR.
The sqlREST User Guide does not have much in it currently, but it does have a section called "Using a different database" that explains how one can expose one's own database REST-style with sqlREST. This section demonstrates that it is very simple to use a custom database with sqlREST.
To use a custom database, one edits the
The following code snippet shows what this file looks like after I have edited it to use with an instance of the Oracle database.
sqlrestconf.xml
The configuration file above references the OracleDataSource class. I need to ensure that this class is available to my web server. To do this, I'll add it to the WAR file that will contain the JAR of sqlREST classes along with the sqlREST-provided
The revised Ant build file builds the WAR with these constituent pieces. The new version is shown next.
dustin-build.xml (revised to build WAR)
This build file leads to the successful assembly of the WAR file as shown in the next screen snapshot.
I don't show it here, but with this EAR built I can deploy it to my Java EE web container of choice. In my case, I have deployed it to GlassFish. By default, GlassFish names the web context based on the name of the deployed WAR, so it is "usingSqlRest" in this case. This means that "usingSqlRest" will be part of the URL used to access the data via sqlREST.
If I neglect to place the Oracle driver class in the WAR's classpath, the browser returns an empty XML element
Once the Oracle JDBC driver class is made available on the classpath, I can see the representations of various resources by including the appropriate table name in the URL. The next two screen snapshots show this for the EMPLOYEES and COUNTRIES tables in the HR schema.
At this point, with only editing of the
Unfortunately, I have run into some issues using sqlREST with the Oracle database HR schema. First, I was not able to access the sqlREST root URL (
A second problem I ran into occurred when trying to GET a particular resource. This is shown in the next screen snapshot which indicates my attempt to access a specific employee.
In the appropriate GlassFish log, the top part of the associated stack trace looks like this:
I really like the sqlREST concept and I believe that it has a lot of potential. The 15-Minute Guide shows its used with the bundled Hypersonic SQL database and it is likely that it works to differing degrees with various other relational databases with appropriate JDBC drivers. Because sqlREST is open source (BSD license), one could edit the code to address issues specific to an alternative database.
Dustin
sqlREST 1.0 can be downloaded here. The file is currently called sqlrest-1.0.zip and is approximately 1.5 MB in size. For my example, I unzipped the contents of this ZIP file into a directory called
C:\sqlrest-1.0. The next screen snapshot shows what the most important directory in this distribution (the WEB-INF/classes directory) looks like.
By the way, the
docs directory includes versions of the previously mentioned 15-Minute Guide to sqlREST as well as the sqlREST Users Guide, the sqlREST Developer Guide (just barely started at this point), and the sqlREST Javadoc-based API documentation.The 15-Minute Guide describes copying sqlREST files into your favorite Java EE web container's web application directory. This is often the easiest way to include a library or framework, but I like to build JARs and include them in my own WAR file's
WEB-INF/lib directory. In order to do this, I need the sqlREST-provided .class files assembled into a JAR file. The following Ant build file instructs Ant to do just that.dustin-build.xml
<?xml version="1.0" encoding="UTF-8"?>
<project name="Building sqlREST Example" default="jar" basedir=".">
<description>Building sqlREST Example</description>
<property name="dist.dir" value="dustin-dist" />
<property name="classes.dir" value="webapps/sqlrest/WEB-INF/classes" />
<property name="jar.name" value="sqlrest10.jar" />
<property name="jar.filesonly" value="true" />
<target name="-init">
<!-- Don't need to create a classes directory because it was part of
sqlrest download and included the .class files. -->
<mkdir dir="${dist.dir}" />
</target>
<target name="jar"
description="Package sqlREST compiled classes into JAR file"
depends="-init">
<jar destfile="${dist.dir}/${jar.name}"
basedir="${classes.dir}"
filesonly="${jar.filesonly}">
</jar>
</target>
<target name="clean" description="Remove generated artifacts.">
<!-- Don't clean classes directory because these .class files were
downloaded rather than built. -->
<delete dir="${dist.dir}" />
</target>
</project>
I named this Ant build file
dustin-build.xml to make it obvious that it is not part of the sqlREST distribution and is for my own use. To run it with Ant, I simply run the command ant -f dustin-build.xml and a directory called dustin-dist is created and a JAR file named sqlrest10.jar is placed in that newly created directory. The next screen snapshot shows that this JAR was created successfully.
I now have a JAR containing sqlREST classes that can be easily deployed with any WAR.
The sqlREST User Guide does not have much in it currently, but it does have a section called "Using a different database" that explains how one can expose one's own database REST-style with sqlREST. This section demonstrates that it is very simple to use a custom database with sqlREST.
To use a custom database, one edits the
sqlrestconf.xml configuration file. In my case, this is located in the WEB-INF directory of the expanded contents of the downloaded sqlrest-1.0.zip file.The following code snippet shows what this file looks like after I have edited it to use with an instance of the Oracle database.
sqlrestconf.xml
<?xml version="1.0" encoding="UTF-8"?>
<sqlrestconf>
<database>
<jdbc-driver-class>oracle.jdbc.pool.OracleDataSource</jdbc-driver-class>
<database-url>jdbc:oracle:thin:@localhost:1521:orcl</database-url>
<user>hr</user>
<password>hr</password>
</database>
</sqlrestconf>
The configuration file above references the OracleDataSource class. I need to ensure that this class is available to my web server. To do this, I'll add it to the WAR file that will contain the JAR of sqlREST classes along with the sqlREST-provided
web.xml file and the just-discussed sqlrestconf.xml configuration file.The revised Ant build file builds the WAR with these constituent pieces. The new version is shown next.
dustin-build.xml (revised to build WAR)
<?xml version="1.0" encoding="UTF-8"?>
<project name="Building sqlREST Example" default="war" basedir=".">
<description>Building sqlREST Example</description>
<property name="dist.dir" value="dustin-dist" />
<property name="classes.dir" value="webapps/sqlrest/WEB-INF/classes" />
<property name="jar.name" value="sqlrest10.jar" />
<property name="jar.filesonly" value="true" />
<property name="war.name" value="usingSqlRest.war" />
<target name="-init">
<!-- Don't need to create a classes directory because it was part of
sqlrest download and included the .class files. -->
<mkdir dir="${dist.dir}" />
</target>
<target name="jar"
description="Package sqlREST compiled classes into JAR file"
depends="-init">
<jar destfile="${dist.dir}/${jar.name}"
basedir="${classes.dir}"
filesonly="${jar.filesonly}">
</jar>
</target>
<target name="war"
description="Generate a WAR file that includes sqlREST"
depends="jar">
<war destfile="${dist.dir}/${war.name}"
webxml="webapps/sqlrest/WEB-INF/web.xml"
filesonly="${jar.filesonly}">
<lib dir="${dist.dir}" includes="${jar.name}" />
<lib dir="webapps/sqlrest/WEB-INF/lib" includes="log4j-1.2.8.jar" />
<lib dir="C:\app\Dustin\product\11.1.0\db_1\jdbc\lib"
includes="ojdbc6.jar" />
<zipfileset dir="webapps/sqlrest" includes="WEB-INF/sqlrestconf.xml" />
</war>
</target>
<target name="clean" description="Remove generated artifacts.">
<!-- Don't clean classes directory because these .class files were
downloaded rather than built. -->
<delete dir="${dist.dir}" />
</target>
</project>
This build file leads to the successful assembly of the WAR file as shown in the next screen snapshot.
I don't show it here, but with this EAR built I can deploy it to my Java EE web container of choice. In my case, I have deployed it to GlassFish. By default, GlassFish names the web context based on the name of the deployed WAR, so it is "usingSqlRest" in this case. This means that "usingSqlRest" will be part of the URL used to access the data via sqlREST.
If I neglect to place the Oracle driver class in the WAR's classpath, the browser returns an empty XML element
<resource> as shown in the next screen snapshot.
Once the Oracle JDBC driver class is made available on the classpath, I can see the representations of various resources by including the appropriate table name in the URL. The next two screen snapshots show this for the EMPLOYEES and COUNTRIES tables in the HR schema.
At this point, with only editing of the
sqlrestconf.xml file and placing of appropriate sqlREST and database JDBC driver classes on the web server, we are able to get REST-style representations of our underlying database. The sqlREST product obviously uses the database's metadata to achieve this functionality.Unfortunately, I have run into some issues using sqlREST with the Oracle database HR schema. First, I was not able to access the sqlREST root URL (
http://localhost:8080/usingSqlRest/ in this case) to see available resources. The reason for this is that the Oracle metadata includes names with dollar sign in them and that causes havoc for the XML parser. This is shown in the next screen snapshot.
A second problem I ran into occurred when trying to GET a particular resource. This is shown in the next screen snapshot which indicates my attempt to access a specific employee.
In the appropriate GlassFish log, the top part of the associated stack trace looks like this:
java.lang.NullPointerException
at de.oio.sqlrest.xml.TableDetailResponseBuilder.generate(TableDetailResponseBuilder.java:88)
at de.oio.sqlrest.Dispatcher.dispatchGET(Dispatcher.java:76)
at de.oio.sqlrest.MainServlet.doGet(MainServlet.java:73)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:718)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
at org.apache.catalina.core.ApplicationFilterChain.servletService
I really like the sqlREST concept and I believe that it has a lot of potential. The 15-Minute Guide shows its used with the bundled Hypersonic SQL database and it is likely that it works to differing degrees with various other relational databases with appropriate JDBC drivers. Because sqlREST is open source (BSD license), one could edit the code to address issues specific to an alternative database.
Dustin
Code Beauty is in the Eye of the Beholder
The phrase beauty is in the eye of the beholder is often used to describe the wide variety of peoples' opinions of what is beautiful. Although this phrase is commonly used in describing different perceptions on the appearance of a particular person, it definitely fits the concept of beautiful code. In this blog posting, I'll look at how some of the subtleties surrounding the rather subjective measurement of human beauty apply to the equally subjective measurement of code beauty.
It is nearly impossible to quantify whether a given individual is beautiful or not for a wide variety of reasons. Does "beautiful" refer only to physical appearance or does it include personality, intelligence, communication skills, social graces, and so forth? Is beauty an absolute or is it more relative (rather than saying someone is beautiful and someone else is not beautiful, is it easier to say the first someone is more beautiful than the next someone)? The aspects of a person's appearance that are important to one person's perception of beauty may not be as important to another person's perception of beauty. All of these considerations impact our ability to gauge code beauty as well.
The Beauty Spectrum
When it comes to deciding whether a person is beautiful or not, there seems to be a spectrum of people. On one end, there are individuals who nearly everyone would agree are beautiful. For example, I don't think many people disagreed when Michelle Pfeiffer was named one of the 50 most beautiful people in the 1990 People Magazine edition. On the other end, there are a few individuals who almost nobody would argue are beautiful. Most people are somewhere in between where there is a split of opinion on whether or not they are beautiful.
Code beauty works in the same way. There are some samples of code that nearly every developer would agree are beautiful (as far as code goes), there are samples of code that developers would nearly unanimously agree are anything but beautiful, and there is a lot of code in between in which developers will disagree on whether that code is beautiful or not. Because so much code falls somewhere on the spectrum other than the extremes (obvious beauty or obvious ugliness), it can be difficult to get agreement on what constitutes code beauty in these cases.
I see examples of this disagreement about code beauty on almost a daily basis. I find myself increasingly fond of less code and approaches such as Java's ternary operator. I see beauty in conciseness. However, I know several experienced Java developers that loath the ternary operator. I noticed in the JRuby Code Conventions that there is an emphatic note: "Do not, never, I repeat, never, use something like 'if (expr == true)'." Although I generally agree with this, I know people who honestly prefer the explicit true or false comparison.
Then of course, as one of many other examples, there is the whole issue of where to place the curly braces (or even if we should have curly braces at all). There is also the debate over level of commenting. Some think no comments make the most beautiful code, others think very verbose commenting is gorgeous, and many others are somewhere in between. For me, I like concise code, significant white space, carefully chosen comments, highly descriptive method names, and so forth. However, I know many respected developers who have differences of opinion on each of these attributes of code beauty.
Even my own sense of code beauty has changed over the years. When I first read about the enhanced for loop that was anticipated for J2SE 5, I did not particularly like how the code looked. However, it has grown on me and I really, really like the conciseness of that loop and wish that it could be used for an even wider set of iterations. Similarly, I used to be one of those who detested the ternary operator, though I deeply appreciate it in the right context now.
With so many different ideas of what is beautiful and even our own changing ideas of what is beautiful, it is difficult to classify many pieces of code as beautiful or not beautiful in any absolute sense of the word.
Code Beauty is More than Skin Deep?
When I was in high school, my mom and I had very different ideas of what made a girl beautiful. I nearly completely focused on physical looks while my mom was more interested in trying to get me interested in girls who had more than just good looks. I have since learned that beauty really is more than just the outside appearance (although it still includes it along with the other aspects).
Code works the same way. The best code cannot make up for poor design. In fact, many argue that "beautiful code" really does not pertain to the superficial appearance of code and instead really references deeper things like good design, loose coupling, modularity, and so forth. One of the several authors of Beautiful Code has also pointed out (related to recursion specifically) that beautiful code can sometimes actually be less efficient or even not work as well as less beautiful code. Jonathan Edwards has pointed out something that I have experienced myself: like physical beauty, code/design beauty is often marred by life as realities, compromises, and special cases creep in.
Can Code Really Be Beautiful?
In Code Isn't Beautiful, Jeff Atwood argues that code is not beautiful. He has a point. It is difficult to argue that code can be "beautiful" in the same sense as a sunset, a snow-covered mountain top, an ocean or beach, a tropical paradise, and so forth.
As discussed in the spectrum topic above, I definitely believe that some code is more beautiful than other code. However, I try not to get too worked up about striving for "beauty" at all costs because working and useful code can only be beautiful to a point. Code is not only about art and beauty; it is also about functionality.
Conclusion
Proponents of certain languages or frameworks will often tout the beauty of that language or framework. Unless there is significant explanation of why and what is so beautiful about it, I generally dismiss these types of statements as irrelevant. Without further explanation, to say "that particular code is beautiful" is akin to saying "I personally think that particular code is beautiful." That's fine, but that doesn't mean that others, including those who will be maintaining that code, feel the same way. After all, code beauty, like all types of beauty, is in the eye of the beholder.
It is nearly impossible to quantify whether a given individual is beautiful or not for a wide variety of reasons. Does "beautiful" refer only to physical appearance or does it include personality, intelligence, communication skills, social graces, and so forth? Is beauty an absolute or is it more relative (rather than saying someone is beautiful and someone else is not beautiful, is it easier to say the first someone is more beautiful than the next someone)? The aspects of a person's appearance that are important to one person's perception of beauty may not be as important to another person's perception of beauty. All of these considerations impact our ability to gauge code beauty as well.
The Beauty Spectrum
When it comes to deciding whether a person is beautiful or not, there seems to be a spectrum of people. On one end, there are individuals who nearly everyone would agree are beautiful. For example, I don't think many people disagreed when Michelle Pfeiffer was named one of the 50 most beautiful people in the 1990 People Magazine edition. On the other end, there are a few individuals who almost nobody would argue are beautiful. Most people are somewhere in between where there is a split of opinion on whether or not they are beautiful.
Code beauty works in the same way. There are some samples of code that nearly every developer would agree are beautiful (as far as code goes), there are samples of code that developers would nearly unanimously agree are anything but beautiful, and there is a lot of code in between in which developers will disagree on whether that code is beautiful or not. Because so much code falls somewhere on the spectrum other than the extremes (obvious beauty or obvious ugliness), it can be difficult to get agreement on what constitutes code beauty in these cases.
I see examples of this disagreement about code beauty on almost a daily basis. I find myself increasingly fond of less code and approaches such as Java's ternary operator. I see beauty in conciseness. However, I know several experienced Java developers that loath the ternary operator. I noticed in the JRuby Code Conventions that there is an emphatic note: "Do not, never, I repeat, never, use something like 'if (expr == true)'." Although I generally agree with this, I know people who honestly prefer the explicit true or false comparison.
Then of course, as one of many other examples, there is the whole issue of where to place the curly braces (or even if we should have curly braces at all). There is also the debate over level of commenting. Some think no comments make the most beautiful code, others think very verbose commenting is gorgeous, and many others are somewhere in between. For me, I like concise code, significant white space, carefully chosen comments, highly descriptive method names, and so forth. However, I know many respected developers who have differences of opinion on each of these attributes of code beauty.
Even my own sense of code beauty has changed over the years. When I first read about the enhanced for loop that was anticipated for J2SE 5, I did not particularly like how the code looked. However, it has grown on me and I really, really like the conciseness of that loop and wish that it could be used for an even wider set of iterations. Similarly, I used to be one of those who detested the ternary operator, though I deeply appreciate it in the right context now.
With so many different ideas of what is beautiful and even our own changing ideas of what is beautiful, it is difficult to classify many pieces of code as beautiful or not beautiful in any absolute sense of the word.
Code Beauty is More than Skin Deep?
When I was in high school, my mom and I had very different ideas of what made a girl beautiful. I nearly completely focused on physical looks while my mom was more interested in trying to get me interested in girls who had more than just good looks. I have since learned that beauty really is more than just the outside appearance (although it still includes it along with the other aspects).
Code works the same way. The best code cannot make up for poor design. In fact, many argue that "beautiful code" really does not pertain to the superficial appearance of code and instead really references deeper things like good design, loose coupling, modularity, and so forth. One of the several authors of Beautiful Code has also pointed out (related to recursion specifically) that beautiful code can sometimes actually be less efficient or even not work as well as less beautiful code. Jonathan Edwards has pointed out something that I have experienced myself: like physical beauty, code/design beauty is often marred by life as realities, compromises, and special cases creep in.
Can Code Really Be Beautiful?
In Code Isn't Beautiful, Jeff Atwood argues that code is not beautiful. He has a point. It is difficult to argue that code can be "beautiful" in the same sense as a sunset, a snow-covered mountain top, an ocean or beach, a tropical paradise, and so forth.
As discussed in the spectrum topic above, I definitely believe that some code is more beautiful than other code. However, I try not to get too worked up about striving for "beauty" at all costs because working and useful code can only be beautiful to a point. Code is not only about art and beauty; it is also about functionality.
Conclusion
Proponents of certain languages or frameworks will often tout the beauty of that language or framework. Unless there is significant explanation of why and what is so beautiful about it, I generally dismiss these types of statements as irrelevant. Without further explanation, to say "that particular code is beautiful" is akin to saying "I personally think that particular code is beautiful." That's fine, but that doesn't mean that others, including those who will be maintaining that code, feel the same way. After all, code beauty, like all types of beauty, is in the eye of the beholder.
Subscribe to:
Posts (Atom)