: 4582 | 108646 | 12353

Change Java item method parameters to use List instead of Vector 
Use this IdeaSpace to post ideas about Domino Designer.

: 13
: 16
: 3
: Domino Designer
: Java, DOM
: Nick Radov1333 26 Jan 2008
: / Email
The Domino Object Model classes for Java that deal with multi-value items use the java.util.Vector class for item values. For example, see the lotus.domino.Item.setValues(Vector) method. That was a good design back when those classes were first created for Java 1.1. But since Java 1.2 the recommended best practice is to use the java.util.List interface instead. So my idea is to change those Domino Java methods to take List parameters.
There are several good reasons to make this change.
  • A general principle of object-oriented programming is to program to the interface (List) instead of to the implemenation (Vector). That preserves the freedom to change the implementation later, perhaps to something like ArrayList or LinkedList, without having to change the rest of the program.
  • The Vector class is fully synchronized, so it imposes an unnecessary performance impact on programs that only have a single thread accessing that object.
  • Common static source code analysis tools such as PMD and FindBugs generate warnings on uses of Vector since it is no longer recommended.
  • Changing the method signatures would not cause any backward compatibility problems since Vector implements the List interface (i.e. Vector is a List).
I maded this suggestion to IBM's main back-end class developer at Lotusphere 2008 and he was receptive to the idea. It's more of an annoyance rather than any kind of serious problem, but if some others vote for this idea it could probably get done.
Just to be clear, I am not suggesting that IBM change the method return types as that would definitely break existing programs. This idea covers only changing the method parameter types.

1) Axel Janssen5023 (26 Jan 2008)
There maybe a few downward compability issues, so the only chance maybe create lotus.domino2 api, which may be a good idea, hibernate has also hibernate2 or some such. PMD, findbugs, etc. can be configured.
I am more for a lotus.domino2 api based on java5.
2) Nick Radov1333 (27 Jan 2008)
Axel Janssen: what specific downward compatibility issues do you forsee?
3) Matt White9280 (27 Jan 2008)
@2 - I imagine Axel is referring to existing code that would need to be rewritten to use lists instead of vectors. A second API would be a good approach to the problem I think. Excellent idea all round.
4) Nick Radov1333 (27 Jan 2008)
Matt White: I think you misunderstood the idea. Existing code would not have to be rewritten, it would continue to work unchanged. You could change variable declarations to List instead of Vector if you wanted to, but it wouldn't be necessary. Again, Vector implements the List interface so everything is compatible.
5) Matt White9280 (27 Jan 2008)
@4 - Of course you're right, I really shouldn't comment before the first cup of tea in the morning!
6) Kerr Rainey3860 (28 Jan 2008)
@5, no you were right in the first place. There is a huge amount of code out there that looks like this.

Vector items=doc.getItems();

if doc.getItems() starts returning List instead of Vector you will get a "Type Mismatch: cannot convert from List to Vector" compile error.

Yes it would be better if all the client code used List, and I do so as a matter of good practice, but changing the interface will break some existing code.

As I've previously made clear I'm a huge fan of a ground up rewrite of the whole java API, but it would have to be a new api that was orthogonal to the existing one.
7) Kerr Rainey3860 (28 Jan 2008)
Just to follow this up; I realise that the cited example of setting values could be changed without causing a problem, but I taking the position that an asymmetrical api would be far, far worse than leaving things as they are.
8) Josť Manuel Rodriguez Moreno985 (28 Jan 2008)
I don't like the idea of changing the class interface (signature of methods).
In case of changing thinks, there are more things to think about, for example generics:
Vector getItems();

could become:
List<Item> getItems();

9) Axel Janssen5023 (28 Jan 2008)
I think there'ld be very few corner cases of Vector-methods, which are not declared in the List interface. But I guess that IBM would not take that risk to change the existing api, but provide a new version.
With the time there are more and more often small issues with the old api. Tiny issues like "you have to take extra-configuration steps in pmd, checkstyle, etc" pile up.
10) Nick Radov1333 (28 Jan 2008)
@6: I am not suggesting that IBM change any of the method return types. My idea covers changing only the parameter types. Thus the change from Vector to List would be 100% backward compatible. There would be no need for a new version of the API.
If someone also wants the method return types to be changed then please post that as a separate idea so that the discussion for this one doesn't get confused.
11) Kerr Rainey3860 (30 Jan 2008)
@10, then to clarify I'm demoting this idea because having an asymetric api is just plain horrible beyond measure.
12) Per Holmberg444 (10 May 2010)
Changing a parameter type changes the method signature which is NOT backwards compatible. All code using the method need to be recompiled. However, you can ADD methods without breaking old code, like you can have setValues(Vector) AND setValues(List), which would be quite nice.

Also, I would like generics, like:
Vector<Item> getItems()
This should be without backwards-compatibility problems since generics are compile-time only.


Welcome to IdeaJam™

You can run IdeaJam™ in your company. It's easy to install, setup and customize. Your employees, partners and customers will immediately see results.

Use IdeaJam to:

  • Collect ideas from employees
  • Solicit feedback and suggestions from employees and customers
  • Run innovation contests and competitions
  • Validate concepts
  • Use the power of "crowd-sourcing" to rank ideas and allow the best ideas to rise to the top

IdeaJam™ works with:

  • IBM Connections
  • IBM Lotus Quickr
  • Blogs and Wikis
  • Websphere Portal
  • Microsoft Sharepoint
  • and other applications.

IdeaJam has an extensive set of widgets and API's that allow you to extend and integrate IdeaJam™ with other applications.

Learn more about IdeaJam >>

IdeaJam developed by

Elguji Software Logo