 |
Search |
 |
|
|
Beautiful Machine, Parts 1-2Posted by editor on August 5, 2008 at 8:00 AM PDT
Why you'd want to distinguish method calls only by return type As I'm catching up with some of the stuff we posted last week, a point I wanted to make about Thursday's feature article got lost in the big JavaFX Preview SDK news, so I'd like to go back to that for a bit. One of the comments on Vinit Joglekar's Return-Type-Based Method Overloading in Java throws scorn on the very premise of the article.
Actually, hang that one on me, because I encouraged the author to proceed with the article, as I've found a real need to distinguish method calls solely by return type. It was years ago, when we were building a GUI editor for our company's XML markup. We needed to support both direct editing of the markup, and a visual GUI builder approach. Of course, it made sense to build both views off the same object, so I tried to combine the XML DOM interfaces (I forget the library we were using; this was before Java had built-in XML support) along with the There's an obvious problem of potential confusion. If Java syntax did allow for method overloads that differ only in return type, you could do crazy stuff like this: Still, having been burned in real life by not being able to override by return type, it's nice to see that there is a way out. If it turns out not to be practical, it's still a good mental exercise to see how it's done, and to reflect on why the Java language is the way it is. Returning to JavaFX matters in the Java Today section, Kirill Grouchnikov notes an unannounced side effect of the JavaFX Preview SDK: Swing apps can get native video codecs and Flash content with JMC. "My number one wish for Java desktop for this year was cross-platform support for H.264 and FLV formats. Today has marked a first (and hopefully not last) step towards playing video content in Swing application - Java Media Components which is a part of JavaFX preview SDK. Here is what you need to do to use JMC in your Swing application..." The SDN's latest interview is Teaching Mobile Computing to Generation C: A Conversation With Java Champion Qusay Mahmoud. In it, Qusay discusses ways to integrate mobile devices into the computer science curriculum, how he uses Java ME in his courses, developing ME apps for the BlackBerry, the Centre for Mobile Education Research (which he helped found), the traits of the current generation of students, and more. Run-time performance monitoring is critical to achieving and maintaining a well-performing system. In the article Run-time performance and availability monitoring for Java systems, the first in a three-part series, Nicholas Whitehead explains how to do low-level granular monitoring of Java performance efficiently. The data you generate can provide valuable insights into system operation and reveal constraints and influences that affect an environment's stability and performance. In today's Weblogs, Evan Summers picks off some major topics in his blog On Computers, God, the Universe and UI. "What are the similarities and differences between "desktop" vs "web" programming? Is RIA the new desktop, and is UI declaration in XML with logic in Javascript, eg. Flex et al, the new UI lingua franca, preferred over DHTML/Ajax and GUI toolkits like Swing? What are the pain points of Swing programming, and how can we ameliorate them?" Fabrizio Giudici updates his OpenJDK gotcha list in Still problems with OpenJDK.... "After fixing my trivial but severe error described in my previous post, other problems occurred with OpenJDK and blueMarine." Finally, John O'Conner looks at Changing project encodings in NetBeans 6.5 M1. "I reported that NetBeans 6.1's project charset encoding feature would allow an unsuspecting user to destroy file data. That's still true...through no fault of NetBeans really. It's just a matter of fact -- if you start out with UTF-8 and and convert your project files to ASCII or ISO-8859-1 or any other subset of Unicode, you will lose any characters that are not also in the target charset."
In today's Forums,
Finally, Current and upcoming Java Events :
Registered users can submit event listings for the java.net Events Page using our events submission form. All submissions go through an editorial review before being posted to the site. Archives and Subscriptions: This blog is delivered weekdays as the Java Today RSS feed. Also, once this page is no longer featured as the front page of java.net it will be archived along with other past issues in the java.net Archive. Why you'd want to distinguish method calls only by return type »
Comments
Comments are listed in date ascending order (oldest first)
Submitted by danieldee on Tue, 2008-08-05 17:10.
I am borrowing a computer.
Mine is broken down.
I've been taking care of my Father & do NOT know when i will have time for much else or $$$s to Repair my computer ????
TY Very Much
:)
Submitted by bpsm on Wed, 2008-08-06 19:06.
Overrides distinguished only by return type:
The problem here is more fundamental than you seem to realize. All the methods of all Interfaces implemented are dumped into a single namespace. Being able to distinguish methods by return type is only a band-aid over part of this problem. Two methods from two different interfaces having the same name *and* signature is still no guarantee that they have the same semantics. What you'd really need is to not lose the namespacing.
Consider how COM solves this or the approach used by Gutknecht's Zonnon language.
// a sketch in pseudo-java:
interface A { void do(); }
interface B { void do(); }
class C implement A, B {
void doA() implements A.do { /* code */ }
void doB() implements B.do { /* code */ }
}
C c = new C();
c.doA(); // legal
c.doB(); // legal
c.do(); // illegal because ambiguous
((A)c).do(); // legal and compile-time safe because C implements A
((B)c).do(); // legal and compile-time safe ...
/* the type-cast syntax in java is notably blecherous, but that's not the issue here.*/
|
|
|
||
|
