Graham Hamilton's Blog

I'm Looking for some Java Boilerplate

We know we have a lot of power in the Java platform, but sometimes that power has come at a cost in simplicity. We want to improve that, and Ease-of-Development has been a major focus of Tiger, Mustang and Java EE 5. Sometimes we need to add major new features to simplify life for developers but often the problem isn't that there is missing functionality, but that the existing functionality is cumbersome to use, or requires typing unnecessary boilerplate code.

To give you a sense of the kinds of things I'm talking about, see My Favorite (Dead) Java Boilerplate. That gives five examples of removing rough edges and simplifying common tasks.

We've accomplished a lot already, specially in Tiger and in Java EE 5. But I think there is still more to do and I am looking for the next set of things we ought to try to simplify or eliminate.

You can help. What are your favorite Java annoyances? I'm particularly looking for areas where people regularly have to type in awkward or redundant code that ought to be eliminated. In this context, I am mostly not looking for big language changes or major framework proposals. (We tend to do quite enough of that already!) I'm hunting for the smaller polishings that often get overlooked.

(Many thanks to people who've already posted suggestions!)

If you have other suggestions, send an email describing the problem to java-boilerplate@sun.com. We probably won't be able to respond to individual suggestions, but we will read all the proposals carefully. Note: you don't need to provide a solution. If we can clearly identify the problems we have a large toolbag to attack them with.

This is your chance to help get your favorite rough edges fixed!

Comments

• There is a ton of boilerplate related to XML (documentbuilderfactory, etc). JDOM makes it easier but for many projects jdom is too big to bundle just for easier API.

  The biggest boilerplate annoyance that I experience is Runnables:

  SwingUtilities.invokeLater(new Runnable() {
  public void run() {
  setText(x);
  }
  });

  When it could just be something like:

  SwingUtilities.invokeLater { setText(x); }

  Posted by: keithkml on November 15, 2005 at 06:49 AM

• By the way, guys, we can all vote for java.net bug 161 "Line breaks in weblog comments are ignored" to be fixed, so that every comment post here won't be a frustrating experience like it is now. No other commonly used weblog software ignores line breaks.

  Posted by: keithkml on November 15, 2005 at 06:54 AM

• Getters/Setters for simple properties are boilerplate.
  

  Posted by: sumitkishore on November 15, 2005 at 08:27 AM

• inline support for readable multi-line String literals is high on my wish list (see: bug 4472509).
  

  Posted by: jurjanpaul on November 15, 2005 at 08:28 AM

• An XML library that was generics aware would help greatly.getAttributes() should return List[Attribute] rather than just List. Similar updates to Swing, JDBC, JNDI, and other core APIs that return lists would also be valuable.

  The creation of dynamic proxies could be greatly simplified. The current implementation is optimized for the general case, where proxied methods could do anything. The more common case, where proxies are used to wrap other objects with common before and after activities, could use some language support.

  An "Iterables" class, similar to "Collections" and "Arrays", which has common utility operations on Iterable objects. Example operations would include filter, map, reverse, fold, min, max, toSet, and all the other common list recursion patterns that the functional programmers rave about. Instead of simple Lists, though, this library would work on arbitrary Iterables, and similarly create Iterables. (This would also be helped if [] array objects were declared to implement Iterable, a small change). This sort of thing can dramatically decrease code sizes and increase maintainability for common object navigation patterns. Write me if you want more details.

  On the large side, a new anonymous class syntax that makes them closer to Smalltalk blocks or the proposed C# 3.0 delegates would be very sweet. Just syntactic sugar, no semantics changes or JVM modifications necessary. Anonymous classes with no visible fields and only one method are common enough that they deserve a special syntax. You don't have to call them closures if it makes you feel dirty.

  Posted by: dgriffit on November 15, 2005 at 08:39 AM

• And some more:

  Language level support for iterating over Maps, similar to the current support for iterating over Collections. This would save huge amounts of boilerplate fiddling with MapEntry or keySet().

  Collections support for Bags and MultiMaps, ideally also with iteration support. I've never seen a large project that didn't implement these themselves, usually poorly.

  Somehow changing the semantics of try/catch/finally so that the blocks all share scope. That would save a lot of boilerplate
  hoisting of variables that need used in exception handling or finally. Probably too late for this change, though.

  Posted by: dgriffit on November 15, 2005 at 08:50 AM

• I *really*, *really*, *really* wish I didn't have to write and rewrite those getters and setters over and over again. I don't know - maybe this is to big for what you're talking about - I just know I'm really sick of them. Even with IDE help, it's still a pain.
  1. Declare instance variable
  2. Write or generate getter and setter.
  3. Add a constructor to set the property.
  4. Javadoc the instance variable, the getter, AND the setter, AND the constructor parameter. For chripes sake!

  I wish I somehow just declared a property and it worked...

  Posted by: paulrivers on November 15, 2005 at 08:52 AM

• And some more:

  The reflection API requires enormous amounts of boilerplate for common requirements, and going up a level to the Beans API
  actually makes the boilerplate worse. java.lang.Object should have methods getProperty(), setProperty(), and callMethod(), with the
  obvious arguments and semantics. Similarly, java.lang.Class should have callStaticMethod() and newInstance(Object...). This would make reflective programming about twenty times easier, for common use cases.

  Making commonly iterated classes support Iterable. For instance, StringTokenizer should support Iterable<String>, String should support Iterable<Character>, etc.

  Posted by: dgriffit on November 15, 2005 at 09:45 AM

• 
  Why does GridBagConstraints require four statements to set grid bounds? Are methods really that frightening? Personally I'd like a full set of methods that return this as StringBuilder (a bit like Packer).

  Constructing fixed or initialising maps is a pain. At least for collections we can use Arrays.asList or Collections.addAll. I want a standard map builder type thing that will allow me to chain puts.

  JavaDocs for exceptions. Loads of methods all throwing the same exception, and each one has to have the documentation copy & pasted.

  In fact the JavaDoc for exceptions, parameters and return values resemble K&R C. Do we have to repeat ourselves so much?

  C#-style using would be useful. Although, I'd prefer it to syntactically look like a declaration modifier.

  Target typing for new. if it's good enough for methods, it should be good enough for the more common use. Map<String,String> map = new HashMap<String,String>(); is nuts. In fact a new after a Map is almost always going to be for HashMap, List will be ArrayList, etc., so why not a default implementation?

  For the simplest Swing tests, the public static void main(final String[] args) { java.awt.EventQueue.invokeLater(new Runnable() { public void run() { .... }});} is a bit much.

  Anonymous inner class with a single are far too verbose. With target typing, new Runnable() { public void run() { could be replaced by new()() {, or similar. And while your about, list the final restriction on accessing variables of the enclosing method.
  

  Posted by: tackline on November 15, 2005 at 09:45 AM

• Hello!

  I'd like to attempt to put forth a list of Swing things that need to be corrected with regard to magic values, but I have not compiled such a list. I'll post this publicly and cc an email, hoping that others who might understand me will also provide feedback.

  So to try and communicate my point: When creating a GridBagLayout, one must pass Insets to arrange white space in the layout. However, one cannot override getTop() for instance to return a dynamic value -- the fields are public. This leads to fixing magic values into a layout which is not appropriate. The other problem is that it is not smart enough to handle BIDI, since left and right can change, etc.

  For a somewhat concrete example: It is possible to instantiate an Insets for a layout in a place where no Font is yet available. At this point, one may not know what the appropriate sizes for the insets are. And there is no way to inject this into the polymorphic system to be calculated during layout. And it may also not be possible to be sure you have the correct orientation.

  Borders (which I use to great effect to achieve white spacing in layouts) have some similar problems: The EmptyBorder implementation is similarly crippled with magic values -- to use an appropriate euphamism, since accessible interfaces are a big benefactor to fixing these problems.

  BoxLayout has allowed some of this to be fixed since you can specify "line" and "page" axes and insert things in order, including whitespace as struts and glue. But here yet again, one must put magic values into a strut width or height. And this layout has its own annoyances like a [I may be mistaken] lack of proportional sizing as in gridBag.weight, so it is not a total solution to what I'm mentioning here.

  There are other similar places: Anywhere you specify an int for a size or where you must choose left or right at an difficult time.

  These are unspeakably irritating to come over while writing gui code!

  I can post two classes I have made to subvert this problem to some degree: An empty border and a strut that attempt to behave a bit more sanely. You can hereby erase the copyrights and do what you want with the posted code.

  Hopefully this is useful; and hopefully I have made some respectable point in here. Contact me if you would like to discuss anything more.

  And: Thanks!

  Actually, I'll post a link to this code to spare this blog entry! See:

  http://stevencoco.net/boilerplate/

  Ciao!
  Steev Coco

  Posted by: steevcoco on November 15, 2005 at 10:14 AM

• ImageIcon icon = new ImageIcon("icon.gif");
  [this JFrame].setIconImage(icon.getImage());

  Posted by: dblair on November 15, 2005 at 10:21 AM

• Shorter and easier to read alternatives to get(), add(), multiply() etc. Yes, I mean operator overloading, but not a C++-style implementation, instead an implementation that prevents you creating misleading operators.
  The hysteria against operator overloading seems to come from the assumption that any implementation must be open to abuse. This assumption is false. If operators can't be abused, they seem to be entirely beneficial.
  There's some very sensible proposals in this RFE ...including a couple by lucretius (a close relation of mine).

  Posted by: lucretius2 on November 15, 2005 at 10:27 AM

• Expand the for-loop syntax to allow for iterators that need to be closed on loop exit. For instance, we could imagine a Query object that
  implemented Iterable<Row>. Then you could do fun stuff like

  
  for( Row row : query)
  {
  //do some stuff with the row
  }

  
  Sadly, that can't really be done now in cases where you have to close the results of a query in some way. The JDBC RowSet is a good example, although it's semantics don't quite fit. There needs to be some way to close out the row iterator, even if the body of the loop returns abnormally. Vast amounts of boilerplate could be removed this way, and code safety improved.

  Posted by: dgriffit on November 15, 2005 at 10:58 AM

• Make the construct:

  try (MyCloseable obj = new MyCloseable (...)) {
  }

  equivalent to:

  MyCloseable obj = new MyCloseable (...);
  try {
  }
  finally {
  obj.close ();
  }

  If you want to make it a bit more generic and not rely on a Closeable interface then you can emulate the for loop and do:

  try (MyCloseable obj = MyCloseable (...); obj.close ()) {
  }

  The whole point is that working with any API that allocates resources that need to be released after use is very unwieldy because of the need to do this (JDBC example):

  Connection conn = DriverManager...;
  try {
  PreparedStatement query = conn.prepareStatement (...);
  try {
  ResultSet result = query.execute ...;
  try {
  //Code that actually does work goes here
  }
  finally {
  result.close ();
  }
  }
  finally {
  query.close ();
  }
  }
  finally {
  conn.close ();
  }

  All those lines of code are just setup and teardown.

  Posted by: rogerhernandez on November 15, 2005 at 04:02 PM

• How about taking a look at all of the support in Spring (http://static.springframework.org/spring/docs/1.2.x/reference/index.html)

  and start there? EJB, JDBC, JMS sound like good places to start to me.

  Posted by: craigpfeifer on November 15, 2005 at 04:53 PM

• +1 re the EventQueue.invokeX(new Runnable(){ run(){ swingComp.setX() }});A smart IDE will let me select it and surround it with the whole statement, but the code looks more complicated than it should have to.
  Annotations might not work in this case, but it would have been nice if the "needy" Swing Methods were marked similar to@EventThread, and if the calling thread wasn't on the ET it would create the runnable and run it there. I realize that the performance overhead might be too big, but at least a man can dream with JIT and optimization becoming better and better.

  Posted by: jorgenrapp on November 15, 2005 at 05:25 PM

• How about this for some easy to implement boilerplate ?

  
  Color c = new Color("#12fae0");

  I've got a small library routine I use for parsing strings into colors but frankly this should be in the Color class as a constructor.

  Posted by: luggypm on November 16, 2005 at 12:18 AM

• This is legal: 'Class c = MyClass.class'
  Why not this? Method m = MyClass.doSomething().method
  Or this? Method m = MyClass.doSomething( int.class, String.class ).methodWhile we're at it, how about: Field f = MyClass.someField.field

  This would make it much, much nicer to pass in Methods as parameters instead of creating anonymous inner classes, and would maintain compiler checking.

  Posted by: jbarnum on November 16, 2005 at 05:38 AM

• getters and setters, but this would be for mustang of course:

  private @Property String name;

  would be equivalent to writing:

  private String name;

  public String getName() {
  return name;
  }

  public void setName(String name) {
  this.name = name;
  }

  
  However these "generated" getters and setters must still be overwritable:

  private @Property String name;

  public String getName() {
  return (name == null) ? "unknown" : name;
  }
  

  Posted by: ge0ffrey on November 16, 2005 at 06:37 AM

• Somebody else posted a lot of these same things, but:

  1. Make creating GridBadConstraints friendly. I don't like to reuse the object, because that risks inadvertantly forgetting to reset a property. I don't like to create a new object and set it's params individually, because that's a *lot* of typing. I usually using the constructor, because even having to type in all the parameters, it's still the fastest / least error prone way.

  2. It would be *great* if I could write something like "new ArrayList("One", "Two", "Three"), rather than having to either take 5 lines to create, add, and return the list or add a lot of visual garbage by using Arrays.asList(). Ditto with maps.

  3. Javadocs are often very redundant - see my other post about writing the getters and setters especially. And if I want something to show up at the beginning of the javadoc page, why do I have to write two comments for the getter method? (the javadoc comment and the @return comment)

  4. List list = new ArrayList(); and things like Integer i = new Integer(); get real old - wish I didn't constantly have to repeat the type declaration.

  5. Although I eventually just created a subclass so I didn't have to retype it, why isn't there a thread-safe showAndPack() method? Or better yet, showCenterAndPack()? (Or maybe show(boolean pack, boolean center)?). I'm always having to retype that swing worker over and over again.

  6. Anonymous inner class declarations are really rather verbose. Often the declaration of the class takes more space than the code I actually put in it!

  7. In a for-each loop, I still find myself having to write a regular for() loop a lot more than I thought I would.

  Posted by: paulrivers on November 16, 2005 at 01:26 PM

• I forgot - something like this

  try {
  ...
  }catch(IllegalArgumentException, NullPointerException ex) {
  ...
  }

  Would mean a lot less copy-and-paste, especially since a lot of exception handling doesn't really care what kind of exception is thrown. Often I'll have 4 exceptions being thrown, and only 1 of them take different handling than the other 4.

  Posted by: paulrivers on November 16, 2005 at 01:32 PM

• Talking of 'class', why can't this keyword be used to find the runtime class of an object:
  Class c = myObj.class;
  This syntax emphasizes the fact that every object in effect contains a field 'public final Class class'. Of course Object.getClass() also returns this value, but it's currently a mystery where it comes from, in the absence of a field to read it from.
  The 'class' field follows the precedent of the 'length' field in arrays, which is in effect 'public final int length'.

  Posted by: lucretius2 on November 16, 2005 at 04:59 PM

• JavaDocs--add an @accessor as a mutually-exclusive alternative to @return--if @accessor was used, it would describe what the method returned, and would supply the body of the doc description as well as the returns output. This would save us having to write both a description and an @return tag for simple accessors.

  Collections factories using Iterators--Iterators are useful if you want to return a collection and indicate that it is non-modifiable; it's a way to indicate there is a contract that the collection returned should not be modified by the caller. The problem is one can't create Collections classes using Iterators, which means the caller who receives an Iterator either has to do everything in one pass, or must loop the Iterator, stuff it in a new List, then work with that list. Give me a List local = new ArrayList((Iterator)Container.elements()); so I get both a controlled collection and ease-of-use.

  Make "text" input easier to work with. I often have to work with files that contain lines of information. I would like a List of those lines (if they're all read at once) or an Iterator (if read on the fly), plus a filter mechanism to restrict which lines are included.

  List lines = new FileReader(file).lines();

  or

  List lines = new FileReader(file).lines(lineFilter);

  the line filter could also be a line processor, not just accepting lines, but optionally parsing them into some kind of Object.

  
  Thanks
  Patrick

  Posted by: pdoubleya on November 17, 2005 at 02:24 AM

• A couple of years ago I blogged about 2 cases where in Java 1.4.x, the "easy" way to do it was replaced (through deprecation) with one that added considerable complexity.

  I was a little more emotional then as it meant i had to maintain 2 separate versions of my library (1.3.1 and 1.4.2) until my company could let 1.3.1 go entirely.

  The first was JComponent's "requestDefaultFocus()" being deprecated in 1.4(.1). So now in order to do

  tree.requestDefaultFocus();

  you have to do

  tree.getParent().getFocusTraversalPolicy().getDefaultComponent(tree.getParent()).requestFocus();

  which is almost exactly what requestDefaultFocus() already did. I wrote, "If what you have works and is what you want the user to do anyways, why take it away from the user?"

  The second was the deprecation of URLEncoder.encode(string), replaced by one where you had to specify the encoding. A localization "enhancement" that required one to have to know the default encoding string, an unnecesarry complexity for agile development and prototyping in applications you know aren't going to be internationalized. If UTF-8 is not available, the program likely has bigger issues than just encoding URLS, so why not leave the original handler alone as the UTF-8 default and allow internationalization as an option rather than a requirement?

  My final gripe was in Java not deprecating Vector and Hashtable. They are not the best solution for most of the places they're used, and only exist today because of 1.0 compatibility.

  Since so many older programs and examples still use them, new Java users continue to use them not aware that better solutions and design patterns exist. At the very least, Sun/Java could have not supported Generics syntax for Vector or Hashtable to at least encourage the new collections and usage -- legacy programs wouldn't break, but new users wanting better features would be forced to learn the rest of collections rather than relying on 8 year old out of date implementations.
  

  Posted by: acroyear on November 17, 2005 at 02:22 PM

• bah -- sorry the formatting got lost in that...

  Posted by: acroyear on November 17, 2005 at 02:23 PM

• It has already been mentioned above: I vote enthusiastically for some syntactic sugar for directly and safely accessing methods, fields and (most important) bean properties.

  Example: In JavaServer Faces, where the whole UI machinery is built up using "model references" (typcially expressed in EL). In JSF, a textfield component only needs a model reference pointing to some bean property for getting the text value and writing it back. You get rid of enormous amounts of boilerplate code for "wiring up" the UI with the beans, just for pulling state out the beans into the UI and pushing the state back! It would be a real killer feature, if we can do same thing without relying on reflection (which again needs tons of boilerplate code)!
  

  Posted by: scotty69 on November 18, 2005 at 07:25 AM

• Hi.

  About the GridBagConstraints comment above: I have posted a bug related to this: #6213318 You might like to look at it and see if it is related to what you're thinking, or even if you might have a solution.

  Later,
  Steev Coco

  Posted by: steevcoco on November 20, 2005 at 02:22 PM

• I've had this conversation with you too many times... *real* properies in Java are a *must*. The same goes for *real* events. Both of these *need* to be language-level features:

  
  // looks like public field, but it has code associated
  // with read and write operations
  public String name
  get {
  return _name; // private variable
  }
  set {
  // value is passed (matching the property's type)
  this._name = value;
  // this line is the whole point
  // properties can have side-affects when set
  repaint(100);
  };

  
  Another example would be *simple* properties w/ no side-affects:

  
  // looks like public field
  public String name;

  // which is the same as
  public String name get set;

  // or read-only
  public String name get;

  // or write-only
  public String name set;

  
  Or the mixed-case example:

  
  public String name
  get set {
  $name = value; // implied field?
  repaint(100);
  };

  
  Now, events are a lot more complicated, but I can resend the document with all the details rather than fill up your blog comment space...

  - Joe

  Posted by: jnuxoll on November 21, 2005 at 06:00 PM

• 
  I wrote up a proposal for 'surrounded code blocks here.

  
  do CloseAfter (InputStream in) {
  in = new FileInputStream(file);
  // do something with in
  }

  
  do is the current keyword, used here to identify the surrounded code block. CloseAfter is a simple Java class with one static method that gets called around the code block allowing appropriate cleanup. But its more general than that, allowing the block to be called multiple times or not at all. Its not closures though - as closures seem to me to be a step too far for Java. See the link for more details.

  
  Note that my proposal covers dgriffit's requests for "dynamic proxies" "used to wrap other objects with common before and after activities" and "changing the semantics of try/catch/finally so that the blocks all share scope" and rogerhernandez's resource closing.
  

  Posted by: scolebourne on November 22, 2005 at 04:14 PM

• To follow up on my previous posting, I have created a new blog entry and posted a .pdf file with my thoughts on Java properties and events.

  Posted by: jnuxoll on November 22, 2005 at 10:23 PM

• Would love if it were easy to access native libraries without having to write the JNI code to back it. If I could just open a library and use it. That way I could write a java program with CD burning capabilities that only required the user have installed the JRE and libburn (not the JRE + libburn + libburn-jni).

  Posted by: imnes on November 24, 2005 at 07:11 AM

• Endless if / else if / else if / else ... are extremely annoying. switch / case syntax could be extended to work for Strings too, even better: how about switch/case on Objects? They can be compared with equals()...

  Posted by: flekko on November 25, 2005 at 03:00 AM

• Another boilerplate code "idiom" that I see far to often is the conversion of collections to arrays:

  List<String> nameList = new ArrayList<String>();
  ...
  String[] names = (String[]) nameList.toArray(new String[nameList.size()]);

  Uhhh, ugly!
  In the days of generics, shouldn't this be as easy as:
  String[] names = nameList.toArray();

  Posted by: flekko on November 25, 2005 at 03:06 AM

• This idiom is too verbose: System.arraycopy(from,0,to,0,from.length);
  It's also unfortunate that arraycopy is in System, and that it's capitalized wrong. It should be discouraged (not deprecated) in favour of a couple of static methods in java.util.Arrays, something like:
  void Arrays.copy(Object from,Object to); // copies the whole array; maybe throws an exception if from.length != to.length, even if from.length
  void Arrays.copy(Object from,int fromPos,Object to,int toPos,int length); // maybe this can be generified, even though System.arraycopy() wasn't, to check that from and to are compatible at compile time

  Posted by: lucretius2 on November 25, 2005 at 05:20 AM

• That should have said:
  void Arrays.copy(Object from,Object to); // copies the whole array; maybe throws an exception if from.length != to.length, even if from.length

  Posted by: lucretius2 on November 25, 2005 at 05:23 AM

• 3rd time lucky:

  void Arrays.copy(Object from,Object to); // copies the whole array; maybe throws an exception if from.length != to.length, even if from.length is less than to.length

  Posted by: lucretius2 on November 25, 2005 at 05:24 AM

• @lucretius2: If you just want to make a defensive copy, use the array's clone method instead.

  Posted by: flekko on November 25, 2005 at 05:57 AM

• No, the point of System.arraycopy() or Arrays.copy() is to copy into an existing array, not create a new object. You'd want to copy if you're doing it frequently or if the array is large.

  Posted by: lucretius2 on November 25, 2005 at 07:58 AM

• Some of the most boilerplate code I tend to write is null checking, and it's also the source of many problems so IMHO if there's scope for some syntactic sugar to help there, that'd be great.

  I don't claim to have lots of well thought through proposals.... so here's one off the top of my head...

  notnull(a, b, c){
  // if a!=null && b!=null && c!=null
  }
  else{}// optional

  
  Anyone else got ideas (short of massive changes such as a notnull type?)

  Posted by: illsleydc on November 25, 2005 at 10:17 AM

• The Java based language "Nice" has a good solution to the null pointer problem. Variables that may be null are declared with a "?" before their type, like in: ?String a; Without the "?" the variable may not be null. (the compiler enforces that). So, if you expect the caller of a methode to only suppy non-null values, you can express it in the method's signature. This removes most uncertainty about the "nullness" of variables and clears up code a lot!

  Posted by: flekko on November 28, 2005 at 05:06 AM

• I have gathered some common boilerplate requests on one page, including examples, and in many cases proposed solutions:
  'function' interfaces (ease implementing simple anonymous classes)
  annotation-based getters and setters
  a java.util.Iterators utility class in the vein of java.util.Collections and .Arrays, including an implementation of this class
  pythonesque string literals
  compile-time checked and compiled regular expressions
  a null-checking reference operator
  fixes for having to catch an UnsupportedEncodingException that can't actually happen
  General mechanic for ignoring certain checked exceptions
  and last but not least a very simple to use annotation based XML reader and writer. Just write a class structure that roughly matches the XML you intend to read, mark a few fields with annotations, and MOX takes care of the rest. Also includes implementation.

  
  Go here for more details and to discuss: java boilerplate blog.
  

  Posted by: rzwitserloot on December 02, 2005 at 10:13 PM

• JOptionPane

  Creating a simple JOptionPane with the 'create' methods is an excellent tool. One problem they have is when you specify a long String, they will just make a Label that is arbitrarily wide - usally going off the edges of the screen in a completely unacceptable fashon. These should really be tweaked.

  Since they attempt to behave like 'Standard Dialogs', they should continue to incorporate nice default behaviors. They should test the bounds of the dialog and automatically make the label max-out at a good width and grow in height to accommodate the rest of the text.

  Having to do this yourself defeats some of their utility.

  Steven.

  Posted by: steevcoco on December 21, 2005 at 08:18 AM

• > Another boilerplate code "idiom" that I see far to often is the conversion of collections to arrays:

  Absolutely.

  Please add Collection#toArray(Class c) which would be implemented as
  { return toArray(Arrays.newInstance(c, size()); }

  Posted by: mernst on February 03, 2006 at 02:03 AM

• Instead of having to do:

  p.setFirstName("Bob");
  p.setLastName("Smith");
  p.setAge(40);
  ...

  
  I would prefer to just do something like this:

  
  p.{
  setFirstName("Bob");
  setLastName("Smith");
  setAge(40);
  ...
  }

  or
  p do {
  setFirstName("Bob");
  setLastName("Smith");
  setAge(40);
  ...
  }

  
  This small change to the language would make it much easier to create and populate GUI, Business, Collections, DOM, and other objects from Java. The code would be clearer as it would more closely reflect the structure of the Objects being created.

  You can read more about this in my blog entry entitled: Fluent Interfaces.
  

  Posted by: kevingreer on March 09, 2006 at 12:02 PM

• javax.swing.text.html.HTMLDocument

  Wouldn't it make sense to provide a Document implementation similar to HTMLDocument, but based on the org.w3c.dom.Document APIs, so there would be a javax.swing.text.xhtml.XHTMLDocument API with a method to set an org.w3c.dom.Document as a backend?

  Posted by: mklemm on November 09, 2006 at 04:14 AM

• Portable Embedded SQL API: Some DBMS manufacturers provide compilers for embedded SQL, e.g. SQLJ from Oracle. It would be nice if JDBC contained a similar, but DBMS-independent construct that could be compiled during a simple javac run.

  Posted by: mklemm on November 09, 2006 at 04:28 AM

• duet love lyric sexy
  netscape browser free download
  border collie cross puppy
  hall lyric oates one one
  mature sex thumb
  town map of south africa
  cheat gamerz planet
  2d play free online game
  walt disney world resort hotel
  horse race betting site
  ass worship
  game popcap web
  a and e.com
  reggaeton daddy yankee
  wwe maria kanellis nude
  rap music video clip
  espn nfl power ranking
  goog r
  bridge fergie london lyric remix
  copying karoke disc
  sex site view web
  bengal cat for sale texas
  sacramento international airport parking
  philippine latest weather forecast
  carving free pumpkin skull stencil
  7 download explorer internet rc1 release window
  free pumpkin pattern print out
  sagittarius daily horoscope
  adventure cartoonnetwork.com game

  gympartner hallofthewild index.html
  yahoo free board game
  hairy pussy woman picture
  t bone steak house
  free group sex mpeg
  bow crib lil wow
  cat free home remedy removal urine
  shop anytime sears.com mailer
  north and south korean borders
  diamond new pokemon
  adult baby fetish
  univision.com despierta america
  university of hawaii press
  desktop management photo screensaver upload

  webshots
  remember my name lyric
  lyric poem rondeau
  charmed theme song lyric
  w radio
  ass boobies booty bra butt gymnast gymnastics

  leotard
  free latin english dictionary
  malaysia airline academy
  free cat fight video clip
  msn web cam strip
  costume mart teen wal
  my first sex teacher porn
  free nude sex
  radio city music hall new york ny
  diego in san shop tattoo
  mature blow job
  christian baby poem
  state farm bank cd rate
  black people having sex
  .com game msn
  2006 2007 800 800 gmat gmat kaplan kaplan
  teen first time audition
  auto zone houston tx
  free xxx sex site
  fairfield inn marriott hotel
  erase computer file
  custom chrome motorcycle rim
  bus magic school
  auditing management process risk
  goo goo doll name lyric
  free gallery porn slim
  adult spanking tgp
  quote by famous people
  50s hair style woman
  easy driving direction
  amy bodacious nude rose
  beach resort for sale philippine
  funny motorcycle crash
  deportes espanol espn radio
  company edmonton management property
  black demon sex story
  dragon picture tribal
  dell latitude cpi a series
  akon love lyric wanna
  hardcore college sex party
  cat dog not persian
  free pic of gay man fucking
  fun adult birthday idea
  anal first her sex
  fairy dress up game
  cheap software microsoft window
  celebrity sex movie archive
  aol billing information
  popular baby name 2005
  horoscope love test
  car nascar racing set slot
  b g oyster
  small dog breed
  carnival cruise line review
  crazy cat name
  aim code name profile screen
  cold war air force bases
  yo moma so fat joke
  code help image myspace picture
  how to build a dog house
  free porn star pic
  craigs list houston texas
  speaking in god name
  big free picture tit xxx
  grim fandango soundtrack
  free ware game for palm os
  thumb joint arthritis
  melyssa ford picture gallery
  video game com cheat code
  messy blow job
  dog pregnancy gestation period
  big blow milf tit
  feedback mtv.com
  a v e r o
  advance boy emulator game sp
  in pennsylvania school shooting
  football high hoover school team
  california board of dental examiner
  stud dog breeding
  2 flash game santa snowboard
  online audio bible study
  mature sexy free movie
  free lesbian sex video gallery
  yahoo casino game
  dell xps discount
  aquinas cambridge god history in

  philosophy question summa text theologiae
  new rihanna video
  video game cheat sheet
  bbc hindi news.com
  texas a m university kingsville
  dillards shopping spree
  akon myspace.com
  elvis sheet music
  free porn star pic
  ciara music video
  sears outlet nashville
  chart hip hop music new
  big round white ass
  birthday card e free sexy
  free xxx rated sex video
  math puzzle sudoku
  extreme pic poker strip uncensored
  private tour to israel
  map of cook county illinois
  bowwow brown chris like mine
  a love affair game
  m s d s
  06 challenge ea madden sports
  farm animal name
  gay white and black man
  biggest fake tit world
  bumiputra commerce bank berhad malaysia
  pregnancy weekly progress
  13 spoiler survivor
  amateur secret sex vids
  catholic youth bible study
  mission aaa hockey
  georgia high school sports score
  lost robin thicke u without
  pharmacy schools
  info nwa nwa.com
  lake traffic school
  hot sex sexy show site time video
  herbal mineral supplement vitamin
  best boarding schools in india
  brazilizn dictionary english oxford picture portuguese
  free xxx disney video
  virginia dmv sample test
  free erotic online short story
  2006 7 nfl power ranking week
  adopt a dog game
  free fat woman sex video
  answer ask margo question yahoo
  2 bootz flavor from love pic
  beach florida hotel in miami south
  150 99,1999,00,2000,01,2001,02,2002,03,2003 f
  love birthday ecard
  2007 wwe
  chat free live video
  map of county in new jersey
  watch free music video
  change google loose video
  thanksgiving sunday school lesson
  sears canada part
  motorcycle sale texas trike
  big movie tgp tit
  example synonym that thesaurus words
  superman music video by eminem
  playboy playmate playoffs
  beach isuzu palm west
  lyric by ciara
  gay latin man porn
  cub purchase scout uniform

  Posted by: ronald45 on August 07, 2007 at 08:14 PM

This work is licensed under a Creative Commons License.