I will not be looking at proposed features for Java SE 7 that are really beyond the language syntax itself, such as JMX 2 because these are often not as comparable between languages as is the syntax and language features.
The Proposed Java Language Features
There are several sources for identifying and learning more about the various proposed new features for Java SE 7. Alex Miller's comprehensive Java SE 7 coverage is not only a good place to start, but is also a good place to find details about the proposed features. He provides streamed Java 7 news via RSS at http://java7.tumblr.com/.
Other good sites for finding out about proposed Java SE 7 new language features include the Java.net poll results for the poll question about the most-missed features to be excluded from Java SE 7, results of whiteboard polling at Devoxx, Danny Coward's weblog, and Mark Reinhold's Blog.
From these sources, we can glean that some of the proposed new language features for future versions of Java (some have already been punted from SE 7) include:
* Closures
* JavaBean Property Support (AKA "first-class properties)
* Reified Generics
* Operator Overloading
* BigDecimal Operator
* Beans Binding (JSR 295)
* Switch Statement Support of Strings
* Enum Comparison Support
* Multiple Exception Capture
* Multi-line String Literals
ActionScript 3 and Java
It turns out that ActionScript 3 is significantly different than its ActionScript 2 predecessor. Besides gaining general Java-like concepts such as support for class-based objects, single-root object hierarchy, and static typing (ActionScript 2 was dynamically typed only), ActionScript 3 syntax appears to be largely based on Java syntax as well. This similarity can be easily seen in the article Comparing the Syntax of Java 5 and ActionScript 3. However, ActionScript has roots in ECMAScript and so has some similarities to JavaScript as well. We'll see how that ECMAScript heritage plays a role in providing some language features in ActionScript that are not in Java.
I will now look at some of the proposed changes to the Java programming language and compare those proposals to the current state of ActionScript.
Multi-line String Literals
Java currently does not support a single literal string overlapping multiple lines. A lengthy literal String in Java must either require a very long line or must be constructed with String concatenation or being built up through append calls on the StringBuilder or StringBuffer. ActionScript's String class supports similar operators and concatenation methods as the Java String class. However, ActionScript 3 also features a seemingly little-known approach for multi-line literal Strings. This is succinctly described in the blog posting Multi-line Strings in ActionScript 3. Note that the blog author (Doug McCune) associates this ActionScript feature with other ECMAScript implementations. An MXML example of a multi-line String is also shown in that blog posting, but I'm focusing on ActionScript features here (and the MXML case is more obvious anyway considering that MXML is an XML grammar).
/** Lengthy String that overlaps multiple lines. */
private const lengthyString:String = (
<![CDATA[
Here is a very long string that is so long that it cannot easily
be fit onto the same line in the source code. This example
demonstrates the ability to have a single String
overlap multiple lines in the source code. Note how even the white
space is retained.
]]> ).toString();
Just as some Java developers would like to see multi-line literal String support in a future version of Java, some ActionScript developers would like to see full-fledged multi-line literal String support in a future version of ActionScript as well. This is one of those features that would occasionally be convenient (especially for preparing logging messages), but which is not as big of a deal for me as it used to be as I have gotten used to acquiring large strings from external sources such as XML or the database.
Sven Efftinge demonstrates a hack in Java for supporting multi-line String literals. It is also worth noting that both Scala (since 2.1.7) and Groovy support multi-line String literals with three double quotes (Groovy also supports three single quotes for multi-line Strings with no GString expansion) and this is what has been proposed for ECMAScript 4 before the Harmony Effect.
Multiple Exception Capture
There are many times when the same exception handling should be done for two types of captured exceptions from the same
try block, but that common exception handling is not appropriate for catching with a single high-level exception. In such cases, it would be nice to use some type of OR syntax to say handle an exception in a particular way for this exception type or for this exception type. It could look something like this (or could be comma-separated or even something totally different, but the concept is the same):
try
{
// some exceptional circumstance occurs
}
catch (FirstTypeException firstEx | SecondTypeException secondEx)
{
// handle these two exceptions in the same way
}
Neither Java nor ActionScript currently supports the multicatch concept. For additional details on ActionScript error handling, see Flex Error Handling: A Simple Example and Using try...catch...finally Statements.
Enum Comparison Support
Like Java before J2SE 5, ActionScript does not have an enum. Therefore, ActionScript obviously cannot have any type of enum comparison support. There have been several different recommendations for faux enums in ActionScript such as using ActionScript static initializers and using a static constructor, but I would like to see ActionScript get an enum as powerful as Java's. This is an example of where Java has something that I really, really like and would like to have in another language (ActionScript). Using the ActionScript fake enums reminds me of employing similar tactics (read hacks) in Java before J2SE 5.
Switch on Strings
This is popular in the Java development community and I admit that there are some times (especially with legacy code) in which it would be really nice to have. I generally don't need it as much as I used to thanks to the powerful Java enum just described, but I do find cases where it would be useful now and then. ActionScript switch statements do support switching on Strings as discussed in my previous blog entry Java and ActionScript: switch-case and Switching on Strings.
Beans Binding
Just as I miss Java's powerful enum in ActionScript, I similarly deeply miss ActionScript's data (beans) binding in Java. In fact, this was the feature that I was most disappointed to hear would not be in Java SE 7. There are alternatives (including the reference implementation for JSR 295) for Java provided by third-party products, but I really was hoping to see it as a standard part of the language. Data binding in Flex/ActionScript is extremely powerful and easy to use. It may be the most addicting feature of Flex and I know others familiar with Java and Flex have missed it in Java as well.
BigDecimal Operator and Operator Overloading
I must admit to missing the ability to overload operators in Java. When I was primarily a C++ developer, I did not use this feature often, but it occasionally was extremely helpful. I will admit to a certain guilty pleasure from wielding its power and can see how such power in the wrong hands can be dangerous. While several languages other than C++ support operator overloading, ActionScript is not one of them.
ActionScript does not have a BigDecimal equivalent, so the obviously useful BigDecimal-specific operator support is not something that can be found in ActionScript.
Reified Generics
Like enums, generics are another feature with Java since J2SE 5 that is not available in ActionScript. I would really like to see runtime generics support added to Java.
Property Support
ActionScript does support properties as a fundamental part of the language. The primary advantage of ActionScript's implementation of properties is that consumers of these can then reference them directly on the class reference as if they are data members of the class rather than as methods of the class. For example, code calling a property could like like this
outputTextArea.text = propertiesExample.someString;
instead of the more Java-like
outputTextArea.text = propertiesExample.getSomeString();
This is implemented in the class being called like this:
/** Variable must be defined with different name than set and get. */
private var _someString:String = "ActionScript properties!";
/**
* "get" method for readable portion of someString property.
*
* @return My String contents.
*/
public function get someString():String
{
return _someString;
}
This is very similar to just having normal Java-like get and set methods except that the calling code can be a little more concise and treat the property like its directly acting on an attribute/property rather than on a method. It feels like it is calling a public variable, but it is actually calling methods. The advantage is that the data member is still encapsulated and logic can be done as part of the get or set method invocation.
For additional details on proposals for Java to have similar support for properties, see Java Properties and Events, Property Support in Java, the Java Way, and Java 7 - Update on Properties. As other languages have proven, there are multiple ways to implement properties. The real question in the Java community seems to be whether properties should be added at all.
Closures
In the recent Java.net poll cited earlier regarding the feature already dropped from Java SE 7 that was most missed, the closures feature was the dominant first choice (nearly half of all votes). However, that is not the end of the story. Indeed, the Devoxx white board survey on closures showed an even split (41 votes in favor and 41 votes against) on whether closures are wanted or not. It seems that closures are by far the favorite feature of those wanting them, but that a significant portion of the Java community does not want them at all.
ActionScript 3 does have and uses closures and their benefits and downsides are recognized among ActionScript developers. The "Method Closures" section of the ActionScript 3 Overview demonstrates the code readability improvement from using closures.
Conclusion
It seems almost inevitable that if a developer uses more than one programming language, he or she will find facets of each language that he or she wishes was in the other language. That is certainly true of me when I was using C++ and Java at the same time, when I have used Java and Ruby at the same time, when I have used Java and ActionScript at the same time, and so forth. This observation also strengthens the argument for learning multiple programming languages.
No comments:
Post a Comment