Choix d' implémentation

Bonjour,
Je suis en train de mûrir les choix pour la réalisation d'un programme. A la base, mon envie était de faire une applet. J'aurais à créer dès le début de l'execution de l'application, environ 10000 objets, puis faire essentiellement des tries, des selections etc (grosso modo les requettes principales qu'on peut faire sur une BD)
Ces objets seront filtrés et triés donc par la requette de l'utilisateur, puis affichés suivant l'ordre de tri de manière animé.

Par exemple, j'ai 3 objets qui comportent respectivement leurs champs choisis pour le tri à 3, 5 et 8, une barre d'avancement type vidéo défilera, et à 3 min l'objet qui a le champs égale à 3 sera affiché (pour une duré de 10s par exemple), puis à 5 min, l'objet qui a le champs égale 5, puis à 8 min, l'objet de champs 8.

Le nombre d'objet n'est pas fini, mais leurs rajouts sera une mise à jour, pas d'ajout pendant l'execution.


Donc la question est :
vaut il mieux faire

• Une applet qui à les objets stokés sour forme xml dans un fichier texte dans le .jar
• Une applet qui s'adresse à une BD, mais que va t'il en être de la requette énorme du début.
• Faire un lazy loading, et attendre que le besoin des objets soit là pour faire une requette sur une base de donnée. (mais cela veut dire qu'il peut y en avoir quelques grosses qui se suivent pendant un cours interval de temps, et comme l'affichage doit respecter une temporisation...)
• Faire un serveur C++ qui s'occupe des calculs à proprement dit. Ca m'ennuirait car du coup je pourrais pas mettre le résultat sur un hébergement gratuit du net. (c'est pas commercial)
• 10000 objets, ça tournera jamais dans une applet, faut le faire comme une application tournant sur une machine, et quite à faire, que en c++.
• ...

Par dessus ça, des calculs devront être réalisé pour faire entre autre (mais c'est le plus typique) des fléches de l'affichage d'un objet vers un autre dont la création à été influencé par le précédent (suivant un champs influence). Comme la liste des objets est amenée à evoluer, cette liste de flêche pourrait :

• Soit être recalculé après l'insertion d'une objet et stoqué dans une autre table de base de donnée, autre fichier texte (XML)
• Soit calculé dynamiquement.

C'est pour mon plaisir personnel, alors j'ai aucune contrainte imposé, alors lachez vous ! ;)

Je ne sais pas trop si cette discussion doit être dans la partie générale Java ou Langages en Général puisque le choix n'est pas encore fait :D , même si j'ai quand même un faible pour la solution JAVA... (plus facile pour moi, et plus facilement distribuable )

Merci de vos réponses !

Si tu veux gagner tu temps sans surcharger la memoire, j'opterais pour une version multithread avec buffer.

Tu creer un tableau "buffer" d'objet a afficher dans lequel ton application ira chercher les objets a afficher.
Le thread ira lui picher dans la BdD ou autre les infos pour la creation des objets qu'il ajoutera au fure et a mesure dans le buffer.

Une bonne taille de buffer te permettra de n'avoir que peut d'objets en memoire (10 ? 50 ? 100 ?) et d'eviter les lag en cas de nombreuses requettes dans un temps tres court.

Le buffer depends du temps moyen d'une requette, calculé a partir d'un set de requettes successif sur des données equitablement repartie dans ta base de donnée (debut/fin/milieux et gros ensemble de données), et depends aussi du nombre max de requettes par secondes estimée. Tu saura donc a peu pres combien de temps de buffer tu as devant toi.

Mais c'est plus chaud a gerer aussi ;)

Hum, ça me parait interessant, mais je sais pas comment comment on gère les buffers en Java. Je vais lire quelques docs et je reviens ;)

(mais je sais pas dans combien de temps, car le temps de lire ne va peut-être pas être dispo tout de suite tout de suite, mais c'est pas grave, je remonterais le topic à ce moment là ;) )

Enfin si je comprend, vous votez pour la solution Java/BD :o

et les autres ?

M'ci !

Edit : Pour pouvoir me lancer un jour, je pense qu'il va falloir que je gère le truc en trois étapes :

1. la partie qui rempli la liste d'objet (reste à choisir BD/XML ...? )
2. la partie qui affiche
3. la partie qui calcul/fait les requettes

Mais suivant les choix d'implémentations, c'est pas facile de "trier" les deux dernières parties - je me consulte - Hum, si je comprend l'idée "Buffer", la partie qui affiche passe la commande pour les X prochaines secondes, et lit le buffer, deux interactions, c'est tout. Ca doit être triable :o

Citation:

---

Envoyé par Naeco

Hum, ça me parait interessant, mais je sais pas comment comment on gère les buffers en Java. Je vais lire quelques docs et je reviens ;)

---

J'entends par "buffer" une simple zone tampon ;)
La plupart du temps il te suffit d'utiliser un simple tableau avec 2 pointeur 'Start' et 'End' enfin Pointeur ..... je veux dire entier contenant un index du tableau ;)
En jouant sur le modulo tu peux boucler sur le tableau sans te prendre la tete avec les indices de fin. A chaque vois que tu utilise une donnée, tu incremente "start" (pas besoin de vider la casse du tableau, elle ne fait plus partie de la zone "Start/End" donc considere comme vide)
et a chaques fois que tu ajoute une element tu incremente Fin.
En aplpiquant le modulo sur la valeur incremente .. tu boucle sur Zero des que tu atteint "BufferSize".
Avant d'ajouter un element, il faut tester que "End+1" n'est pas egal a "Start"
Sinon tu ecrase ce qui n'a pas encore ete traité.

Citation:

---

Envoyé par Naeco

Enfin si je comprend, vous votez pour la solution Java/BD :o

---

Non .... Plutot pour la solution Delphi ;)
De ce cote la je ne sais pas ... je demarre en java et je ne connait pas les limites de ce langage et toutes ses possibilités. Je disserte juste sur l'aspect conceptuel de la chose ;)

Citation:

---

Envoyé par Naeco

Edit : Pour pouvoir me lancer un jour, je pense qu'il va falloir que je gère le truc en trois étapes :

1. la partie qui rempli la liste d'objet (reste à choisir BD/XML ...? )
2. la partie qui affiche
3. la partie qui calcul/fait les requettes

Mais suivant les choix d'implémentations, c'est pas facile de "trier" les deux dernières parties - je me consulte - Hum, si je comprend l'idée "Buffer", la partie qui affiche passe la commande pour les X prochaines secondes, et lit le buffer, deux interactions, c'est tout. Ca doit être triable :o

---

Pour le choix de la structure qui heberge les données, je ne sais pas.
Une BdD c'est pas mal car elle gere les requettes elel meme, mais il te faut au moins un acces internet ... sinon ca risque d'etre galere a distribuer.
En general j'aime bien opter pour la gestion personnelle du fichier de donnée : Un bon vieux fichier binaire dans lequelle j'ecrit et je structure mes donnes par blocs. XML reviens un peu au meme, sauf que sous Delphi sa gestion demande l'instalation d'une bibliotheque tellement complexe que ca me saoulais :) Sous java je ne sais pas ... si tout est fourni et facile a utiliser ca peut etre pas mal ;)
Ca t'affranchi de toutes limites dont celle d'un acces internet pour une BdD distante.

La partie qui affiche elle devra surement ne gerer que l'affichage. Je pioch, j'affiche. Dans le cadre d'application a contrainte temporelles, moins la partie d'affichage en fait mieux ca vaut.
Le tout et de lui transmettre les donnees qu'il lui faut, dans l'odre qu'il lui faut.
LE tri devra donc se faire avant ajout dans le buffer, que la partie affichage n'aura qu'a depiler.

Pour les requettes/tri, il faudrais en savoir plus sur ton concept. Si j'ai bien compris tu souhaite faire une sorte de slide a la power point ... donc j'opterais par une requette de toutes les donnees correspondant a la meme section temporelle (ou interval) et ensuite je les ordonnerais dans un tableau temporaire, puis je les ajouterais au buffer au fil du temps. Une fois toutes les donnees ecrites, je passe a la section temporelle suivante.
L'ideal serais d'avoir un buffer tel que l'on puisse etre sur d'ajouter toutes les valeurs d'une sectio ntemporelle d'un coup sans que le buffer soit vide.

Bien sur le traitement devra se faire dans un thread secondaire ... sinon aucun interet ;)

Merci pour cette longue prose !

oui, ok l'idée est claire.

Sinon j'avais pensé à une FIFO aussi :o

Et les pro java, vous en pensez quoi, viable en applet d'après vous ?

Citation:

---

Sinon j'avais pensé à une FIFO aussi :o

---

C'est un buffer de ce type dont je parlais ;)
C'est tout a fait adapté a tes besoin :)

En java il existe des solutions plus évoluées qu'un simple buffer ou une FIFO, ensuite tout dépend du besoin.
Grosso merdo tu peux mettre en place de véritables caches (possibilité présente dans hibernate par exemple)

Une implémentation de ces mécanismes: EHCache

Hum, oulà, ça m'a l'air compliqué tout ça.
J'ai trouvé ça sur developpez.net :

http://stessy.developpez.com/j2ee/hi...e/?page=page_3

et ça ailleurs :
http://www.tellaw.org/index.php?2005...e-avec-ehcache

j'ai lu de trois truc à droite à gauche, et je ne comprend pas trop, si ehcache est un gestionnaire de cache, à quoi sert la couche hibernate en plus ?

Ben à cause des informations tirées à partir des objets (les fleches dont je parle dans le premier post), il est possible de se trouver face à cette situation :

• Objet1 champs_de_temps : 2 creation influencé par : null
• Objet2 champs_de_temps : 5 creation influencé par : 1
• Objet3 champs_de_temps : 8 creation influencé par : null
• Objet4 champs_de_temps : 15 creation influencé par : 2
• Objet5 champs_de_temps : 18 creation influencé par : 1

En supposant que les objets sont affichés pendant une pèriode de temps de 1 minute, ça va donner :

• minute 2 : affichage de 1
• minute 3 : effacement de 1
• minute 4 : rien
• minute 5 : affichage de 2 / affichage de 1 / fleche de 1 vers 2
• minute 5 : effacement de 2 / effacement de 1 / effacement fleche de 1 vers 2
• minute 6 : rien
• minute 7 : rien
• minute 8 : affichage de 3
• minute 9 : rien
• ...
• minute 15: affichage de 4 / affichage de 2 / fleche de 2 vers 4
• minute 16: effacement de 4 / effacement de 2 / effacement fleche de 2 vers 4
• minute 17: rien
• minute 18: affichage de 5 / affichage de 1 / fleche de 1 vers 5
• minute 19: effacement de 5 / effacement de 1 / effacement fleche de 1 vers 5

Du coup, un FIFO serait bien, mais pas suffisant, il faudrait que je fasse un champs "dont dépend" au lieu de/en parallèle de "depend de", si je sais que l'objet dépend d'un autre qui sera affiché dans un temps inférieur à une certaine valeure, je le garde en cache, sinon, je le vire... et là peut-être que ehcache serait bienvenue ...

Mais faut que je lise des docs sur ehcache pour voir. Car mon cas n'est pas non plus si compliqué, alors faut pas utiliser un bazooka pour tuer une mouche ;)

Citation:

---

minute 2 : affichage de 1
minute 3 : effacement de 1
minute 4 : rien
minute 5 : affichage de 2 / affichage de 1 / fleche de 1 vers 2

---

Si j'ai bien compris, la fonction "depend de" entraine le reaffichage de l'objet dont ce dernier depent et non de l'usage d'un objet deja existant c'est ca ?
Vu que d'apres ton exemple, 1 est effacé puis recree lorsque 2 est affiché.

Dans ce cas, je ne vois pas ou est le probleme ....
Lorsque tu appele 2, tu charge recursivement les parents.

D'un autre coté, 1 possede un timecode de 2 la premiere fois .. mais sera affiche lors de l'appel a 2 lors du timecode 5.
J'ai peut que l'affichage d'un objet de timecode inferieur a celui en cours pose un probleme .....

En fait je te propose la solution suivante : Decoupper les donnees de la timeline.
Dans une BdD ou autres, tu stocke des types d'objets differents : Fleche haut, fleche bas, fleche, droite, fleche gauche, carré sans fond, carré avec fond, ovale, etc ....
Ensuite tu te genere une timeline qui definira l'odre d'affichage des objets.
L'affichage lui va donc avoir un pointeur sur un index du tableau de la timeline, dont il testera l'element ciblé (timecode) avec le timecode courrant. Si le timecode courrant est supperieur au time code de l'element pointé, l'affichage afficher l'objet indiqué dans un 2e champs de cette timeline, et incremente le pointeur (appele dans ces cas la "compteur ordinal" ou "CO"), puis teste la valeur suivante, et boucle tant que les time codes des elements suivant sont toujours inferieur au timecode courrant.

La structure de la timeline peut etre basique (contenir le timecode de l'objet et l'id de l'objet dans la base). Dans ce cas les données de la base doivent contenir TOUTES les infos necessaire a la creation de l'objet a afficher. PAr exemple, <carré rouge avec un bord noir et le texte "toto"> generera uen entree dans la base de donnée differente de <carré rouge avec un bord noir et le texte "titi">

La structure de la timeline peut etre plus complexe : La base de donnee peut definir des objets differents dont le parametrage sera effectué depuis la timeline. L'objet <carré rouche avec un bord noir> est defini dans la Base de donnéé, et le texte "toto" et "titi" sont defini dans la timeline en tant que champs supplementaire.
Dans ce cas, la timeline peut progressivement s'approcher d'un pseudo code analysé en temps reel a la sauce "java" ;)
Par exemple :
TIMECODE 1 NEWOBJECT Obj1 OBJECTTYPE 8 TEXT toto WIDTH 32 HEIGHT 48 TOP 128 LEFT 230 TIMECODE 1 NEWOBJECT Obj2 OBJECTTYPE 4 WIDTH 32 HEIGHT 48 TOP 128 LEFT 230 TIMECODE 1 SHOW Obj1 TIMECODE 1 SHOW Obj2 TIMECODE 3 HIDE Obj1 TIMECODE 3 CLEAR Obj2 .... TIMECODE 5 SHOW Obj1 TIMECODE 5 NEWOBJECT Obj3 [...]

Analyse du pseudo code :
Ton compteur parcours dans un seul sens le tableau contenant le pseudocode et lance successivement des appels a certaines fonctions, qui analyse la suite du tableau en fonction du code retourné.

Plusieurs types d'analyses sont possibles, tout comme plusieurs types de codage du pseudo code sont possible. Si cette solution t'interesse .. dit le mois je detaillerais plus ;)

Citation:

---

Envoyé par Clorish

Si j'ai bien compris, la fonction "depend de" entraine le reaffichage de l'objet dont ce dernier depent et non de l'usage d'un objet deja existant c'est ca ?

---

oui :D

Citation:

---

Envoyé par Clorish

Dans ce cas, je ne vois pas ou est le probleme ....
Lorsque tu appele 2, tu charge recursivement les parents.

D'un autre coté, 1 possede un timecode de 2 la premiere fois .. mais sera affiche lors de l'appel a 2 lors du timecode 5.
J'ai peut que l'affichage d'un objet de timecode inferieur a celui en cours pose un probleme .....

---

Non non, moi non plus je ne vois pas de problème sur ce qui est des appel eux même ! En effet, il suffit de consulter le champ "depend de " et de réafficher ces entrées.

Je détaillais de cas juste pour avoir un avis sur l'utilité d'utiliser ehcache ou pas. Car sans ce cas, la FIFO suffirait très bien, mais à cause de ça, il faut refaire une requette pour le même objet plus tard, d'ou peut être l'intêrêt d'un cache.

Les questions sont donc :

• Mon cas est il suceptible d'avoir typiquement besoin d'un cache
• si oui, ehcache ? la grosse machine qu'a l'air d'être hibernate
• Ce cache peut il seulement être utlisé avec une BD ? (cette dernière question, bon, je pourrais trouvé tout seul en lisant les docs, après mes partiels ;) )
• les questions toujours en suspend : Java / Java applet / c++ ? BD / XML ?

Citation:

---

Je détaillais de cas juste pour avoir un avis sur l'utilité d'utiliser ehcache ou pas. Car sans ce cas, la FIFO suffirait très bien, mais à cause de ça, il faut refaire une requette pour le même objet plus tard, d'ou peut être l'intêrêt d'un cache.

---

Dans ce cas oui ... tu gagnera du temps a l'affichage.
Maintenant tout depends des perfs requises. Si ta FIFO est suffisement grande pour "absorber" les appels aux composants lorsque tu les reafichent, tu peut te passer d'un "cache".
A noter que l'utilisation d'un "cache" me semble un peu "hasardeuse".
A priori un cache a une taille limité, donc se vide au fure et a mesure qu'on le remplit. Donc tu risque (et c'est meme sur) de perdre des objets a reafficher plus tard, et tu sera ammené a les recharger.
Sinon, le cache garde toutes les infos ... et c'est plus un cache ! Autant creer directement tous les objets des le depart, quitte a les charger dans un thread parallele et commencer la lecture avant la fin du chargement (pour gagner du temps au chargement).

Sinon il te reste l solution du Pseudocode a interpreter ;)
Mais tres vite, et surtout selon les cas d'utilisation, je me demande si la memoire utilisée dans un programme optimisé ne sera pas proche de celle utilisé lors de la creation de tous les objets au lancement.
Tu peut peut etre charger en memoire uniquement les données et effectuer dynamiquement la creation des objets graphiques, initialisé selon ces donnees a l'execution ....

[EDIT] A mon avis pour le plus long est la requette sur un serveur BdD ...

J'avais pas pensé au coup du thread qui continu le chargement pendant que l'affichage commence ! Je crois que je tiens une solution adaptée, car en effet, dans un champ "liste des objets dépendants de moi" (facilement actualisable lors d'une nouvelle entrée dans la BD/fichier XML), j'ai l'info à savoir si l'objet est suceptible d'être encore affiché ou pas, et donc potentiellement, je peux gérer mieux le fait de le garder ou pas en mémoire.

Si "liste des objets dépendants de moi" contient une référence à l'objet X dans la liste : soit X est instancié et je peux lire son timecode et décider si je l'efface, soit il ne l'est pas, et donc forcément c'est qu'il n'a pas encore été affiché...

Bon il me manque plus que l'avis d'expert Java pour me dire à partir de quand on considère que la taille d'une applet n'est pas raisonnablement mettable en ligne. En effet, si c'est trop gros pour être mis en ligne, autant le faire dans un autre language... (Le problème est que j'ai du mal moi même à aprécier la taille du résultat, et du traffic généré)

Citation:

---

Si "liste des objets dépendants de moi" contient une référence à l'objet X dans la liste : soit X est instancié et je peux lire son timecode et décider si je l'efface, soit il ne l'est pas, et donc forcément c'est qu'il n'a pas encore été affiché...

---

Attention a une chose : Si A depends de B .. B Possede A dans sa liste des dependances. Donc a priori si A n'ets plus affiché, B Possede aucune dependance active .. donc s'efface. Mais si A est reaffiché plus tard ... B devra l'etre aussi. Donc est ce que tu as interet a l'effacer completement la premiere fois ?
Si c'est pour les garder present mais invisible ... pas d'interet a gerer un FIFO ou tout autre cache.

Citation:

---

Bon il me manque plus que l'avis d'expert Java pour me dire à partir de quand on considère que la taille d'une applet n'est pas raisonnablement mettable en ligne. En effet, si c'est trop gros pour être mis en ligne, autant le faire dans un autre language... (Le problème est que j'ai du mal moi même à aprécier la taille du résultat, et du traffic généré)

---

A mon avis tu ne te pose pas les bonnes questions ;)
Pour cequi est de la taille d'un fichier : 1Mo est une limite max a mon avis. Apres ca depends de la clientelle ciblée et de la vitesse de leurs connections.

Mais surtout : Ton application se doit elle d'etre integree dans une page Web ? ou bien la page web n'a d'existance que pour fournir un acces a l'application ?
Dans le 1e cas : Applet.
Dans le 2e cas, je preconise plutot un JAR autoexecutable, voir meme un deploiement par WebStart (jpnl je crois ;))
Mais bon la je ne connait pas trop la technique ....
Toutefois une version "applicative" de ton programme sera mieux car moins limitée.

Quand au choix BdD ou XML .... c'est juste une question de mise a jour et de clientelle ciblee.
Clientelle ne possedent pas forcement un acces internet ou ne souhaitant pas ouvrir une connection internet pour lancer l'application => XML
Sinon, BdD, pour une meilleur gestion des MAJ.
Par contre, tu perdra surement plus de temps et faudra que la BdD puisse supporter la charge .....

Ou alors : BdD+XML ;) avec un XML telechargé depuis une BdD (ou une URL d'ailleur) lors du lancement de l'applciation.

Citation:

---

Envoyé par Clorish

Attention a une chose : Si A depends de B .. B Possede A dans sa liste des dependances. Donc a priori si A n'ets plus affiché, B Possede aucune dependance active .. donc s'efface. Mais si A est reaffiché plus tard ... B devra l'etre aussi. Donc est ce que tu as interet a l'effacer completement la premiere fois ?
Si c'est pour les garder present mais invisible ... pas d'interet a gerer un FIFO ou tout autre cache.

---

Je n'ai besoin de la dépendance que pour un degré, je n'ai pas besoin du "grand père"

oué, si je me fie à tes conseils, moi ce serait plutôt un jar autoexecutable, j'en ai jamais fais, , mais il me semble que le code change pas des masses de toutes les façons.

Citation:

---

Envoyé par Clorish

BdD+XML ;) avec un XML telechargé depuis une BdD (ou une URL d'ailleur) lors du lancement de l'applciation.

---

Pour un jar executable, oué, ce serait le mieux ! faut que je vois ce qu'il y a comme possibilité avec un jar executable. (à vu de nez, ça serait moins visité, puisque pas directement accessible :o )

Faut que je relise mes contraintes perso, que je relise les réponses ici, que la nuit porte son conseil, voir si j'ai rien oublié, le problème me semblait tellement un montagne ce matin, ça m'étonne qu'une solution pointe déjà le bout de son nez :o

Citation:

---

Envoyé par Naeco

Je n'ai besoin de la dépendance que pour un degré, je n'ai pas besoin du "grand père"

---

Je n'ai pas parlé du grand pere ... ;)
Mais du fait que dans ton exemple, A dependant de B, si A est appelé plusieurs fois, tu devrais recharger B car il a ete dechargé lors du premier appel a A ..... Bref, connaitre les descendant d'un objet ne permet pas de savoir combient de fois ils vont etre utilisé, donc de savoir quand "liberer" B .... Desactiver oui ... mais pas liberer. Or c'etait la gestion de l'espace memoire et la creation de N objets qui posait problemes ...
:)

Citation:

---

Envoyé par Naeco

oué, si je me fie à tes conseils, moi ce serait plutôt un jar autoexecutable, j'en ai jamais fais, , mais il me semble que le code change pas des masses de toutes les façons.

---

Meme pas du tout ;)
Suffit de rajouter ce fichier manifest.mf (duement completé/corrigé) :

Citation:

---

Manifest-Version: 1.0
Created-By: 1.4.1_01 (Sun Microsystems Inc.)
Main-Class: monappli.Main
Class-Path: .

---

dans un repertoire "META-INF"
et de lancer la commande de compilation :

Citation:

---

jar cvfm monappli.jar META-INF/MANIFEST.MF <class>

---

Citation:

---

Envoyé par Naeco

Pour un jar executable, oué, ce serait le mieux ! faut que je vois ce qu'il y a comme possibilité avec un jar executable. (à vu de nez, ça serait moins visité, puisque pas directement accessible :o )

---

Absolument pas .... un JAR est un fichier zip renommé .... enfin en gros.
Quoi qu'il en soit, ca s'ouvre, et s'extrait sous winrar comme un simple rar ;)

Citation:

---

Envoyé par Naeco

Faut que je relise mes contraintes perso, que je relise les réponses ici, que la nuit porte son conseil, voir si j'ai rien oublié, le problème me semblait tellement un montagne ce matin, ça m'étonne qu'une solution pointe déjà le bout de son nez :o

---

C'est pas un sujet facile, mais c'est pas infaisable :)
Je suis a ta dispo pour toutes infos/Conseils .... tant que ca reste dans la conception :p
Pour la technique ya les autres ;)

Merci de vos propositions d'aides

ah oué non, je voulais dire, les gens ont comme un poil dans la main, alors si c'est pas direct sur une page, qu'il faut télécharger une appli, l'executer, ça va en rebuter plus d'un...

Oui, sinon, protéger le contenu du jar, j'y ai pas pensé, c'est pas faissable ?

Pour le reste c'est noté.

Je suis en train de me faire un diagramme UML pour tenter d'estimer un peu plus le truc...

Citation:

---

Envoyé par Naeco

Merci de vos propositions d'aides

---

De rien ... C'est toujours avec plaisir.
Puis faut rendre un peu l'aide qu'on a recu aussi ;)

Citation:

---

Envoyé par Naeco

ah oué non, je voulais dire, les gens ont comme un poil dans la main, alors si c'est pas direct sur une page, qu'il faut télécharger une appli, l'executer, ça va en rebuter plus d'un...

---

Oui ca je confirme .... :)

Citation:

---

Envoyé par Naeco

Oui, sinon, protéger le contenu du jar, j'y ai pas pensé, c'est pas faissable ?

---

ca, je suis preneur. Mais j'ai deja posé la question, et un CLASS n'est pas si facilement decompilable ... du moins pas plus qu'en exe. Donc quel interet a proteger un CLASS ?
Quand a charger un de tes class dans un exe et le manipuler ... sans doc, je lui souhaite bien du courrage :D

Citation:

---

Envoyé par Naeco

Je suis en train de me faire un diagramme UML pour tenter d'estimer un peu plus le truc...

---

C'est quoi "UML" ? C'ets pas une sorte d'aeroplane ? ;)

UML, c'est ça : http://fr.wikipedia.org/wiki/Unified_Modeling_Language

Bon mon utilisation est beaucoup plus modeste, mais ça reste très pratique, et propre quand on utilise un logiciel pour, comme StarUML (Open Source)

Un fichier class pas facilement décompilable????
Je doute vu la tripottée de décompilateurs qui existent sur le marché^^
Le reverse sur du bytecod c'est tout de même bien plus facile que sur du natif

Citation:

---

Envoyé par sinok

Un fichier class pas facilement décompilable????
Je doute vu la tripottée de décompilateurs qui existent sur le marché^^
Le reverse sur du bytecod c'est tout de même bien plus facile que sur du natif

---

Ha ... faudrais savoir :)
Parce que c'est pas ce qui m'a ete dit ici (post #7+). ;)

Citation:

---

Envoyé par naeco

UML, c'est ça : http://fr.wikipedia.org/wiki/Unified_Modeling_Language

Bon mon utilisation est beaucoup plus modeste, mais ça reste très pratique, et propre quand on utilise un logiciel pour, comme StarUML (Open Source)

---

Oui je connait bien UML .... ma question etait ironique, desolé ;)
Mais c'est justement parce que je connait .. que je supporte pas :D
De la a dire que c'est encore la faute des profs ....... ;)

En ce qui concerne la décompilation ce que j'ai dit n'est pas forcément en désaccord avec les posts de lautre topic.

L'obsfucation ne fait que mettre un bordel innomqable dans le code, et encore faut il déja l'appliquer. Car quand tu fais du javac monfichier.java, tu peux retrouver un code plus ou moins identique (contenant les noms de variables & ainsi de suite).

Dans ce cas, je suis aussi interesse par une technique de protection des programmes ecrit en java ....

Premier niveau l'obsfucation: ça rend le code décompilé pas franchement lisible. (de toute façon la protection ne fait que retarder la décompilation, ce n'est que le temps qui varie pour le hacker)

Deuxième niveau: Créer un classLoader sachant faire du décryptage et encrypter toutes tes classes.

http://www.javaworld.com/javaworld/j...pt.html?page=2

Bon je lirais ca mieux au calme :)
Mais ca a l'air hach'ment interessant !

Merci ;)