Discussion :

[lil_jam63]

Salut, je suis en train de me mettre gentillement au dev de jeux sous J2ME et je commence deja à avoir un soucis de taille, pour l'instant c'est une MIDlet pas trop compliqué, qui se contente d'afficher une image dès le démarrage avec en accompagnement une ambiance musicale, j'utilise pour ça un PNG de 54.9 Ko et un WAV de 2.34 Mo et pourtant je me retrouve avec un Jar de plus de 5 Mo même si je supprime la partie musique, est ce normale ??? Mon projet comporte 2 classes, l'une de 200 lignes et l'autre de 50.
Je suis partis sur l'idée que seul ce qui est utile est importé comme delphi et je fais plusieurs import

la classe principale

Code :

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

1
2
3
 
import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;

et l'autre

Code :

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

1
2
3
4
5
6
 
import javax.microedition.lcdui.*;
import javax.microedition.media.*;
import javax.microedition.media.control.*; 
import java.io.*;
import java.util.*;

est ce que cela peut en être la cause? Si oui comment est ce que je peux optimiser cela.

[Pill_S]

est ce que cela peut en être la cause?

non je ne pense pas, les importations en java ne sont pas identiques à celles de C/++. En fait les imports n'incluent pas les classes, mais pointent vers d'autres classes de la JVM, donc que tu les mette ou pas la taille de ton prog ne changera (presque) pasé. (bon peut-être que ça change pour J2ME mais ça m'étonnerait)

comment est ce que je peux optimiser cela.

en n'important que les classes réellement utilisées et pas les paquages complet

ex:

Code :

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

1
2
3
4
 
import javax.swing.JFrame; // au lieu de import javax.swing.*;
 
class MaClasse extends JFrame{}

mais bon cela n'aura aucune influence sur la taille du jar, donc la question reste ouverte....

peut-être qu'il faudrait essayer de faire le jar "à la main": tu crée une archive zip contenant un répertoire META-INF et le fichier manifest, et uniuement tes fichier nécessaire. La taille devrait sensiblement baisser

[waddle]

donne nous la ligne qui construit ton jar (si c pas dans un IDE).

de toute manière un jar n'est qu'un zip "bien formé" dc le mieux c de faire unzip -d monappli/ monjar.jar et de regarder ce qu'il contient exactement avec un petit
ll -R ./monappli

y a pas de secrets, les octets ca se créé pas tout seul ;-)

waddle

--
EPITA Student
Promo 2006

[lil_jam63]

Merci de ta réponse, je viens de faire des essais en important seulement ce dont j'avais besoin et la taille reste toujours la même, j'ai supprimé la partie sonore qui étais la plus lourde et cela n'a strictement rien changé.

@Waddle
J'utilise KToolbar pour créer mon package, sinon je vais essayé de décompresser le jar comme tu l'explique et je te tiens au courant.

[lil_jam63]

ok, je comprend mieux, en fait j'ai décompresser avec winrar et je me retrouve avec tous les fichiers qui se trouve dans le repertoire ressource du projet, je pensais que seul ce qui étais utilisé étais importé dans le package mais apparement non. Apres avoir supprimé ce qui étais inutile, j'ai une taille correcte.

Merci de votre aide.

[waddle]

ok c un tres bon outil ca tombe bien.

as-tu essayé de faire un clean avant de créer ton package, ca efface les fichiers class temporaires pour ca dan KToolBar va dans Project>clean

ensuite tu peux créer ce qu'on appel un package épuré (obfuscated package en anglais) qui te donnera un jar plus petit (je t'explique pas comment ca marche, d'ailleur on s'en fou, mais si tu veux des infos google est ton ami), pour cela choisis un outil qui traite ton code et qui est reconnut par KToolBar (com proguard @ proguard.sourceforge.net) et va dans project>package>create obfuscated package.

waddle

avec tout ca et en dézippant ton jar pour voir ce qu'il a, tu devrais finir par avoir un tout petit jar.

ps: pour les import, Phil_s a raison, les imports en Java sont en fait des définitions de nom pour la compilation et en aucun cas des include com en c++ qui eux, copie-colle le code. Ces noms permettent au compilo de vérifier que les types, les cstes , etc.. existent bien. A l'execution, cela permet a la VM de savoir ou se trouve le code a executer quand tu appel une methode par exemple.

--
EPITA Student
Promo 2006

[waddle]

bah désolé mais je peux pas trop t'aider ca fais un bail que je l'ai plus utilisé et pour tout dire je l'ai installer qu'un fois dc je me souviens pas trop comment j'ai fais.

en tout cas il te reste le site de SUN pour KToolBar:
http://java.sun.com/j2me/docs/wtk2.1/user_html/ch_ktoolbar.html

et pour proguard, j'avais du trouver la soluce dans la doc (a moins que ce soit ds un forum... ;-))

enfin si j'ai trouvé, nul doute que tu trouvera aussi.

en tout cas avec KToolBar tu commence bien... :-D

waddle

--
EPITA Student
Promo 2006

[lil_jam63]

Merci pour ton aide, je viens de telecharger proguard et j'ai créé un obfuscated package qui effectivement est plus petit, ce sont des choses à savoir, surtout quand on est limité en taille.

Je commence juste la java et KToolbar donc j'ai pas forcement saisi quelques trucs.