If I Could Add One Thing To Java

2 AM August 25, 2004

If I could add one thing to Java, it would be to add first() and last() methods to the List interface. I know it's not going to happen, for all kinds of good backward compatability reasons, but it sure would make some of my code easier to read.

By alang | # | Comments (14)
(Posted to javablogs and Java)

Comments

At 06:15, 25 Aug 2004 Doug wrote:

myList.get(0) and myList.get(myList.size()-1) don't do the job? Granted the second one is longer to type, but you could write a simple wrapper method for it.

Or if appropriate, you could move up to LinkedList, which has a getFirst() and getLast(). Obviously, that doesn't work with ArrayList.

(#)
At 12:10, 25 Aug 2004 Alan Green wrote:

Doug,

Yes, they do the job, they're just hard to read in many contexts. As for LinkedList... that's nice, but Java programmers are "supposed" to access the collections class through the standard interfaces.

(#)
At 13:10, 25 Aug 2004 Paul wrote:

I do not understand why Sun would be unwilling to add such methods because of backwards compatibility. They are always coming out with new and better classes and depreciating methods in favor of new ones.

(#)
At 16:05, 25 Aug 2004 Isaac Gouy wrote:

And perhaps you'd like to provide a default implementation (shock horror) with the interface?

<T> ?T first(List<T> a){
   if (a.size > 0) { return a[0]; }
   else { return null; }
}
<T> ?T last(List<T> a){
   if (a.size > 0) { return a[a.size - 1]; }
   else { return null; }
}
void main(String[] args){     
   let L1 = new LinkedList();
   L1.add(5); L1.add(14);
   println(L1.first); println(L1.last); 
//
   let L2 = new ArrayList();
   L2.add(5); L2.add(14);
   println(L2.first); println(L2.last); 
}
// java version "1.4.2_04"
I:\pls\Nice\Test>java -jar test.jar
5
14
5
14

(And have a generic List for old JVMs, and a little type inference, and painless autoboxing, ... http://nice.sourceforge.net/ )

(#)
At 12:44, 26 Aug 2004 Martin Crawford wrote:

How would adding two methods be considered "breaking" backward compatibility? It only hurts to remove methods or change their signatures. These would be "nice-to-have" extra methods and would not impact anything existing.

(#)
At 13:56, 26 Aug 2004 Gabriel Mihalache wrote:

If there was ONE thing you could add to Java, would this be it? You'd be wasting a pretty big chance!

If *I* had my shot, I'd add operator overloading and make Jython part of the JRE specs. That, or a rich wrapper API over OpenGL or DirectX (depending on platform) and one over 3D sound positioning.

(#)
At 14:04, 26 Aug 2004 Andrew Shuttlewood wrote:

Martin: Adding them to an interface will break every class that implements it. If I've created a class that doesn't support that interface, but supports the old one then it creates a possible problem

(#)
At 04:42, 27 Aug 2004 Martin Crawford wrote:

True. I guess I didn't see this as a problem seeing as the Collections API also includes a number of implementations that the majority of projects just use, meaning again no impact (Sun would obviously had these). The break also would occur at compile time, at runtime a call to class that does not implement the method would throw a NoSuchMethodException. You would think new work would use the new method, and existing projects would never know the difference. I agree that something like how JDBC got ugly is a good warning, with pleny of interface expansion on already cumbersome interfaces. But there are many, many JDBC drivers and probably limited 3rd party implementations of the Colletions API! But yeah, to the original though, first() last() are good notions. Also I never understood y there is a Stack but no Queue (neither are necessary, but yet one over the other). K.... new topic.

(#)
At 23:26, 27 Aug 2004 Jorgen wrote:

multiple inheritance which I miss every now and then. Yeah it's more complex, but you don't HAVE to use it.

Maybe adding default behaviour to interfaces like: 
  
interface Mailable {
  public String formatForMail();
  public void mail(){
    Mailer.getInstance().mail(this.formatForMail());
  }
}

the formatForMail would be compiler enforced (abstract), but not the mail().

class MyReport implements Mailable, Printable{}

Why is that soo bad?

(#)
At 04:45, 28 Aug 2004 David wrote:

I am still new at java and programming in general so this might sound trivial.I would like to see mutable wrapper classes for primitive types and strings. It seems like a waste of resources to instantiate a new object each time you want to change a value. How would adding a set method to Integer, String, ect, hurt the language? It seems to me that it would only help.

Put me down for operator overloading also!

(#)
At 01:17, 30 Aug 2004 Jed Wesley-Smith wrote:

Jorgen, you can get multiple-inheritance without the hassles using AOP mixins.

David, there are some funky things like flyweight patterns, thread-safety and other advantages to immutable objects. If you want mutable wrappers, they are but a class away anyhow. Read Joshua Bloch's Effective Java for a good explanation of the utility of the immutable pattern.

Personally, I reckon closures (and or method pointers, which are really the same thing) are what I would really like, and although it isn't really a language thing but a compiler/VM thing, having generics not use erasure would be better.

(#)
At 02:20, 31 Aug 2004 German wrote:

One thing: Operator overloading.
One this is there you could handle nicely math objects like Matrices, Polynomials, random variables (distributions), etc.

(#)
At 05:58, 18 Sep 2004 Piotr Gaertig wrote:

I would like to see automatic setter and getter generation for bean properties (something as in C#, Delphi) only on compile level (for backward comp with JREs)

<code>
class X {
 // automatic getSomeProp and custom setSomeProp
 private property int someProp {
   setSomeProp throws Exception { alt_impl(value) };
 }
 // automatic getOtherXProp, setOtherXProp
 private final static property int otherXProp;
 // custom names
 private property int otherProp {
   setExtraOtherProp;
   getOtherNameOtherProp;
 }
}
</code>
(#)
At 07:55, 08 Apr 2005 David JOhnston wrote:

class OneThing
{
// operator overloading

// native compilation

// simpler output eg (out?? ) or write ()??

// instead of System.out.print (ln)..blah blah

// templates

// constant references (saves returning
//references to arrays (eg) from a class allowing
//calling method to mutate it (seems a bit silly
//to totally create a new array if it's only
//purpose is to be read (to provide read-only
//access)

// more if i can think of it later...
}

(#)

Add Comment




(Not displayed)






(Leave blank line between paragraphs. URLs converted to links. HTML stripped. Indented source code will be formatted with <pre> tags.)




© 2003-2006 Alan Green