Java passage par reference

Non justement.
Mettre une méthode affect() à String est une mauvaise idée.
String, Integer, Byte, Short, Long, Double, Float, Boolean et Char (à ne pas confondre avec les types primitifs) sont des classes immuables. C'est-à-dire qu'une instance ce des classes ne peut être modifiée en cours de route.
En pratique, on a l'impression que c'est le cas, car on peut faire ceci :

Integer i = 2;
i = 3;

Mais en fait, ce code n'est pas compilé directement comme ça, en réalité, le compilateur Java remplace de lui-même par :

Integer i = new Integer(2);
i = new Integer(3);

On a donc bien deux objets différents qui sont affectés à i. Et ça fonctionne de la même manière pour les String. Ce code :

public static void test(String s) {
    s = "le test marche";
}

devient (juste avant la réelle compilation) :

public static void test(String s) {
    s = new String("le test marche");
}

Petite note avant la suite : quand je parle de variable objet, c'est ce que contient par exemple s ou i dans mes exemples du dessus. Quand je parle de l'objet (mais pas de la variable objet, qui sont des pointeurs), je parle de l'objet en lui-même : par exemple (ci-dessus) Integer(2) ou "le test marche".

Autre détail important qu'il faut bien avoir en tête (et que les habitués du C et du C++ ont l'habitude de gérer), c'est que les variables objets ne sont pas des valeurs, mais des pointeurs. Toutes les variables objets sans exception (les variables de type primitif ne représentent pas des objets). C'est une des raisons pour lesquelles les classes correspondant à ces types primitifs ont été créées (Integer, Short et compagnie).
Cela veut dire que 's' ne contient pas directement la chaîne de caractère "le test marche", mais en fait l'adresse qui pointe sur l'emplacement mémoire où est situé la chaîne de caractères "le test marche". D'ailleurs, si jamais on fait : *String s2 = "le test marche";* dans la méthode statique 'test', s2 contiendra l'adresse mémoire où se situe la chaîne de caractères "le test marche".
C'est la raison majeure pour laquelle les String sont immuables (de même que Integer, Short, etc...) : ça permet à Java de faire une optimisation sans risque, qui est non pas de recréer la chaîne de caractères ailleurs dans la mémoire et affecter son adresse à s2, mais plutôt de lui (s2) affecter directement l'adresse de "le test marche" (qui ezlle existe déjà dans la mémoire).
Au final, s et s2 contiendront la même adresse mémoire. Ça, c'est en théorie. En pratique, c'est un peu plus subtil.

Du fait que ce sont en fait des pointeurs, en découle une autre conséquence (et d'autres, mais je vais pas être exhaustif) : les objets passés en paramètres transmettent en réalité l'adresse, aucun copie d'objet n'est effectuée.
Reprenons le code de tout à l'heure :

public class main {
public static void main(String[] args) {
    String test = "test";
    ValideurTest.test(test);
    System.out.println("Résultat : "+ test);
}

public class ValideurTest {
    public static void test(String s) {
    s = "le test marche";
    }
} 

Le s dans la méthode main contient l'adresse qui pointe (dans la mémoire) vers la chaîne de caractères. Admettons que ce soit l'adresse 1000.
En schématisant :

@1000 : "test" (le @ équivaut à adresse)
[main.main]s : @1000

(J'utilise [<classe>.<méthode>]<variable> pour pouvoir bien les différencier).
On appelle la méthode statique test de ValideurTest en lui passant en paramètre [main.main]s.
Dans cette méthode, le paramètre s ([ValidateurTest.test]s), qui est une autre variable objet, reçoit l'adresse mémoire de [main.main]s. Il contient donc désormais l'adresse 1000.
En schématisant :

@1000 : "test"
[main.main]s : @1000
[ValideurTest.test]s : @1000

Ensuite, on affecte "le test marche" à [ValideurTest.test]s (en admettant que Java crée la chaîne de caractères à l'adresse 1008). On a maintenant :

@1000 : "test"
@1008 : "le test marche"
[main.main]s : @1000
[ValideurTest.test]s : @1008

Qu'est-ce qu'il s'est passé ? On a changé l'adresse pointée par [ValideurTest.test]s, mais pas celle de [main.main]s. [main.main]s désigne donc toujours la chaîne de caractères "test". A la fin de la méthode ValideurTest.test, [ValideurTest.test]s disparais et la mémoire où se situe la chaîne de caractères "le test marche" sera libérée par le ramasse-miettes (Garbage Collector en anglais) de la JVM (Java Virtual Machine : Machine Virtuelle Java, en français) à un moment ou un autre.
Le ramasse-miettes est un processus automaituqe qui libère la mémoire des objets qui ne sont plus référencés (c-à-d qu'il n'y a plus de variable objet qui pointe vers ces objets). Il est présent pendant toute la durée d'exécution du programme, c'est la JVM qui le lance.

Ce fonctionnement, qui est un peu partout dans Java, est difficile à appréhender quand on n'a pas fait de C ni de C++. C'est une des raisons qui me pousse à conseiller ces langages avant de faire du Java.
Une autre solution est de tomber sur un tutoriel ou un prof qui explique tout ça en détail (et par chance, c'est mon cas : mon prof de Java a passé 2h de cours en Amphi pour expliquer uniquement comment fonctionne la mémoire en Java, en comparant avec le C (je suis en 3e année de Licence Info)). Tout ça, je l'ai compris en 5mn grâce au fait que je fais du C depuis 7 ans et du C++ depuis 5 ans.
Mais l'inconvénient est que ces deux langages demandent beaucoup de rigueur lors de la manipulation de la mémoire, ce qui les rend difficiles à apprendre en tant que débutant, sauf exceptions (certains comprennent bien le fonctionnement des pointeurs en 1 mois, d'autres mettent 1 an avant d'avoir le déclic).
Ça dépend de ce qu'on veut et à quoi on a accès. Bref, je commence à être hors sujet xD

Pour terminer, s'il faut retenir une chose : c'est que les variables objets (pas les variables de types primitifs) contiennent l'adresse vers l'emplacement mémoire (la RAM) où est stocké l'objet. Tant qu'on a compris ça et ce qui en découle, pour le reste ça roule !

@Loukiluk
Dans les grandes lignes je suis d'accord avec toi, il y a cependant une petite subtilité dont tu ne parles pas (peut être que je vais te l'apprendre).

La classe String gère un cache de données de tel sorte que tout les String créés en dur dans le code sont mutualisés, il n'y aura qu'un seul objet par valeur, et on pourra comparer leurs références.

Exemple :

class A {
    public static final String TOTO = "toto";
}

class B {
    public static void main(String[] args) {
        String toto = "toto";
        System.out.println(toto == A.TOTO); // true
        String newToto = new String("toto");
        System.out.println(newToto == A.TOTO); // false
        String internToto = newToto.intern(); // ajoute newToto au pool de String
        System.out.println(internToto == A.TOTO); // true
}

Remarque : à la vue de cette mécanique il serait dramatique de modifier un String (même si c'est faisable sous certaines conditions) puisqu'il modifierait tout les autres String qui utilisent la même référence...