Reprise du message précédent :
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 ?

 
Bon,  tu racontes n importe quoi.  
Et non, tu n a pas compris pour la dernière phrase.

mdr, tu n'avances que des notions vagues et c'est les autres qui disent nimporte quoi ?
En attendant c'est toi qui te fait claquer la porte au nez par spring, bon courage

On va prendre un exemple tout con (on va prétendre que c'est un prog java qui l'execute mais ca pourrait etre n'importe quoi) : un bete traitement de purge.

J'ai la liste des réferences de commande (pour rester sur mon ex. perso) à purger en entrée dans une table "COMMANDES_A_PURGER" qui est une table qui sert à juste de point d'entrée. Elle est alimentée uniquement par un traitement qui determine la liste des commandes à purger,  ce traitement la remet à zero à chaque fois.

Le traitement de purge d'une commande fait simplement un "delete COMMANDE where refcommande=<ref>" .   Derrière, c'est le SGBD qui nettoie toutes les tables qui réferencent de manière directe ou indirecte ma commande ( foreign key avec cascade on delete , sous Oracle).

Je constate que ma purge est la plus rapide quand je répartis le traitement de purge sur 5 threads.
T'en penses quoi?

Rebonjour à tous.  
Pour donner des nouvelles l'intérim m'a claqué alors j'ai revu à la baisse mon nombre d'heures hebdomadaires bien que je compte revoir celà à nouveau à la hausse. Et surtout ne pas abandonner.
 

 
Merci pour ta réponse que je n'avais pas vue.
 
Basketor63 :

En effet    
 
Après avoir vu les bases de la programmation (boucles conditionnelles etc...) j'ai abordé les 1ers concepts de la programmation objet (avec udemy) :
Constructeur, Héritage, Composition, Encapsulation, Polymorphisme.
 
Je compte aborder par la suite : ArrayList, Autoboxing/Unboxing, LinkedList, Interface, Inner class, Abstract class.
 
Après ça, vous me conseillez de passer au Kotlin ou bien de travailler l'interface graphique et de faire un petit jeu java PC avant de passer au kotlin ? C'est ce que j'avais prévu initialement de faire mais je ne sais pas si travailler l'interface graphique java aide à travailler l'interface graphique kotlin.
 
Final Fantasy 5.

Tu peux déjà commencer les Kotlin koans: https://kotlinlang.org/docs/tutorials/koans.html
Et voir si tu bloques.
 
Kotlin est vraiment conçu pour être un meilleur Java et sera d'autant plus facile à assimiler si tu approfondis tes connaissances.
Mais une fois que tu maitrises les concepts centraux des deux langages et le coeur de la bibliothèque standard de Java, y a pas de raison que tu ne puisses pas directement te jeter dans des APIs plus spécifiques et développer des interfaces graphiques dans le langage que tu préfères.

 
Les concepts centraux c'est-à-dire ? Pour le Java juste le listing que j'ai fait par exemple ?
Et qu'inclus-tu par exemple personnellement dans le coeur de la bibliothèque standard de Java ? ^^
 
J'ai vu qu'en effet les codes Java/Kotlin peuvent être intervertis, c'est sympa !
Et donc pour le Kotlin, vous approuvez tous Android Studio je devine ?
 
edit : c'est vrai qu'après avoir regardé les Kotlin koans il y a des choses de ce que je compte aborder dans un 3e temps (comme ArrayList par exemple) alors je vais rester sur le Java pour l'instant de toute façon Mais le lien est bookmarké et je vais le geeker plus tard.

Faut bien faire la différence entre le langage et la bibliothèque standard.
Pour faire simple le langage c'est tous les mots clés qui sont directement compris par le compilateur. Il y en a une cinquantaine en Java.
Ça couvre l'aspect impératif du langage (contrôle de flux) et l'aspect orienté objet (ce que tu as cité plus haut).
 
Mais ça ne suffit pas pour utiliser Java en pratique. Il faut connaître au moins un peu la bibliothèque standard. Elle est grande (et contient beaucoup de composants qui ne sont plus forcément pertinents), donc il n'y a pas besoin de tout connaître, loin de là.
Mais les collections (dont ArrayList) et autres structures de données font partie des choses à savoir utiliser, ou du moins savoir aller chercher quand tu en as besoin.
 
Kotlin c'est deux choses:
1. Un nouveau langage, mais qui reste assez proche. En très gros, c'est du sucre syntaxique.
Quand tu fais

en Java, le compilateur pourrait très bien deviner que le type d'une valeur entière, bah c'est int.
Donc en Kotlin ça donne

Et si tu veux vraiment spécifier le type (même si ça n'a aucun sens ici)

 
Kotlin s'appuie sur sa syntaxe pour cacher certaines choses qui sont explicites en Java comme la "nullabilité" des variables, donc il faut être au courant de ces différences qui ne sont pas que syntaxiques, mais parfois changent parfois aussi la sémantique.
 
2. Kotlin vient avec sa propre bibliothèque standard. Mais le but étant de rester le plus proche possible de la bibliothèque standard de Java, les additions sont assez limitées, et sont souvent qu'une petite couche au dessus des classes Java (comme pour les collections par exemple).
Donc ce que je voulais dire, c'est que si tu connais bien la bibliothèque standard de Java, tu devrais pouvoir te débrouiller.
 
Si tu ne fais pas de programmation Android, n'installe pas Android Studio. La version communautaire d'IntelliJ IDEA vient avec tout ce qu'il faut pour apprendre Java et Kotlin, en même temps si tu as envie.

Hello
 
petite question : si on a des questions sur le dev Android, est ce qu'on peut les poser ici vu que le topik dev Android est décédé ?

Ce topic n'est pas particulièrement actif non plus.
 
Je pense qu'il vaut mieux poster dans le topic dédié, ça risque de réveiller certains intervenants (même si l'intersection n'est pas vide, ce ne sont pas forcément les mêmes personnes qu'ici).

ok, je vais essayer

 
Salut.
Si le test marche empiriquement alors tant mieux.
Apres faut voir si en prod il y aura pas d'autres choses qui s'exécuteront en même temps, maintenant ou dans le futur.
Comme j'ai travaillé sur un projet ou chacun bossait dans son coin, tout le monde se mettrait parallélisme pour grappiller. Avec des dizaines d'exécutors indépendants.
Sauf qu'un jour la base s'est effondrée sur elle même et on ne pouvait pas juguler le nombre de threads, car il y avait pas de centralisation. ( Pas de workers côte Sever d'app)
Donc la solution était de réduire le nombre de connections, mais du coup on partait en out of memory parceque le nombre de threads java était incontrôlable.
 
Donc mon conseil serait que si tu parallélises il faut faire en sorte que la parallélisation soit controlable avec un executor global.
Enfin c'est la vision long terme mais ayant été dans le cas où c'est trop tard en raison de cette non vision à long terme, je suis obligé d'avertir
 

Je passe des message de log par saxon le moteur xslt via la balise <xsl:messages> blabla</xsl:message>
 
Je récupère le contenu côté java sous forme de String par une classe MessageListener .
 
J'aimerai formater ces messages par exemple afficher sous formes de table de taille fixe.
Genre  
| Valeur1 | valeurB |
| Valeur2 | valeurC |
 
Le problème c'est que côté xslt les variables que je dois afficher ne sont pas de taille fixe, donc le formatage joli en tableau est bousillé.
 
| Valeur1112 | valeurB |
| Valeur2 | valeurCxyzet |
 
String.format permet de gérer la taille des valeurs, mais il faut qu'elles soient passées en paramètre.
Genre String.format("%1$10s",str) affichera str en taille 10 maximum.
 
Mais j'aurais plutôt besoin de passer une chaîne qui porte son propre format depuis le xslt.
Par exemple "%1$[Valeur1112]$10s" et qu'une lib java interprete le format.
 
En fait n'importe quel truc ferait l'affaire tant que le formatage est interprété côté java.
J'avais même pensé utiliser un moteur HTML.
Un moteur XML pourrait le faire si par exemple j'ai des balise de type <table>.
Ou bien genre une balise <fixed size=10>Valeur1112</fixed> mais j'ai pas envie de réinventer la roue
 

Mmm j'ai une idée.
En fait mon format devrait être $[valeur1112]$s10$ ensuite côté java je place tout les trucs entre $[ ] dans une liste de String et je les remplace par %1 ..%n , et je me démerde pour appeller format avec cette liste de string sur "%n$s10$"  
 

Questions pour progresser en java/conception, est-ce que vous vous servez souvent dans le monde pro:
- des design pattern  ?
- d'UML + génération de code ?
 
 

Hello !
 
Question pour ceux qui font un peu de réseau en Java.
Quand j'envoie un int par TCP à un serveur, si la valeur est <128, pas de problème, le serveur reçoit bien la bonne valeur.
Mais si j'envoie une valeur entre 128 et 255, le serveur reçoit deux bytes
 
Exemple : j'envoie 0xFF et je lis 0xC3BF dans le buffer du serveur
 
J'ai beau me creuser la tête, je vois pas d'où ça peut venir.
 
Si quelqu'un a une idée, je suis preneur.

 
Sans code c'est compliqué. Tu utilises des Integer ou des int?

Les design patterns c'est utile mais peu de monde les connait. ( je les connais pas suffisament bien à part les classiques, faudrait que je me lise un ouvrage, je me dis ça depuis un bail )
L'uml les gens s'en servent plus ou moins jamais. C'est pas que ça sert à rien mais les projets super bien structurés et spécifiés c'est rare, ou alors ça se fait les premiers mois du projet jusqu'a la V1, et puis après ça tombe aux oubliettes.

Enfin ça me rappelle quand tu fais des trucs bien avec héritage etcetera, et puis tu te rends compte après qu'un type est passé sur ton code et rajoute des if et passe des paramètres nimporte comment, bref fait de la merde, et tu peux rien dire parce-que "ce qu'il a fait marche", que le code review il y a pas le temps blabla.

Ha ça me revient, j'avais fait une vue swing dont le constructeur prenait des paramètres MaVue(x,y,z), et il y avait une methode mavue.init() appellée ensuite.
Bah le gars il a trouvé le moyen de passer un paramètre à mavue.init(toto) plutot que passer par le constructeur.

Et puis biensur dans la methode il rajoute un if then else degueux, alors qu'il suffit de surcharger la méthode.

Donc voilà, dans le monde pro, à quoi bon parler de design pattern quand les types comprennent même pas les bases des langage objet, comme l'intérêt de l'héritage, du constructeur, des attributs de classe.

L'héritage, je mourrai avant d'avoir vu un use case où ça a du sens

Ah oui ? Alors qu'en Java, tout est hérité de l'objet Object... Curieux comme réflexion

Je reviens à cause de mon problème de BufferWriter qui commence à la briser menu.

Ci dessous ma method qui envoie un message sous forme de byte par TCP à un serveur :

Quand je mets comme message à émettre
byte[] message = {127, 127};
mon serveur reçoit bien deux octets 0x7F 0x7F.

Mais quand je mets byte[] message = {-128, -128};
Le serveur reçoit 6 bytes : 0xEFBE80 0xEFBE80.

Je ne vois pas d'où viennent les deux bytes 0xEF et 0xBE.
Surtout que mon log me dit bien que j'envoie un message de 2 bytes.
Franchement, je sèche.

Edit :
il semblerait que ça viennent de la définition de mon BufferedWriter
mBufferOut = new BufferedWriter(new OutputStreamWriter(socket.getOutputStream()));
OutputStreamWriter ferait une conversion de mes bytes vers des char puis vers des bytes

Quelqu'un saurait comment écrire en mode bourrin directement en byte dans le buffer ?

Tu ne peux pas utiliser un writer pour ça je pense, cf la javadoc de Writer:

Ce que tu obtiens comme comportement est cohérent avec la javadoc.
 
Si ton objectif est juste d'écrire des bytes avec un buffer, tu peux utiliser new BufferedOutputStream(socket.getOutputStream())

J'approuve malheureusement à 99% ce poste.
Néammoins j'ai fait une formation design patterns il y a peu et ca permet quand même de fixer en tête quelques "trucs qui puent" à éviter, et ca m'a donné un point de vue meilleur et plus larges sur l'utilisation des interfaces. Et j'ai appris quelques trucs qui me serviront surement comme l'Observateur.
Et ca peut servir en cas de refacto aussi.

Petite excuse pour me ré-introduire sur le topic après de nouveaux mois d'absence de pratique :
 
Java (devient ?) payant :
https://www.itassetmanagement.net/2 [...] -jan-2019/
 
Ensuite je réponds à ma propre question :
 

Il s'agit de la POO bien sûr.
 
Cependant...
En repassant en boucle ce que j'ai déjà vu et en allant plus loin dans l'abstraction des exercices, je me pose des questions que je n'arrive pas à résoudre, sur des trucs même parfois primordiaux :
Par exemple :
 

 
Le résultat donne  :
 

 
Je n'arrive pas à comprendre la dernière ligne du résultat, pourquoi ça ne donne pas

 
J'essaye de comprendre (attention les yeux) :
 
Dans la méthode modifyArray, il y a un "new" : création d'un nouveau tableau= référence vers un objet.
A la ligne

array serait "déréférencé" et pointe vers un autre objet non présent dans ce code (ou pas ?), mais array repasse en paramètre de la méthode anotherArray et est "re-référencé" vers le "1er objet" de array ?

Java n'a pas de passage par référence. Dans ta méthode modifyArray, l'adresse de ton tableau est une variable locale. Donc si tu la fais pointer vers un nouveau tableau, ça n'a aucune incidence en dehors du contexte de ta méthode.
 
Tu peux changer ta méthode comme ça

Pour obtenir l'effet escompté.
 
Et non Java ne devient pas payant, Oracle est passé à des cycles de développement plus courts et change sa politique de support, mais ça ne changera pas grand chose en pratique.
L'implémentation de référence est OpenJDK qui est open source.

 
Merci DDT, j'étais possédé par une légende urbaine pour la référence, et merci pour la correction pour la tarification Java ainsi que pour la présentation de la méthode System.arraycopy() bien utile car sur ce dernier point je constate que la méthode Arrays.copyOf() ne marche pas car là aussi ça pointe vers une nouvelle adresse de tableau qui est une variable locale qui va rester inutilisée et à l'intérieur de la méthode :
 

Putain j'ai perdu un monstrueux à chercher pourquoi j'arrivais pas à effacer certains fichiers, et qu'ils disparaissaient que quand la jvm était terminée.
 
J'ai cherché les OutputStream non fermés, je pense en avoir trouvé certains.
J'ai débuggué, comme un ouf, et je me retrouvais dans des situations où explorer ou cygwin listaient le fichier, mais impossible de l'ouvrir.
ls -l dans cygwin montrait des permissions bizarres.
 
En retirant des bouts de code dans les tests, car c'est dans des tests que le blem apparaissait, j'ai fini par voir que le problème venait d'un bout de code qui utilisait  

Donc je me suis dit que c'est pas possible, Files.lines doit être buggué car il doit pas libérer le handle sur le fichier.
Et en fait non, c'est bien ce qui se passe, mais c'est pas un bug !!
Ils ont volontairement pas fermé la resource fichier quand la commande terminale .count() ou foreach est appellée.    
 
Donc il faut faire
 

 
Ce truc de batard

Hello,
 
Question sur les accès BDD, hibernate...
Est-ce qu'il est parfois préférable de faire du native sql pour des questions de perfs (beaucoup d'objets à ramener, avec de multiples liaisons) ?  
 
   

Ou alors le JPQL produit une requête SQL non optimisée.

Pour moi non car avec les Criterias on peut écrire les mêmes requêtes qu'a la main.
Avec l'avantage que combiné à certains framework qui génèrent des enums de tables avec noms des colonnes à partir des métadonnées de la base, on peut être prévenus à la compilation que les requêtes vont foirer, si le model à changé.
Alors qu'en natif on ne saura pas le problème avant que la requête soit exécutée.

Le besoin de faire du natif c'est plus pour accéder à des fonctionnalités qui ne sont pas dans hibernate, comme les fonctions Rank.
Ou bien des hints pour forcer des index etcetera, mais bon si t'en est là ...

perso j'utilise jooq pour certaines query car je trouve l'écriture et la mise à point plus aisée qu'avec les criterias
 
et je trouve que jooq permet de gérer les filtres de manière aisée

salut

Java c'est mon langage preferer  

moi aussi c'est bien utile pour épater les femmes

Vous pensez quoi des streams?  
On dirait que y a une omerta, qu'on a pas le droit de mentionner les problèmes évidents qu'ils peuvent introduire. Java8 c'est génial !!! Ouais!!!.
Alors oui ces putains de streams c'est vachement pratique et ça rend certains bouts de code bcp plus lisibles,  mais ça permet aussi de faire des trucs dégueulasses qui passent easy sous Sonar et suffit d'écrire un TU avec en entrée une liste vide pour que le coverage soit à 100% ... un rève de consultant.  

 
J'ai jamais vu l'omerta dont tu parles, je pense plutot que personne n'y voit un probleme. Ce pattern de stream est la dans des langages recents comme swift ou rust par ex. Ex en rust:
 

 
Si il est la dans des langages recents et crees from scratch c'est parce que c'est une bonne idee amha. C'est assez evident quand on l'utilise je trouve, ca rend le code plus expressif, moins indente, plus decoupable/testable, ca ameliore les perfs des fois etc.
Comme toute instruction du langage, le tenir responsable de la proprete du code me semble tres suspicieux. Si la ou tu bosses les gens committent des trucs degeux parce que le seul garant de la qualite du code c'est sonar, c'est pas la faute a java amha, mais au manque de process et de normes dans l'equipe de dev. A ta place, je mettrais en place des revues de code et du pair programming pour ameliorer la qualite du code et eviter de pouvoir commiter des tests pourris par ex.
Sonar c'est une aide pour les devs, mais c'est tout, l'analyse statique ne suffisant jamais pour juger de la qualite du code.
Bref, les streams sont un reve de consultant dans un cadre ou ils sont faineants (erreur de casting), ou le seul indicateur de qualite c'est de l'analyse statique (erreur de process) et on les laisse faire de la merde (erreur de suivi).

J'en suis convaincu, je refactore des tonnes de for/if/for/if avec. Du moins quand ils sont bien couverts par les TU avant.... (gros legacy)

Quand sur un projet le dev est externalisé, il est courant que le prestataire du dev soit objectivé sur sonar et le taux de couverture.

Dans mon équipe, on fait revue de code et parfois pair programming.
Ca ne garantit malheureusement rien, il suffit qu'un développeur se fasse relire par un autre dév qui s'en tape (ou incompétent, ou complaisant) pour que des monstruosités passent la relecture.
Ou que les 2 dev en pair soient des branlos (ou incompétents, ou complaisants) pour que les TUs soient une blague.

J'en suis arrivé au point où je relis quasi tout le code de l'équipe sur la partie Java du coup... mais quand je suis en vacances, des horreurs passent.
(et y a des autres parties de l'appli faites dans d'autres techno que je maitrise pas, je frémis sur ce que je vais découvrir)

Java8 a été introduit sur un nouveau module de mon projet sur lesquels 2 mecs ont bossés +ou- dans leur coin pendant des mois.
Aucun autre dev de l'équipe n'en avait fait avant.
J'ai mis des mois à me rendre compte à quel point ils avaient fait de la merde bien camouflée. Notamment parce que j'ai mis du temps à comprendre les implications pratiques en terme de TUs et sonar.

Bref, ce que je veux dire, c'est que les stream, même bien utilisés, rendent plus compliqués la vérification de la qualité du code et de la couverture des tests et que c'est un sujet qui ne semble jamais évoqué.  

Les problèmes de lisibilité viennent plus de l'écriture fonctionnelle que des streams je trouve.
Par exemple la tentation de vouloir mettre une fonction -> et puis se rendre que merde il faut catcher une checked exception.
Pas le temps de faire plus propre et hop t'as un truc merdique.