Reprise du message précédent :
 
 
Je compte faire du java mon 1er langage de programmation afin de conceptualiser pour une 1ère fois les opérateurs logiques, les boucles conditionnelles, les méthodes, les objets, les tableaux, l'encapsulation, l'héritage, le polymorphisme, fenêtre graphique, etc...
Le java est aujourd'hui encore généraliste, courant et on y trouve de la doc+tutos facilement, ce qui est un avantage pour moi, débutant. Il me faut lire parfois plusieurs sources différentes pour une même chose afin de comprendre cette dernière.
 
Kotlin+android studio se sont-ils imposés comme java l'avait fait ?
Mon futur est-il inévitablement là-bas ?
Je ne suis pas pressé, je compte faire au moins 1 an de Java avec minimum 10h/semaine, soit grosso modo 500h d'apprentissage et de pratique et uniquement sur le langage de programmation, pas de réseaux/cryptographie/droit à l'entreprise/marketing etc...
Je compte laisser quelques jeux gratuits en open-source ici, c'est mon objectif pour ma 1ère année :
 
http://codes-sources.commentcamarc [...] -jeux/last
(et avant en réculter pour comprendre, bien que je sois encore loin de ce niveau).
 
Je ne compte pas laisser d'appli sur le google play store avant au moins 3-4 ans, voire plus. Je n'ai pas la contrainte, la pression du temps.
 

 
30 min d'essai pour la version ultimate en effet, c'est trop court pour me faire une idée. Je reste sur la version community pour l'instant. Par exemple je ne saurais lister les bénéfices du "Detecting Duplicates" etc..
En tout cas j'ai déjà l'argent pour plus tard, mais je l'investirait dans d'autres formations en attendant je pense.
 
edit : kotlin est-il également meilleur que java pour les systèmes autres que android, genre iOS pour les iPhones ?

 
Google me dit que maven est surtout spécialisé pour le Java EE = appli web ce qui n'est pas mon but. Mais il n'y a pas que Java EE en effet.
Cependant je vais prendre intelliJ pour le debugger.

 
Oui mais j'ai l'impression qu'il a l'air d'être meilleur sur IntelliJ ? J'ai l'impression que le debugger d'eclipse c'est juste les messages dans la console que j'ai toujours eu. Pour un code qui se lance correctement si je fais "Debug" il lance le programme comme si je faisais "Run", et s'il y a un problème, ça m'affiche la même chose que si je fais "Run", avec les messages d'erreurs dans la console.
 
edit : je voulais dire que le debugger d'IntelilJ était plus manipulable ?
 
edit2 : ok pour Maven/Gradle je regarderai plus tard. De toute façon je suis encore loin de cela. A présent je vais continuer ma formation Java avec udemy.

 
C'est noté  
 

 
J'y retourne

 
En effet, et je viens d'utiliser pour la 1ère fois le debugger sur Eclipse, merci (avant je n'avais que les tooltip).
 
edit : en effet je viens de conceptualiser avec ton lien de façon plus complète le debugger d'Eclipse. J'ai peut-être dit une bêtise en le comparant au debugger d'IntelliJ.
 
edit 2 : je viens de voir qu'avec mon inscription sur Udemy j'ai un free trial de 90j au lieu de 30min pour la version ultimate d'IntelliJ. Cependant, je vais garder ce coupon pour plus tard, sachant qu'en plus c'est peut-être mieux si la plupart des gens ici a la version CE.

 
Déjà fait un projet de plus de 20000 classes et 2 millions de lignes de code, ça passe sur du core i5 avec disque dur. Ca passe bien mieux sur linux qui met beaucoup de fichiers en cache d'ailleurs que sur windows.
Mais je pense que intelij se comporterait mieux, sauf que c'est payant, et il faut s'y habituer.
Si je préférais intelij j'hésiterais pas à me payer ma propre licence, et je pense que le développer doit utiliser l'ide qu'il veut si il est plus efficace avec, après c'est à lui de se démerder par rapport à la solution "officielle".
 
Mais d'une façon générale le problème c'est surtout les confs maven faites n'importe comment, et intelij ou éclipse auront les mêmes problèmes de toutes façons.
 
m2e marche bien, mais on peut se demander pourquoi m2e veut absolument son éclipse embeded pour résoudre les dépendances, peut être que l'api maven est pas suffisante pour faire ce qu'ils veulent.

https://github.com/google/google-java-format

Imposer, pas convaincre.
 
Ton intégration continue appelle l'outil de formatage, qui fait foirer la build si des fichiers mal formatés sont détectés.

 
https://google.github.io/styleguide/javaguide.html
Elles sont plutôt pragmatiques et cohérentes, je suis content de voir qu'ils préconisent le no-wildcard pour les imports, c'est une des guidelines pour laquelle je n'étais pas d'accord dans Clean Code.
AMHA il manque juste une position sur le 'final' dans le cas des paramètres et variables locales (idéalement en faveur de l'usage partout ).

C'est plutôt le job d'un analyseur statique ça. Mais leur outil ne le propose pas: http://errorprone.info/bugpatterns

 
D'accord avec la remarque sur l'outil, mais je parle plutôt du contenu de leur code style tel qu'il est décrit dans le lien que j'ai posté plus haut. Rien n'empêche ici d'afficher leur position sur l'utilisation d'un mot clé optionnel. Qu'elle soit vérifiée ou vérifiable par Google Java Format c'est l'étape suivante.

L'idéal serait que l'ide montre le code formaté comme le préfère chaque développeur quand il ouvre un fichier.

 
Raison de plus pour que tu déroules le code comme expliqué pour qu'on voit l'endroit où tu sautes à la mauvaise ligne.
 
L'appel de méthode overloadées dépendant du type des paramètres ou du nombre de paramètres.

L'idée de séparer la représentation du code de son format d'archivage n'est pas nouvelle, les IDEs auraient déjà presque tout ce qu'il faut en interne pour faire ça d'ailleurs.
 
Après en Java y a pas 36 styles non plus...

drap
 
Question mapping, il y aurait des alternatives à Dozer ?  
 

Apache Commons BeanUtils

ModelMapper

Mais c'est pas assez répandu et c'est dommage.  
 
Du coup la plupart des projets faut pas oublié de te caler le formatter qui va bien sinon tu as des changements de format dans tes commits sans arrêt. Quand tu travailles sur différentes projets formatés différemment c'est vite chiant.

 
Merci

C'est ptetre chiant à faire à la main le mapping, mais pour ajouter des champs, en modifier ou en enlever, dans du code dans lequel tu as jamais mis les pieds avec des conversions et passages d'objets à travers 3 ou 4 couches, tu dis juste merci d'avoir des erreurs de compilation.
 
J'ai reconvertis des conversions dozer avec des mappers manuels tellement ça me soulait sur un projet.

 
Rien que la longueur des lignes, ça change absolument tout le formatage

A tout hasard, est ce que quelqu'un aurait réussi à faire du Spring Batch avec :
- un Reader qui lit une table en base
- un Writer qui écrit dans d'autres tables en base
- traitement mutli threadé
J'ai enchainé les echecs là ... y a tjs un truc qui foire, genre si je fais du AsyncProcessor et AsyncWriter (avec spring-batch-integration), SpringBatch clot l'entity manager dès que le Reader  ( un JPAPagingReader ) a terminé -> pratique pour le Writer

Je pense que ça n'apporte pas d'écrire et même lire en multithread sur la même base, sauf si tu as des tables dans tables spaces sur différents disques ou des tables dont les partitions sont sur différents disques.
Le pire c'est écrire dans la même table non partitionnée, car l'écriture entraînera une escalade des locks au niveau row, puis page, puis table, et les indexes aussi vont locker, donc en fait tu y perds même.

Évidement le multithread sert pour un serveur web car un client ne peut pas attendre, il y a besoin de disponibilité.

Faut voir aussi que tu ne peux pas faire du transactionnel multithreadé, parceque les méthodes de l'objet connection et statement sont dans le meilleur des cas synchronisés sur la connexion, et dans le pire des cas non threadsafe.
Donc soit ça n'apportera rien de partager une conection, soit il y a des risques de boucles infinies sur des theads.
Je connais des crétins qui ont essayé au taf ...

Que l'entity manager reste ouvert entre reader et writer ça devrait être possible pour faire du transactionnel, mais comme la session est attachée au thread, si tu des nouveaux thread il n'aura pas de session, et le framework recreera une nouvelle session, donc nouvelle connection.

AMHA, quand tu commences à te demander si les tables sont sur des disques différentes, si elles sont partitionnées, et que tu raisonnes en page/table, tu te poses trop de question.
Je sais pas dans quel env technique tu bosses mais ca a l'air "original".
(PI on est sous Oracle avec une stack Spring Hibernate, et les pb de perf Java / Hibernate/JPA / Oracle, j'en connais un rayon)

Non, là j'ai des données préchargées dans une table, et je dois aller les rattacher à mon coeur de métier (en gros, on gère des commandes, les données préchargées sont des informations sur l'avancement et le contenu de ces commandes, mon traitement va trouver la commande à mettre à jour, et répartir les informations dans une dizaine de tables).
J'ai donc pas de contre indication à multithreadé : la seule opération que je vais faire sur les données de la table en entrée sera de passer un flag à "traité" (sans que 2 thread traite la même ligne), et en sortie, chaque thread va s'occuper de commande (et ses sous objets/tables) différentes.

Par rapport à la théorie SpringBatch (quand je dis théorie, lol, si seulement y en avait une claire...), la lecture de mes données en entrée devrait être dans le Reader (avec  JpaPagingReader ou JdbcPagingItemReader par ex. ), le traitement qui met à jour mes commandes dans le Processor, et mon traitement qui flagge la ligne que je viens de traiter dans le Writer.  Il y a plusieurs solution théorique pour multithreader, j'en ai essayé 2 :
- utiliser des AsyncProcessor et AsyncWriter (et là je tombe sur le bug de la cloture de l'EntityManager)
- utiliser un partitionner sur mon step mais ca me plait pas des masses car là, j'ai X threads qui font chacun reader/processor/writer et faut bricoler explicitement (par ex. en ajoutant une colonne indiquant quel thread va lire quelle ligne) pour que les threads ne lisent pas les mêmes données.  

Je t'ai expliqué pourquoi tu ne peux pas selon moi.
La session est attachée à un thread.
Donc tes writers dans des threads différents ne peuvent pas utiliser la même session de lecture, et pas utiliser la même session entre eux.

Ce n'est pas se poser trop de question que se demander comment est structuré la base et les tables, car tu vas te retrouver avec le résultat inverse de ce que tu veux avec des performances inférieures.

J'ai travaillé dans un environnement où les gens faisaient justement n'importe quoi sans réfléchir donc je le sais.

C'est pas parceque tu utilises hibernate et jpa que tu peux te dispenser de comprendre le fonctionnement de la DB, en tout cas tu peux le faire jusqu'au moment oú tu auras des emmerdes , et le problème c'est que ça sera trop tard

en spring hibernate y a pas un mécanisme de transaction (genre SUPPORT_EXIST) qui permet de réutiliser la session si existante ?

Il ne peut pas y avoir de transaction existante si tu pars dans un nouveau thread.
Les transactions ça ne marche que dans un thread.

Thread -> transaction -> session -> connection

Tout est lié.

certes mais il me semblait pourtant que spring intégrait un truc permettant de dupliquer les infos du thread déjà existant vers les autres threads, y compris les infos de transactions
 
http://blog.dulaj.info/2017/04/spr [...] er_19.html

J'ai pas lu encore mais même si tu fais ça, tu te retrouverais alors avec une session  ,donc une connection, partagée entre plusieurs threads.

Si tu regardes l'implémentation du driver jdbc Oracle, tu verras que toutes les méthodes des classes Connection, Statement, PreparedStatement sont synchronisées sur une instance d'un Objet Connection.

Ce qui veut donc dire que ça ne sert à rien de faire du multithread puisque tout sera exécuté séquentiellement à cause de la synchronisation.

En fait au mieux faudrait utiliser JPA en mode XA pour avoir des transactions distribuées qui permettent d'intégrer plusieurs transaction en une, donc plusieurs connections.
Mais ce genre de truc c'est utilisé pour des transactions multibases ou avec du MQ.

j'ai mal ses posts tu as raison.

Le truc du blog que tu as mis le soucis c'est qu'en cas d'échec les exceptions ne remonteront pas au delà de leur thread, donc il faudrait ajouter un mécanisme avec le thread parent qui chope une exception, interromp les threads enfants et rethrow une exceptione pour qu'elle soit interceptée par la couche aop qui fera le rollback.
 
Apres si ils ont base qui supporte le lultithread sur une connexion pourquoi pas, mais c'est pas transposable à tout.
 
En fait Spring ne supporte pas ces cas de figure.

 
   
 
Si tu lisais mieux, tu devinerais que justement, je n'ai pas besoin que mes threads utilisent la même session de lecture   Chacun de mes threads à son EntityManager, chacun tape dans le pool de connexion, et j'en ai jamais 2 en concurrence sur une même donnée de la BDD. Pour l'entity manager et le pool, ca n'est jamais géré explicitement par mon code évidemment, tout ça est géré de manière transparente par Spring JPA.
 
 
 

Je comprends très bien le fonctionnement de la BDD, merci...  mais quand tu commences à te faire des noeuds au cerveau alors que tu veux juste faire des traitements paralleles en nombre raisonnable avec une BDD tout ce qu'il y a de plus classique, prévue pour ça, y a un soucis.  
 
 

 
Quand aux perfs,  
 j'ai un paquet d’expériences de métrologie et tuning avec des contextes applicatifs et des stacks java techniques très différentes où multithreader réduit le temps de traitement total par typiquement par 3. Evidemment, ca consomme plus de CPU par contre, et , plus tu mets de thread, moins tu gagnes, voire tu finis par perdre, à cause de la concurrence coté BDD... j'ai jamais réussi à obtenir du x5 je pense.  
 
Là dans mon projet actuel, j'ai quelques bricolages avec Spring Batch où ça marche (avec typiquement temps de traitement divisé par 3 en mettant 5 threads).  
Mais je ne suis pas satisfait techniquement des ces bricolages donc je suis venu voir si quelqu'un avait une solution de mise en oeuvre relativement clean.  
 

C'est pas qu'une question de concurrence sur la même donnée (si tu parles de ligne), car la base gère les locks au niveau ligne, mais suivant les réglages quand il y en a trop, alors ça escalade en niveau page, puis au niveau table.

Le fait que tes traitement soient plus rapides parallelisés peuvent venir de goulot d'étranglement diverse par exemple lenteur niveau java avec cpu pas tres rapide en mono thread.
Ou bien le cpu de la base qui limite.
Ou alors t'as une base répartie sur plusieurs disques, ce qui se voit pas forcément avec les volumes logiques et la virtualisation.

Tu as dit que le reader ferme l'entitymanager, et que tu comptais le partager avec le writer. Mais c'est pas du partage de session ça en fait ?