Editor's Daily Blog

Beautiful Machine, Parts 1-2

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. jlrowe writes:

Wow, how utterley and totally useless.

Using bytecode and bypassing javac, there are thousands of little acrobatic tricks like this you can pull, that ultimately break the java language spec and the code maintainers will to live

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 javax.swing.text.Document. At first, it was very encouraging, because both interfaces implied tree-structured data, which of course is what the XML is, so we hoped that we could create a single document implementing both the XML parser and Swing text interfaces. But it ended up not working out because of a single method, like a getElement(int) or getNode(int) or something, defined in both interfaces, but returning different types. So our would-be document class wouldn't even compile.

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:

	public int getX() { return 1;}
	public long getX() { return 2L;}
	public test() {
		int myIntX = getX(); // makes sense
		long myLongX = getX(); // also makes sense
		System.out.println (getX()); // uh oh, which one does this call?
	}

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, jslott announces the latest from the Wonderland project in Release Candidate 1 of Version 0.4 Now Available. "The Project Wonderland team is pleased to announce Release Candidate 1 of Version 0.4. This release represents a near-final version before the official v0.4 release is made. Community members are invited to download and test this version and report back any problems they find! Download Release Candidate 1 Binary. The Release Candidate 1 of Version 0.4 adds a number of new features over Version 0.3, including enhanced audio and telephony support, a PDF viewer, VNC viewer, video player, cone of silence, microphone platform, whiteboard, and in-world audio and video recorders. Release Candidate 1 of Version 0.4 also adds support for several new gestures (nodding, waving, and pointing) and also a single web page for launching the Wonderland client and world builder. We are grateful to the entire Wonderland community for their help and support getting this release candidate ready."

riepi has a followup question in Re: Scenegraph version in JavaFX. "Another Question: What version/build of Compiler is shipped the javafx-sdk1.0pre1? I always worked with the daily builds, but when i installed javafx-sdk1.0pre some of my tryouts didn't work any more... for example in latest builds there was a rename of TextField to SwingTextField but in javafx-sdk1.0pre it is still TextField. Should i work with SDK or the latest builds now?"

Finally, tarbo offers some scripting language advice in Re: Execute PHP Script from Java Code. "If the client has a PHP interpreter, you can call the interpreter from the Java runtime just like you would any other program. If there are libraries which allow PHP execution, you can use these with a native interface (though I'm not sure whether applets --even when signed-- would allow this). I'm thinking the best solution would be to check for Java libraries that implement PHP using the javax.script package. A Google search on "javax.script PHP" turns up a few hits that seem like they could be useful; you'd have to check whether they really are."

Current and upcoming Java Events :

• August 4-8 - Java Training Philippines
• August 8-10 - Atlantic Northeast Software Symposium 2008
• August 11-15 - Struts Training Philippines
• August 15-17 - Southern California Software Symposium 2008
• August 15-17 - Southern Ohio Software Symposium 2008
• August 18-22 - J2EE Training Philippines
• August 22-24 - Central Florida Software Symposium 2008
• August 25-28 - Dev Week India 2008
• August 25-28 - Java Power Tools Bootcamp in Wellington
• September 12-14 - New England Software Symposium 2008: Fall Edition
• September 15-19 - Java Training Philippines
• September 19-21 - Pacific Northwest Software Symposium 2008: Fall Edition
• September 23-26 - Java Power Tools Bootcamp in Melbourne
• September 29-October 1 - The Ajax Experience
• September 29-October 2 - Java Power Tools Bootcamp in Sydney
• September 29-October 3 - JavaEE Training Philippines

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.

Comments

• 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
  :)

  Posted by: danieldee on August 05, 2008 at 05:10 PM

• 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.*/

  Posted by: bpsm on August 06, 2008 at 07:06 PM

This work is licensed under a Creative Commons License.