Reprise du message précédent :
ben ouais tu peux écrire tes Criteria custom non ? mais bon, vu que c'est hibernate, ça veut aussi dire que tu devras etre capable de transcrire ça en sql non ? Au point ou t'en es, tu filtres après coup.

 
bah devrait y avoir moyen, mais je me demandais si ça faisait
 

 
oui, il faudrait écrire le code qui convertit l'objet en chaine sql
il y a une méthode toSqlString sur les objets qui composent le criteria
mais il y a aussi l'histoire de dialect etcetera, je sais pas si il y a une api claire qui permet d'étendre facilement
 

 
si je maintient dans un cache toutes les données oui c'est faisable
 
mais comme ça résoud pas le problème des recherches approximative, des fautes de frappes et orthographe
je vais peut être laisser le dao jdbc actuel et le temps de mettre en place hibernate search qui se base sur apache lucenne
 
ça sera pas hyper smooth comme transition, mais bon pas de risque, pas de gloire
 
un peu plutard ...
 
bon benh j'arrive pas à télécharger sur le dépôt jboss derrière un proxy
 
Downloading: https://repository.jboss.org/nexus/ [...] .Final.jar
Error transferring file: repository.jboss.org
org.apache.maven.wagon.TransferFailedException: Error transferring file: repository.jboss.org
 
pourtant l'url https://repository.jboss.org/nexus/ [...] .Final.jar j'y accède bien avec firefox
 
 
edit: bon, ça marche avec maven 3.0.3
 
bon il charge une chiée de dépendances
le war est maintenant 10 fois plus gros que le dump de la base de donnée
 
edit : beaucoup un peu plutard : ça à l'air de marcher, l'indexation à eu lieu  

Question  
Si j'ai un client lourd avec des requêtes classiques vers hibernate et que je veux dans la même application faire des requêtes a partir du client léger en mode cache read-only..
Est ce que hibernate va jouer à cache-cache avec mongraphe d'objet ? Est ce que je vais avoir des "operation not permit" quand je voudrais faire des lectures sur le client lourd ?

La question bête du lundi-qui-n'en-est-pas-un : péter l'encapsulation de cette manière (c'est-à-dire pour une classe dont les paramètre sont settés une seule fois à la création), ça vous choque ?
 

public class Foo {
 
    public final int bar;
    public final int baz;
 
    public Foo(final int bar, final int baz) {
        this.bar = bar;
        this.baz = baz;
    }
}

 
Plutôt que de mettre des getters. Je procède intuitivement comme ça, mais j'ai peut-être raté un argument massue.
 

En quoi ça pête l'encapsulation, et pourquoi y aurait-il un problème avec un objet immutable?

Notes que si tu prends des objets complexes, mutables, il te faut les cloner en entrée (et tu dois ajouter un getter pour les cloner en sortie, sauf s'ils ont une forme "frozen" disponible, genre les collections)

 
Mal exprimé, je parle des BP Java qui préconisent getters / setters plutôt que de jouer sur la visibilité des champs.
 

 
C'est ma question
L'idée c'est que mettre des getters / setters à tout va "parce que c'est comme ça qu'on fait ©" ça me saoule, mais je prend les avis au cas où un aspect m'ait échappé dans le cas précédent.
 

 
Genre celui-là

 
D'ailleurs, si j'utilise une instance clonée en entrée et sur un champ final, en quoi - sous réserve que ma classe n'effectue aucune modif sur l'objet en question - un getter clone en sortie est nécessaire ?

parceque la plupart des frameworks qui accèdent en réflexitivité à des attributs d'objets vont faire un String methodName = "get"+nomAttribut;

et pour les interfaces aussi c'est peut être mieux

Ça dépend de l'utilisation que tu fais de tes objets: tout ce qui utilise des beans (ou patterns similaires à base de get*) va demander d'avoir implémenté des getters, même si ceux-ci n'ont pas de valeur ajoutée intrinsèque (faut se plaindre à java après). Idem pour la gestion des interfaces, tu peux pas définir un champ abstrait, un getter (ou setter) si.

cf au dessus, les outils qui te les demandent.

Si ton objet est mutable (seule raison pour cloner en entrée) et que le clone est mutable, alors l'entité qui get* ton objet peut le modifier, et tout d'un coup ta classe immutable ne l'est plus, puisqu'il est possible de modifier les objets qu'elle contient.

À celà il y a deux solutions: que l'objet stocké en interne soit immutable, avec des collections Java standard par exemple tu clone la collection puis tu la wrappe avec Collections.unmodifiable*.

Dans ce cas tu peux juste la renvoyer puisque tes clients n'ont pas la possibilité de modifier la collection (après il faut voir la scope d'immutabilité que tu veux, et considérer le cas d'une collection immutable contenant des objets mutables. YMMV), mais si tu es dans un cas où tu n'aies pas de variante immutable de tes objets (parce que ça n'a pas de sens, ou parce que ça n'a jamais été implémenté, ou parce que tu codes contre un type concret et non abstrait, etc...) alors il te faut aussi cloner l'objet en sortie histoire d'éviter qu'un client ne te le change quand il est visible en dehors.

Le pb est similaire en entrée: tu récupères un objet, mais le code qui te l'a donné peut encore le modifier après te l'avoir donné (genre ajouter des objets dans une collection), considères-tu que c'est un problème ou pas?

on peut définir un attribut dans une interface

par exemple  public String fuck = null;

ça m'arrive de le faire mais que pour des attributs static final

"la plupart" ?
http://code.google.com/p/mockito/s [...] er.java#29
https://github.com/mandubian/siena/ [...] .java#L228

ce sont des constantes de class dans ton cas. Bref, ce ne sont pas des champs d'une class.

Tu m'expliques en quoi ton attribut est abstrait?  

Oui, je suis à près certain qu'il y a plus de 4 fws java. Et il est commun pour les fw web de passer via des beans pour peu ou prou n'importe quoi. Et plus ils sont gros, plus c'est probable.

j'ai rien compris à ta phrase, mais c'est surtout pour dire que "la plupart" des frameworks java ne font pas  
"String methodName = "get"+nomAttribut; " pour faire de la reflexion.

Très clair, merci.
 
Et    général.
 

c'est le définition du mot "la plupart" que tu comprends pas ?

bien sur que si ce sont des champs de classe  

tu m'expliques où je dis qu'il est abstrait ?

quand tu mets un attribut dans une interface ce qui est clair c'est qu'il fait partie du contrat

ensuite ça serait difficile de rendre un attribut abstrait car on peut rien implémenter de plus que ce que sa déclaration.

mais la tu ne démontres rien
tu montres qu'il est possible d'accéder à un attribut de façon directe avec la réflexion
ça ne dit pas si les frameworks en question permettent de procéder ainsi ou si c'est le comportement par défaut pour accéder à des attributs de beans.
mais ça devrait pas être dur à tester

je me suis souvent retrouvé dans des cas ou un attribut privé n'avait pas son getter, donc erreur au runtime
à voir si sous struts par exemple ça fonctionne avec un attribut public sans qu'il y ai de getter

Non mais ils font pas de la réflexion de cette manière, ils passent par les outils dédiés aux beans, qui utilisent la convention [get|set]Property.

Nulle part, et c'est bien le problème: je parlais de champs abstraits. GTFO.

Non. T'as clairement jamais testé ce que ça donnait:

interface Foo {
    String bar = "foo";
}

class Qux implements Foo {
    String bar = "bar";
    public Qux() {
        this.bar = "qux";
    }
}

public class Test {
    public static void main(String[] args) {
        Foo bob = new Qux();
        System.out.println("(Foo) Qux " + bob.bar);
        System.out.println("Qux " + (new Qux()).bar);
    }
}

Trop bien

sauf qu'on parlait plus généralement du cas des attributs, de leur getters, et des implications concernant les interfaces

interface Foo {
    String bar = "foo";
}

class Qux implements Foo {
    String bar = "bar";
    public Qux() {
        this.bar = "qux";
    }
}

public class Test {
    public static void main(String[] args) {
        Foo bob = new Qux();
        System.out.println("(Foo) Qux " + bob.bar);
        System.out.println("Qux " + (new Qux()).bar);
    }
}

je vois pas ce que ton exemple démontre, enfin si je vois, on peut pas faire nawak niveau implémentation si on décide d'utiliser ça
mais ce qui importe à mon sens c'est que le champ est présenté par toutes les classes qui implémentent cette interface.

de façon à pouvoir faire

Foo bob = ...
bob.bar

après les problèmes d'implémentation, de super. etcetera c'est java ...

La partie à laquelle tu as répondu mentionnait très précisément un champ abstrait

Que les attributs crées sur les interfaces ne sont présents que sur les interfaces, pas sur leur contrat, pas sur leurs classes d'implé et sûrement pas sur les instances.

Mais ouais, essayer de setter un champ c'est "faire nawak"

C'est con, tu peux pas

interface Foo {
    String bar = "foo";
}

class Qux implements Foo {
}

public class Test {
    public static void main(String[] args) {
        Foo bob = new Qux();
        bob.bar = "oops";
    }
}

et c'est reparti pour un tour... allez vous tirer les cheveux en pm, sérieux ...

ouais et alors ?

a ce moment là aucun de nous ne savait qu'un champ d'interface était final
donc la possibilité d'avoir une fonctionnalité de contrat similaire à ce qu'on pourrait avoir avec un champ réellement abstrait était encore plausible

mais vu que tu te braques vraiment pour rien dès le début ...

bah si ils sont présents, sauf qu'ils sont automatiquement en final, c'est ce que ton premier exemple ne montre pas et  que le deuxième montre

nan mais t'as pas vu que tu pouvais confondre les champs là ?
tu déclares deux fois le même champ, une fois dans l'interface, une fois dans la classe

interface Foo {
    String bar = "foo";
}

class Qux implements Foo {
}

public class Test {
    public static void main(String[] args) {
        Foo bob = new Qux();
        bob.bar = "oops";
    }
}

bah si tu peux y accéder, tu peux juste pas la modifier vu qu'il est automatiquement mis en final. Ni avoir différentes valeurs pour différentes instances

ce qui du coup répond à la question de l'importance d'avoir des getters et setters concernant les attributs des beans accédés par une interface

Mais c'est pas possible, tu peux pas juste accepter que t'avais tort et arrêter? Ya plus de branches, tu peux pas te rattraper.

Accessoirement, je pense bien que je me braque, quand tu me sors des conneries du style:

en prenant les gens pour des cons (comme d'habitude) je pense avoir quelques raisons de me braquer

No shit, sherlock? Ce que je montrais, c'est (encore une fois) que les champs d'une interface ne font pas partie du contrat de l'interface, mais de l'interface elle même, n'ont donc aucun rapport avec les getters et setters, et que ça pose donc (et on en revient au problème original que tu as savamment réussi à ne pas comprendre dès le départ) problème dans le cas d'utilisation de champs publics: des champs d'instance public ne peuvent pas faire partie d'une interface, c'est donc une très bonne raison pour ne pas en utiliser (ou pour au minima avoir des getters et/ou setters en plus).

Sur ce je considère le débat clos, et ferais de mon mieux pour éviter de répondre à tes conneries la prochaine fois, ça n'en vaut pas la peine. À jamais.

Tort putain

fixed

nan mais ce qui est grave c'est que dès le début tu places le truc sur une question d'avoir raison ou tord

tu te braques parcque en répondant une possibilité alternative au fait qu'il y ai pas d'attributs abstrait au sens stricte tu penses que je te contredit alors que je ne parlais que d'une alternative potentielle

il a fallut qu'on arrive a voir qu'un champ est final après 2 exemples pour se rendre compte que c'était pas possible, alors dit pas que je te prends pour un con ou que je tente de te prendre en défaut, franchement je m'en tape de toi, j'avais juste jamais creusé cette aspect des attributs sur les interfaces.

d'autant que mon intuition intiale était que l'absence de getter setters posait problème si un bean est accèdé par son interface

tu voulais quoi ? que je te crois sur parole parceque tout ce que tu dirais serait parole d'évangile ? En général je suis un peu plus curieux que ça

Tort putain

tiens, qu'est-ce vous pensez d'outils comme Spring Roo ?

play 1.2.1 dispo qui fix ce problème
http://www.playframework.org/download

Y'a du monde qui utilise assertThat + Hamcrest ici ? J'aime *beaucoup*, et les feignants que j'essaie de convaincre d'écrire plus de tests aussi.

La je suis sur des impl de Matcher custom, et j'ai du mal à avoir des messages d'assertion failure assez lisibles:

.. et j'aimerais bien:

"a chalala named 'foo' with a value of 'bar'", ça vient de MonMatcher#describeTo()
"<SomeClass:leToStringDeLaClasse>" ça vient de org.junit.Assert#assertThat() qui fait description.appendValue(actual);

Or, je doute qu'Hamcrest préconise de modifier le toString() pour qu'ils soient lisibles lors des tests - donc je suppute que soit junit est à la rue, soit c'est moi qui ai loupé un truc tout con ...

edit: a priori y'a org.hamcrest.Matcher#describeMismatch (ou dans mon cas org.hamcrest.TypeSafeMatcher#describeMismatchSafely) pour ça, sauf que junit à pas l'air de l'appeler... bon, google time..

edit2: http://stackoverflow.com/questions [...] bemismatch

il y a pas moyen dans éclipse de mettre une marque spéciale dans le code qui permetrait de rendre une portion de code non formatable ?
 
 
par exemple
/**NON_FORMATABLE BEGIN*/
(du code formaté à la main)
/**NON_FORMATABLE END*/

depuis eclipse 3.6 si, regarde dans les règles de formatting

de manière générale, j'ai abandonné les outils de mise en page non classique voire customisé car en équipe, il y en a toujours un qui veut un truc spécial et après le CVS remonte des absurdités quand on diffe... donc, KISS.

c'est pour les trucs genre  a.add(2).add(3).add(4)  
parfois ça peut être bien d'aller à la ligne
ce qu'on ferait pas pour a.getTruc().getMuche().getBiduille()
 
d'ailleurs je trouve qu'il y a un peut le même problème avec le formatage des annotations
j'aime bien que les imbrications soient visibles avec l'indentation

compréhensible mais typiquement foireux si tu travailles en équipe dans le même code et que tes collègues n'en ont rien à faire

il y a justement des plugins eclipse pour ça, qui formattent automatiquement le code à la sauvegarde du fichier.
 

Dites les gens, je crois me souvenir que certains étaient passés par une boîte FR pour négocier des licences de produits Jetbrains, z'avez des noms ? En MP si ça dérange.

Petite question à propos de l'exécution d'un programme sur plusieurs JVM, plusieurs machines.
 
Ça m'est venu en lisant la news sur la sortie de Scala 2.9 et particulièrement l'ajout des collections parallèles :
 

 
On a une même JVM qui schedule le boulot sur plusieurs threads, potentiellement plusieurs cores. Mais si je veux scaler encore plus et que je veux paralléliser l'exécution sur plusieurs machines (hors virtualisation) ? Une JVM sur plusieurs machine, c'est possible (intuitivement, je dirais non) ? Sinon, comment une exécution parallèle de ce type peut-elle fonctionner ? On fait en sorte que chaque tâche soit un programme indépendant sans effet de bord ?
 
Question annexe : quand on bosse avec des Actors (de ce que j'en sais, même comportement que le passage de messages entre process en Erlang), le passage de messages peut-il se faire entre 2 applis différentes ? 2 JVM / machines différentes ? Instinctivement encore, je répondrais non à tout ça, mais ça relance donc ma question plus haut sur la scalibilité d'un programme sur plusieurs machines différentes (toujours hors virtualisation).

Théoriquement oui (Erlang fait ça très bien), en pratique je suis moins sûr, chuis pas persuadé que la JVM soit facile à faire tourner en cluster (il y a probablement des contraintes sur un besoin de partage de mémoire & autres). IBM avait un projet de ClusterVM il y a quelques années, mais à ce que je sache il est mort.

Mais Scala peut fournir ça de son côté, genre sur Terracotta. Me semble qu'Akka fournit ce service et cet article sur Akka 1.1 semble indiquer que ça sera déplacé dans Akka Open Source à la sortie d'Akka 2.0 (le clustering transparent d'acteurs), avec le clustering "explicite" (remote.actorFor/spawnRemote/spawnLinkRemote) déjà supportés dans Akka 1.x

Ok