Le talk "The birth and Death of Javascript" de Gary Bernhardt est très open-minded à ce sujet : https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript

"When you use void as your return type Spring will by default try to determine the view name from your method name, unless it thinks you're directly writing the response (which it does when you have a HttpServletResponse as a parameter). Have a look at section 15.3.2.3 of the Spring 3 docs."

Rah ! Mais il faut vraiment lire tout StackOverflow pour lire ce genre de choses ? Ils ne sont pas fichu chez Spring de faire une usine à gaz avec une documentation et des exemples un peu clair non ? Mince, avec toute la doc qui existe, la base des bases restent tout de même inexpliqué...
Décidément, le Web en Java EE, ça m'énerve à chaque fois !

Voilà qui répond bien à mes questions quant à la modification de paramètres d'une méthode en Java.
Ainsi que ces deux topics :
http://stackoverflow.com/questions/5607773/change-a-functions-arguments-values
http://stackoverflow.com/questions/40480/is-java-pass-by-reference

Rah !!! Déclarer un array en Java (je l'oublie toujours celui là...) :
String[] anArray = new String[10];
Ou en plus court:
String[] anArray = {"Val1", Val2};

Les tests unitaires en Java, c'est le pied grâce à JUnit ! C'est vraiment le pied ! Dans un projet, j'ai même eu l'occasion de m'en servir pour des tests d'intégrations !
Cela devient plus compliqué dès qu'il faut tester des méthodes asynchrones utilisant des callback (ou listener, as your prefer). Je n'ai rien de complètement figé dans ma tête actuellement, mais voilà ce que je note :

• Le framework Awaitility (http://code.google.com/p/awaitility/) permettrait de faire ça proprement, mais ça ne m'a pas tenté.
• Certains disent qu'il faut mocker et faire en deux étapes... Mouais, à mon avis ce n'est pas adaptable dans tous les cas. Pour un test d'intégration système par exemple, il vaut mieux éviter de mocker.

• La solution générique consiste à attendre l'appel du thread à l'aide de synchronized, wait et notify. Dans la réalité, il semble qu'il vaut mieux utiliser CountDownLatch (http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/CountDownLatch.html) afin d'éviter que le callback n'arrive avant que l'on est eu le temps d'attendre... ce serait dommage ;-)
  Actuellement, pour moi, la meilleure solution consiste donc à utiliser un code du type :
  
public class AsynchronousTest
{
/**

  • Asynchronous helper
    */
    private CountDownLatch lock = new CountDownLatch(1);
    /**
  • Received data from the asynchronous call
    */
    private Object receiveddata;

  @Test
  public void testAsynchronousCall() throws Exception
  {
  Object parameters = null;
  myAsynchronousCall(parameters, new MyCallback()
  {
  @Override
  public void onSuccess(Object data)
  {
  receiveddata = data;
  lock.countDown();
  }
  });

  boolean releaseBeforeTimeout = lock.await(2000, TimeUnit.MILLISECONDS);
  // Check timeout
  if (!releaseBeforeTimeout) {
          // Do stuff
          fail("Timeout");
  }
  
  assertNotNull(receiveddata);
  // Other tests

  }
}