Discussion :

[adiGuba]

Ce n'est pas du tout la tendance actuelle où les navigateurs ont plutôt tendance à délaisser le support de Java...

Je n'ai jamais dit que c'était une tendance !
Mais cela ne veut rien dire : même le JavaScript a eu une période moins "tendance" où il a été délaissé à l'avantage du coté serveur avant de revenir en force (merci GMail).

Content que tu aies trouvé ton bonheur avec GWT. Même si je suis surpris que Google n'ai pas encore officialisé sa mort (ce ne serait pas le premier produit à subir un tel sort).

Je te rassure l'avenir de GWT est au beau fixe

Comme je l'ai dis plus haut, tu peux passer par des langages intermédiaires typés et objet qui transpilent en JS si ce langage te donne la nausée.
Je me suis d'ailleurs réconcilier avec JS grâce à TypeScript.

Ben c'est ce que je fais avec GWT... mais ce serait plus simple et plus pratique de pouvoir faire cela directement avec du vrai Java !



a++

[Gugelhupf]

Oui, en fait tu veux que la verbosité et la rigidité contre-productive de Java soit transposée côté navigateur...

Je ne vois pas en quoi Java est plus verbeux ou rigide* que les autres langages, c'est juste qu'il est plus concis.
Je ne remet pas en cause les langages cités s'il n'y a que moi qui travaille avec, cependant je pars du principe qu'en informatique tu travailles souvent en équipe et tu as souvent des gens qui ne savent pas nommer une variable correctement, si tu leur donne un langage comme PHP tu peux te retrouver avec un nom de variable bidon et tu ne sauras pas quel était son intention, tu n'arriveras pas à aller en amont sans effort vu que tu n'as pas de typage explicite et que les variables/fonctions globales peuvent être situés dans n'importe quel fichier de code.

* : il faudra me dire en quoi consiste ce mot dans le contexte actuel

[yahiko]

Je ne vois pas en quoi Java est plus verbeux ou rigide* que les autres langages, c'est juste qu'il est plus concis.
Je ne remet pas en cause les langages cités s'il n'y a que moi qui travaille avec, cependant je pars du principe qu'en informatique tu travailles souvent en équipe et tu as souvent des gens qui ne savent pas nommer une variable correctement, si tu leur donne un langage comme PHP tu peux te retrouver avec un nom de variable bidon et tu ne sauras pas quel était son intention, tu n'arriveras pas à aller en amont sans effort vu que tu n'as pas de typage explicite et que les variables/fonctions globales peuvent être situés dans n'importe quel fichier de code.

* : il faudra me dire en quoi consiste ce mot dans le contexte actuel

Rigide c'est par exemple être monoparadigme (hors POO point de salut)

Ensuite, je ne suis pas contre le typage, loin de là puisque j'utilise TypeScript, surensemble typé de JavaScript, pour développer des applications Web.

Pour ce qui est de la verbosité, les exemples sont légion alors que dans les langages multiparadigmes, une simple ligne suffirait pour ces exemples.

Hello World

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
class HelloWorldApp {
    public static void main(String[] args) {
        System.out.println("Hello World!");
    }
}

Lecture de fichier

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
import java.io.*;
 
...
 
BufferedReader myFile =
    new BufferedReader(
        new FileReader(argFilename));
 
...

ou encore la redondance quand il s'agit de manipuler les types génériques, l'obligation de créer un fichier par classe, etc.

On ne va pas refaire le troll de Java ici j'espère mais il y a tout de même des raisons objectives de qualifier Java de verbeux et rigide.

Après, je peux concevoir que des développeurs Java préfèrent ces caractéristiques. Il doit il y en avoir même si je pense que pour la plupart, s'ils défendent ce langage c'est parce que c'est leur gagne pain.

[Gugelhupf]

Je pars du principe que si on laisse le choix avec du typage optionnel, les gens qui se sentent fort (ce qui est "beaucoup" dans notre domaine) ne vont pas typer leurs variables.
J'ai toujours trouvé l'exemple du Hello World imbriqué dans la méthode de point d'entrée main() un peu facile, parce que c'est sûr que tu vas te retrouver avec 3 lignes de code par défaut au lieu de 1, et encore je préfère avoir un point d'entrée que de ne pas en avoir... mais ça dépend du domaine car en Java EE tu ne précises pas de main() . Je trouve l'exemple de la lecture de fichier meilleur pour casser Java, mais depuis Java 7 il y a tout de même le try-with-resources ou des méthodes comme readAllBytes().
Tu peux créer autant de classe que tu veux dans un fichier, du moment qu'il y a une classe public, les autres peuvent avoir une visibilité par défaut/package, cependant je préfère un découpage où je peux retrouver la classe à partir d'un fichier qui porte son nom et qui est situé dans le dossier du même nom que son package.
Je défends Java, pas forcément parce que c'est mon gagne-pain (parce je ne fais pas que du Java, je suis développeur C++ à la base, et puis j'ai fait pas mal de PHP), mais j'ai trouvé beaucoup de bonnes choses dans ce langage, il est plus strict, son environnement et sa bibliothèque standard est d'une grande richesse.

[oallouch]

C'est clair que les Properties seraient vraiment super. Ils expliquent de temps en temps dans la mailing liste du jdk pourquoi ils ne le font pas (je ne me souviens plus de la cause en fait), mais je n'ai plus le problème parce que j'utilise le project Lombok. C'est sûr que ton code rapetisse ! Le seul problème, c'est pour faire des recherches dans ton code pour rechercher, par exemple, qui appelle setToto(). Tu te retrouves à faire des recherches plein texte (par forcément très gênant).

[mikrethor]

Trop hâte de jouer avec Jigsaw.