Pour des applis perso, éventuellement "données" à quelques
utilisateurs, disons du freeware mais sans ambition, j'utilise
généralement C++ (divers IDE/RAD) ou Delphi. Est-il raisonnable
d'envisager Java pour de tels utilitaires ? Je ne parle pas de
performances, ni même de mon usage personnel, je fais un .jar et ça
fonctionne très bien. Mais quelles sont les contraintes pour un
éventuel autre utilisateur ? J'imagine qu'il devra télécharger et
installer un JRE pour disposer d'une JVM si ce n'est déjà fait. A-t-on
une idée du taux d'installation de cet outil sur, par exemple, le parc
de machines Windows ?
Ma seconde question concerne une base de données locale et légère.
Utilisant par ailleurs MySQL (avec du Php), ce serait mon choix si
j'étais seul au monde. Mais il me semble que ça compliquerait les
problèmes de déploiement. Est-ce que Java DB est une meilleure solution
(il me semble que le moteur est dans un .jar que l'on peut mettre dans
le .jar unique) ?
Merci d'avance pour vos réponses, suggestions et liens ...
Pour des applis perso, éventuellement "données" à quelques utilisateurs, disons du freeware mais sans ambition, j'utilise généralement C++ (divers IDE/RAD) ou Delphi. Est-il raisonnable d'envisager Java pour de tels utilitaires ? Je ne parle pas de performances, ni même de mon usage personnel, je fais un .jar et ça fonctionne très bien.
Complètement, tu devrais trouver ton bonheur dans Java. J'ai un "background" de hardcore-développeur C/C++ et je peux te dire que Java... c'est que du bonheur ! D'ailleurs comme tu parles de "donner" tes petites "applis perso" à d'autres, plutôt que de parler "freeware" je t'invite à penser "logiciel libre". Par exemple le SGBDR hsqldb que l'on t'a conseillé... c'est un logiciel libre ! Tout comme MySQL et bientôt Java ! Penses-y :).
Mais quelles sont les contraintes pour un éventuel autre utilisateur ? J'imagine qu'il devra télécharger et installer un JRE pour disposer d'une JVM si ce n'est déjà fait. A-t-on une idée du taux d'installation de cet outil sur, par exemple, le parc de machines Windows ?
L'installation d'un JRE est aujourd'hui à la portée de tout le monde et cette "logique" se démocratise : Flash, .NET... Les utilisateurs commencent à en prendre l'habitude. Donc il ne faut pas considérer que l'installation d'une machine virtuelle Java posera problème aux utilisateurs. Il faut simplement leur indiquer que l'installation du logiciel nécessite qu'un JRE, comme celui de java.com par exemple, soit installé sur le système. C'est un peu le boulot d'un installeur automatique.
Ma seconde question concerne une base de données locale et légère. Utilisant par ailleurs MySQL (avec du Php), ce serait mon choix si j'étais seul au monde. Mais il me semble que ça compliquerait les problèmes de déploiement. Est-ce que Java DB est une meilleure solution (il me semble que le moteur est dans un .jar que l'on peut mettre dans le .jar unique) ?
Concernant MySQL, ce SGBD serait parfait si sa bibliothèque "Embedded MySQL Server Library" était disponible en Java, mais ça n'est pas le cas. On ne peut que l'utiliser dans une application C/C++. C'est sans doute possible en bidouillant de développer une application hybride C/C++/Java mais... Et installer un serveur MySQL et utiliser MySQL Connector/J pour s'y connecter, c'est pas franchement très conseillé. Je trouve qu'utiliser un serveur comme "base locale" n'est pas très judicieux. Après peut-être qu'en réfléchissant un peu plus c'est une solution envisageable...
Sinon dans la même veine que hsqldb il y a SQLite (http://www.sqlite.org). C'est un SGBDR développé en C mais on peut l'utiliser dans de nombreux langages grâce à ses nombreux "Sqlite Wrappers" (http://www.sqlite.org/cvstrac/wiki?p=SqliteWrappers), évidemment il y en a pour Java. Bon esprit, bonne communauté et bien documenté.
Comme dernière solution à envisager il y a aussi celles des SGBD XML... Mais ceci est une autre histoire :D.
JM.
Pierre Maurette wrote:
Pour des applis perso, éventuellement "données" à quelques
utilisateurs, disons du freeware mais sans ambition, j'utilise
généralement C++ (divers IDE/RAD) ou Delphi. Est-il raisonnable
d'envisager Java pour de tels utilitaires ? Je ne parle pas de
performances, ni même de mon usage personnel, je fais un .jar et ça
fonctionne très bien.
Complètement, tu devrais trouver ton bonheur dans Java. J'ai un "background"
de hardcore-développeur C/C++ et je peux te dire que Java... c'est que du
bonheur ! D'ailleurs comme tu parles de "donner" tes petites "applis perso"
à d'autres, plutôt que de parler "freeware" je t'invite à penser "logiciel
libre". Par exemple le SGBDR hsqldb que l'on t'a conseillé... c'est un
logiciel libre ! Tout comme MySQL et bientôt Java ! Penses-y :).
Mais quelles sont les contraintes pour un
éventuel autre utilisateur ? J'imagine qu'il devra télécharger et
installer un JRE pour disposer d'une JVM si ce n'est déjà fait. A-t-on
une idée du taux d'installation de cet outil sur, par exemple, le parc
de machines Windows ?
L'installation d'un JRE est aujourd'hui à la portée de tout le monde et
cette "logique" se démocratise : Flash, .NET... Les utilisateurs commencent
à en prendre l'habitude. Donc il ne faut pas considérer que l'installation
d'une machine virtuelle Java posera problème aux utilisateurs. Il faut
simplement leur indiquer que l'installation du logiciel nécessite qu'un JRE,
comme celui de java.com par exemple, soit installé sur le système. C'est un
peu le boulot d'un installeur automatique.
Ma seconde question concerne une base de données locale et légère.
Utilisant par ailleurs MySQL (avec du Php), ce serait mon choix si
j'étais seul au monde. Mais il me semble que ça compliquerait les
problèmes de déploiement. Est-ce que Java DB est une meilleure
solution (il me semble que le moteur est dans un .jar que l'on peut
mettre dans le .jar unique) ?
Concernant MySQL, ce SGBD serait parfait si sa bibliothèque "Embedded MySQL
Server Library" était disponible en Java, mais ça n'est pas le cas. On ne
peut que l'utiliser dans une application C/C++. C'est sans doute possible en
bidouillant de développer une application hybride C/C++/Java mais... Et
installer un serveur MySQL et utiliser MySQL Connector/J pour s'y connecter,
c'est pas franchement très conseillé. Je trouve qu'utiliser un serveur comme
"base locale" n'est pas très judicieux. Après peut-être qu'en réfléchissant
un peu plus c'est une solution envisageable...
Sinon dans la même veine que hsqldb il y a SQLite (http://www.sqlite.org).
C'est un SGBDR développé en C mais on peut l'utiliser dans de nombreux
langages grâce à ses nombreux "Sqlite Wrappers"
(http://www.sqlite.org/cvstrac/wiki?p=SqliteWrappers), évidemment il y en a
pour Java. Bon esprit, bonne communauté et bien documenté.
Comme dernière solution à envisager il y a aussi celles des SGBD XML... Mais
ceci est une autre histoire :D.
Pour des applis perso, éventuellement "données" à quelques utilisateurs, disons du freeware mais sans ambition, j'utilise généralement C++ (divers IDE/RAD) ou Delphi. Est-il raisonnable d'envisager Java pour de tels utilitaires ? Je ne parle pas de performances, ni même de mon usage personnel, je fais un .jar et ça fonctionne très bien.
Complètement, tu devrais trouver ton bonheur dans Java. J'ai un "background" de hardcore-développeur C/C++ et je peux te dire que Java... c'est que du bonheur ! D'ailleurs comme tu parles de "donner" tes petites "applis perso" à d'autres, plutôt que de parler "freeware" je t'invite à penser "logiciel libre". Par exemple le SGBDR hsqldb que l'on t'a conseillé... c'est un logiciel libre ! Tout comme MySQL et bientôt Java ! Penses-y :).
Mais quelles sont les contraintes pour un éventuel autre utilisateur ? J'imagine qu'il devra télécharger et installer un JRE pour disposer d'une JVM si ce n'est déjà fait. A-t-on une idée du taux d'installation de cet outil sur, par exemple, le parc de machines Windows ?
L'installation d'un JRE est aujourd'hui à la portée de tout le monde et cette "logique" se démocratise : Flash, .NET... Les utilisateurs commencent à en prendre l'habitude. Donc il ne faut pas considérer que l'installation d'une machine virtuelle Java posera problème aux utilisateurs. Il faut simplement leur indiquer que l'installation du logiciel nécessite qu'un JRE, comme celui de java.com par exemple, soit installé sur le système. C'est un peu le boulot d'un installeur automatique.
Ma seconde question concerne une base de données locale et légère. Utilisant par ailleurs MySQL (avec du Php), ce serait mon choix si j'étais seul au monde. Mais il me semble que ça compliquerait les problèmes de déploiement. Est-ce que Java DB est une meilleure solution (il me semble que le moteur est dans un .jar que l'on peut mettre dans le .jar unique) ?
Concernant MySQL, ce SGBD serait parfait si sa bibliothèque "Embedded MySQL Server Library" était disponible en Java, mais ça n'est pas le cas. On ne peut que l'utiliser dans une application C/C++. C'est sans doute possible en bidouillant de développer une application hybride C/C++/Java mais... Et installer un serveur MySQL et utiliser MySQL Connector/J pour s'y connecter, c'est pas franchement très conseillé. Je trouve qu'utiliser un serveur comme "base locale" n'est pas très judicieux. Après peut-être qu'en réfléchissant un peu plus c'est une solution envisageable...
Sinon dans la même veine que hsqldb il y a SQLite (http://www.sqlite.org). C'est un SGBDR développé en C mais on peut l'utiliser dans de nombreux langages grâce à ses nombreux "Sqlite Wrappers" (http://www.sqlite.org/cvstrac/wiki?p=SqliteWrappers), évidemment il y en a pour Java. Bon esprit, bonne communauté et bien documenté.
Comme dernière solution à envisager il y a aussi celles des SGBD XML... Mais ceci est une autre histoire :D.
JM.
Pierre Maurette
Merci général (la tournée, c'est pas possible, mais le coeur y est) pour vos informations.
Pour le déploiement, c'est tout bon. Web Start que je connaissais en tant que client, sur la doc en ligne de Sun, est le contraire de ce que je veux faire dans un premier temps. Mais c'est une possibilité intéressante.
Pour le SGBD(R) ce sera JavaDB/Derby ou HSQLDB. A cause du déploiement. Pour une utilisation personnelle, MySQL eut été plus logique, puisque je l'utilise déjà avec du Php et que je me suis farci le partage avec un poste Linux.
Bonne journée
-- Pierre Maurette
Merci général (la tournée, c'est pas possible, mais le coeur y est)
pour vos informations.
Pour le déploiement, c'est tout bon. Web Start que je connaissais en
tant que client, sur la doc en ligne de Sun, est le contraire de ce que
je veux faire dans un premier temps. Mais c'est une possibilité
intéressante.
Pour le SGBD(R) ce sera JavaDB/Derby ou HSQLDB. A cause du déploiement.
Pour une utilisation personnelle, MySQL eut été plus logique, puisque
je l'utilise déjà avec du Php et que je me suis farci le partage avec
un poste Linux.
Merci général (la tournée, c'est pas possible, mais le coeur y est) pour vos informations.
Pour le déploiement, c'est tout bon. Web Start que je connaissais en tant que client, sur la doc en ligne de Sun, est le contraire de ce que je veux faire dans un premier temps. Mais c'est une possibilité intéressante.
Pour le SGBD(R) ce sera JavaDB/Derby ou HSQLDB. A cause du déploiement. Pour une utilisation personnelle, MySQL eut été plus logique, puisque je l'utilise déjà avec du Php et que je me suis farci le partage avec un poste Linux.
Bonne journée
-- Pierre Maurette
Pascal Pizeine
"Jean-Marc Molina" a écrit dans le message de news: 447b27a1$0$24929$
Pascal Pizeine wrote:
Pour des procédures d'install, j'ai utilisé InstallAnywhere Standard Edition (c'est payant et je ne sais pas s'il y a un équivalent gratuit), c'est pratique.
Comme alternative libre il y a IzPack (<http://www.izforge.com/izpack>). Il est par exemple utilisé par MediaLibrary (<http://medialibrary.sourceforge.net>).
Ca permet de faire un programme d'installation qui contient ton programme et un JRE. Le programme d'install est un peu gros mais ça te permet de fournir un JRE compatible avec ton programme.
Il n'existe pas une option pour séparer le JRE de l'application ? Je vois pas l'intérêt d'embarquer la machine virtuelle dans la distribution : - Perte de place - Obsolescence de la distribution (Ancienne version du JRE)
On n'est effectivement pas obligé de fournir une JRE dans l'installation. Ca
permet quand même de fournir une JRE dont on est sur de la compatibilité avec l'application même si elle devient obsolète pour d'autres applications.
L'idéal serait un système qui téléchargerait automatiquement la dernière version d'un JRE choisi par l'utilisateur, celui de java.com par exemple. Vu le prix des éditions de InstallAnywhere ça doit forcément être possible. Peut être mais comme je fournis un programme d'installation pour des postes
qui n'ont pas forcément un lien avec l'extérieur, je n'ai pas cherché.
"Jean-Marc Molina" <jmmolina@PASDEPOURRIEL-free.fr.invalid> a écrit dans le
message de news: 447b27a1$0$24929$626a54ce@news.free.fr...
Pascal Pizeine wrote:
Pour des procédures d'install, j'ai utilisé InstallAnywhere Standard
Edition (c'est payant et je ne sais pas s'il y a un équivalent
gratuit), c'est pratique.
Comme alternative libre il y a IzPack (<http://www.izforge.com/izpack>).
Il
est par exemple utilisé par MediaLibrary
(<http://medialibrary.sourceforge.net>).
Ca permet de faire un programme d'installation qui contient ton
programme et un JRE. Le programme d'install est un peu gros mais ça
te permet de fournir un JRE compatible avec ton programme.
Il n'existe pas une option pour séparer le JRE de l'application ? Je vois
pas l'intérêt d'embarquer la machine virtuelle dans la distribution :
- Perte de place
- Obsolescence de la distribution (Ancienne version du JRE)
On n'est effectivement pas obligé de fournir une JRE dans l'installation. Ca
permet quand même de fournir une JRE dont on est sur de la compatibilité
avec l'application même si elle devient obsolète pour d'autres applications.
L'idéal serait un système qui téléchargerait automatiquement la dernière
version d'un JRE choisi par l'utilisateur, celui de java.com par exemple.
Vu
le prix des éditions de InstallAnywhere ça doit forcément être possible.
Peut être mais comme je fournis un programme d'installation pour des postes
qui n'ont pas forcément un lien avec l'extérieur, je n'ai pas cherché.
"Jean-Marc Molina" a écrit dans le message de news: 447b27a1$0$24929$
Pascal Pizeine wrote:
Pour des procédures d'install, j'ai utilisé InstallAnywhere Standard Edition (c'est payant et je ne sais pas s'il y a un équivalent gratuit), c'est pratique.
Comme alternative libre il y a IzPack (<http://www.izforge.com/izpack>). Il est par exemple utilisé par MediaLibrary (<http://medialibrary.sourceforge.net>).
Ca permet de faire un programme d'installation qui contient ton programme et un JRE. Le programme d'install est un peu gros mais ça te permet de fournir un JRE compatible avec ton programme.
Il n'existe pas une option pour séparer le JRE de l'application ? Je vois pas l'intérêt d'embarquer la machine virtuelle dans la distribution : - Perte de place - Obsolescence de la distribution (Ancienne version du JRE)
On n'est effectivement pas obligé de fournir une JRE dans l'installation. Ca
permet quand même de fournir une JRE dont on est sur de la compatibilité avec l'application même si elle devient obsolète pour d'autres applications.
L'idéal serait un système qui téléchargerait automatiquement la dernière version d'un JRE choisi par l'utilisateur, celui de java.com par exemple. Vu le prix des éditions de InstallAnywhere ça doit forcément être possible. Peut être mais comme je fournis un programme d'installation pour des postes
qui n'ont pas forcément un lien avec l'extérieur, je n'ai pas cherché.
Pascal Pizeine
"Jean-Marc Molina" a écrit dans le message de news: 447b2efc$0$24903$
Pierre Maurette wrote:
Mais quelles sont les contraintes pour un éventuel autre utilisateur ? J'imagine qu'il devra télécharger et installer un JRE pour disposer d'une JVM si ce n'est déjà fait. A-t-on une idée du taux d'installation de cet outil sur, par exemple, le parc de machines Windows ?
L'installation d'un JRE est aujourd'hui à la portée de tout le monde et cette "logique" se démocratise : Flash, .NET... Les utilisateurs commencent à en prendre l'habitude. Donc il ne faut pas considérer que l'installation d'une machine virtuelle Java posera problème aux utilisateurs. Il faut simplement leur indiquer que l'installation du logiciel nécessite qu'un JRE, comme celui de java.com par exemple, soit installé sur le système. C'est un peu le boulot d'un installeur automatique.
C'est vrai mais entre la JRE que tu installes et celles qui sont installées
par d'autres applis (en modifiant le Path), tu peux avoir quelques soucis. Sur mon poste de développement j'en ai trouvé pas loin d'une dizaine en recherchant sur le disque dur.
"Jean-Marc Molina" <jmmolina@PASDEPOURRIEL-free.fr.invalid> a écrit dans le
message de news: 447b2efc$0$24903$626a54ce@news.free.fr...
Pierre Maurette wrote:
Mais quelles sont les contraintes pour un
éventuel autre utilisateur ? J'imagine qu'il devra télécharger et
installer un JRE pour disposer d'une JVM si ce n'est déjà fait. A-t-on
une idée du taux d'installation de cet outil sur, par exemple, le parc
de machines Windows ?
L'installation d'un JRE est aujourd'hui à la portée de tout le monde et
cette "logique" se démocratise : Flash, .NET... Les utilisateurs
commencent
à en prendre l'habitude. Donc il ne faut pas considérer que l'installation
d'une machine virtuelle Java posera problème aux utilisateurs. Il faut
simplement leur indiquer que l'installation du logiciel nécessite qu'un
JRE,
comme celui de java.com par exemple, soit installé sur le système. C'est
un
peu le boulot d'un installeur automatique.
C'est vrai mais entre la JRE que tu installes et celles qui sont installées
par d'autres applis (en modifiant le Path), tu peux avoir quelques soucis.
Sur mon poste de développement j'en ai trouvé pas loin d'une dizaine en
recherchant sur le disque dur.
"Jean-Marc Molina" a écrit dans le message de news: 447b2efc$0$24903$
Pierre Maurette wrote:
Mais quelles sont les contraintes pour un éventuel autre utilisateur ? J'imagine qu'il devra télécharger et installer un JRE pour disposer d'une JVM si ce n'est déjà fait. A-t-on une idée du taux d'installation de cet outil sur, par exemple, le parc de machines Windows ?
L'installation d'un JRE est aujourd'hui à la portée de tout le monde et cette "logique" se démocratise : Flash, .NET... Les utilisateurs commencent à en prendre l'habitude. Donc il ne faut pas considérer que l'installation d'une machine virtuelle Java posera problème aux utilisateurs. Il faut simplement leur indiquer que l'installation du logiciel nécessite qu'un JRE, comme celui de java.com par exemple, soit installé sur le système. C'est un peu le boulot d'un installeur automatique.
C'est vrai mais entre la JRE que tu installes et celles qui sont installées
par d'autres applis (en modifiant le Path), tu peux avoir quelques soucis. Sur mon poste de développement j'en ai trouvé pas loin d'une dizaine en recherchant sur le disque dur.
Jean-Marc Molina
Pascal Pizeine wrote:
C'est vrai mais entre la JRE que tu installes et celles qui sont installées par d'autres applis (en modifiant le Path), tu peux avoir quelques soucis. Sur mon poste de développement j'en ai trouvé pas loin d'une dizaine en recherchant sur le disque dur.
Tu vois donc tout le problème d'embarquer un JRE à ses distributions. C'est justement parce que certaines applications installent leur propre JRE que ce genre de problèmes arrivent. L'objectif des JRE de Java, de Flash et de .NET c'est justement de séparer l'application de a techno qui en permet l'exécution. Je rencontre rarement le problème avec les applications Java car généralement celles que j'installe sont très pro et les installeurs proposent souvent de choisir le JRE après avoir détectés ceux qui sont installés. Par contre dans le cas d'applications GTK c'est vraiment l'enfer. J'ai deux applications : GIMP et Gaim. Mettre à jour l'un fait sauter la configuration de l'autre. Au point en Java on est à peu près assuré qu'un JRE conviendra à la majorité des applications à installer.
Donc c'est vraiment aux installeurs de bien faire leur boulot, pas aux applications d'emettre des hypothèses sur la configuration de l'utilisateur ou de bidouiller les JRE du système.
Pascal Pizeine wrote:
C'est vrai mais entre la JRE que tu installes et celles qui sont
installées par d'autres applis (en modifiant le Path), tu peux avoir
quelques soucis. Sur mon poste de développement j'en ai trouvé pas
loin d'une dizaine en recherchant sur le disque dur.
Tu vois donc tout le problème d'embarquer un JRE à ses distributions. C'est
justement parce que certaines applications installent leur propre JRE que ce
genre de problèmes arrivent. L'objectif des JRE de Java, de Flash et de .NET
c'est justement de séparer l'application de a techno qui en permet
l'exécution. Je rencontre rarement le problème avec les applications Java
car généralement celles que j'installe sont très pro et les installeurs
proposent souvent de choisir le JRE après avoir détectés ceux qui sont
installés. Par contre dans le cas d'applications GTK c'est vraiment l'enfer.
J'ai deux applications : GIMP et Gaim. Mettre à jour l'un fait sauter la
configuration de l'autre. Au point en Java on est à peu près assuré qu'un
JRE conviendra à la majorité des applications à installer.
Donc c'est vraiment aux installeurs de bien faire leur boulot, pas aux
applications d'emettre des hypothèses sur la configuration de l'utilisateur
ou de bidouiller les JRE du système.
C'est vrai mais entre la JRE que tu installes et celles qui sont installées par d'autres applis (en modifiant le Path), tu peux avoir quelques soucis. Sur mon poste de développement j'en ai trouvé pas loin d'une dizaine en recherchant sur le disque dur.
Tu vois donc tout le problème d'embarquer un JRE à ses distributions. C'est justement parce que certaines applications installent leur propre JRE que ce genre de problèmes arrivent. L'objectif des JRE de Java, de Flash et de .NET c'est justement de séparer l'application de a techno qui en permet l'exécution. Je rencontre rarement le problème avec les applications Java car généralement celles que j'installe sont très pro et les installeurs proposent souvent de choisir le JRE après avoir détectés ceux qui sont installés. Par contre dans le cas d'applications GTK c'est vraiment l'enfer. J'ai deux applications : GIMP et Gaim. Mettre à jour l'un fait sauter la configuration de l'autre. Au point en Java on est à peu près assuré qu'un JRE conviendra à la majorité des applications à installer.
Donc c'est vraiment aux installeurs de bien faire leur boulot, pas aux applications d'emettre des hypothèses sur la configuration de l'utilisateur ou de bidouiller les JRE du système.
Jean-Marc Molina
Pierre Maurette wrote:
Est-ce que Java DB est une meilleure solution (il me semble que le moteur est dans un .jar que l'on peut mettre dans le .jar unique) ?
Au passage je pense que l'article "Using Java DB in Desktop Applications" [1] de John O'Conner publié sur SDN en mars dernier devrait t'intéresser. Il présente le développement d'un carnet d'adresses sous NetBeans dont les données sont stockées dans une base locale Java DB.
Est-ce que Java DB est une meilleure
solution (il me semble que le moteur est dans un .jar que l'on peut
mettre dans le .jar unique) ?
Au passage je pense que l'article "Using Java DB in Desktop Applications"
[1] de John O'Conner publié sur SDN en mars dernier devrait t'intéresser. Il
présente le développement d'un carnet d'adresses sous NetBeans dont les
données sont stockées dans une base locale Java DB.
Est-ce que Java DB est une meilleure solution (il me semble que le moteur est dans un .jar que l'on peut mettre dans le .jar unique) ?
Au passage je pense que l'article "Using Java DB in Desktop Applications" [1] de John O'Conner publié sur SDN en mars dernier devrait t'intéresser. Il présente le développement d'un carnet d'adresses sous NetBeans dont les données sont stockées dans une base locale Java DB.
