Plop les bovins, comme vous avez pu le constater on aime bien mettre en avant de nouveaux projets et de nouvelles applications dans le coin, même si dès fois ils ou elles peuvent paraître un brin biscornu(e)s. Joeffice est un nouveau projet intéressant qui vise à fournir une suite bureautique légère, à même de pouvoir être utilisée sur des machines anciennes ou aux ressources limitées. Ce qui est intéressant dans ce projet, c’est qu’il n’a pas pour but de balancer un énième fork de LibreOffice ou d’autres softs du même type, mais qu’il constitue vraiment une alternative à part entière, dont le seul mot d’ordre est « légèreté. Parmi les aspects qui le caractérisent, on notera tout d’abord qu’il est publié sous licence Apache2 et multiplateforme GNU/Linux, Windows, Mac.
On notera ensuite qu’il est écrit en Java et qu’il propose un mode de travail prenant en compte la navigation par onglets, vous permettant ainsi de passer rapidement d’un document à un autre. On notera enfin qu’il peut être agrémenté de divers plugins mais que pour le moment, le bel animal ne prend en compte qu’un nombre de formats limités (dont ceux de MS Windows). Cela dit leur nombre devrait très vite augmenter et cela peut se comprendre dans le sens où ce projet est encore naissant. Il a moins de deux mois d’existence et pour info, la version actuelle a été codée en 30 jours seulement, par une seule personne.
Si vous avez envie de voir à quoi ressemble Joeffice, je vous invite à regarder cette petite vidéo qui va vous montrer tout ça en images.
Vous pouvez trouver plus d’infos sur le site officiel et aussi voir quelques captures décran sur cette page. Joeffice ne devrait pas tarder à sortir en version Alpha mais si vous êtes impatients, vous pouvez déjà vous procurer une version de développement du bel animal en vous rendant sur cette page, ou le tester en ligne (uniquement sur contribution 5€).
Je signale enfin à ceux qui chercheraient un projet dans lequel s’investir, que son développeur Anthony Goubard, cherche du monde pour l’aider. Alors si ça vous tente …
Amusez-vous bien.
Moo!
source
Un logiciel ne peut pas être léger et écrit en Java ce n’est pas possible :D
Je me faisais la même remarque… Que ce soit en charge comme en occupation mémoire, cela risque d’être assez rigolo :)
Je l’attendais cette remarque :D
Wait and see :)
En tout cas je ne peux pas vraiment voir si ça rame ou pas puisque le support famélique des type documents se limitent à docx… même pas un doc classique, un rtf et encore moins de l’odt, super !
Oui c’est sûr, mais bon, comme dit, le projet a moins de 30 jours ;)
Faire une suite Office Open Source qui gère des formats proprio et pas libre je trouve ça ubuesque.
Non, perso j’ai découvert le logiciel libre et plus tard GNU/Linux au travers des applications que j’avais installé sous Windows. Après avoir fait le tour des logiciels libres j’ai décidé de basculer entièrement.
Si tu cantonnes le logiciel libre au logiciel libre et basta, tu exclus des utilisateurs et au final on ne peut plus vraiment parler de liberté dans ce cas.
Je pense qu’assurer une certaine compatibilité est nécessaire, ne serait ce que pour promouvoir le libre. le contraire serait contre productif et stérile.
Je n’ai pas dit de faire du logiciel libre pour du logiciel libre, mais assurer les formats libre me semblent être un minimum sinon autant faire du proprio.
Ça je peux le comprendre, après si je me met dans la peau du développeur je peux comprendre ce choix techniquement.
Il a du tabler sur un seul format et choisir celui qui sera susceptible d’être le « plus compatible », pour poser une base « solide » avant d’intégrer les autres.
Si il avait commencé par intégrer des tas de formats ça aurait peut être été plus compliqué. C’est un postulat et ça reste discutable, mais ça peut se comprendre.
Le plus compatible c’est surement pas du docx. Les trois formats les plus courant pour du document c’est le .doc, le .rtf et le pdf. Le .doc étant quand même le minimum à faire pour une suite office.
On peut se poser la question en effet, mais là c’est au développeur qu’il faudrait s’adresser.
Les vieilles légendes ont la vie dure.
heuuu Désolé. moi avec mon i7, 16Go de ram et un ssd Java ça tourne du feu de dieu. <= ironie inside
Toute légende à sa part de réalité. En général je fuis les applications en java mais j'en utilise quelques une qui sont au dessus du lot et je peut t'assurer que cette légende est encore d'actualité.
Et moi je peux t’assurer que j’utilise des appli en C++ qui me bouffe plein de RAM, des appli en python qui bouffent plein de RAM etc.
Conclusion -> tous les langages de programmation bouffent plein de RAM =)
Oh bé si encore c’était une légende :)
En préambule, je suis développeur J2EE depuis prés de 15 ans. Dans l’intervalle j’ai un peu eu le temps étudié les performances des JVM sous toutes ses coutures. Et elle est définitivement très gourmande en ressources tant CPU que Mémoire.
À titre d’exemple, le garbage collector qui est le point névralgique de ce type de VM. Il y en a 4 sur la JVM, et aucun ne fonctionne sans bug et sans leak. j’ai ainsi de grosse installations Apache Solr que je suis obligé de redémarrer chaque nuit pour éviter la saturation mémoire.
Après en terme d’interface graphique (là on est dans la partie framework de Java, plus dans la JVM) c’est le souk dans le monde. AWT est totalement dépassé, Swing, surpuissant mais aussi très lent et surtout est incapable d’avoir un rendu « natif » fonctionnel. Reste SWT qui ne fait que ce que le projet éclipse veut bien lui faire faire.
Enfin tu as les temps de démarrage, traditionnellement très long. La raison est assez simple, la JVM va charger toutes les librairies (les .jar, des .zip en gros) et analyser avant de commencer à bosser. Ceci explique l’énorme différence de démarrage avec CLR/.Net.
Ce n’est d’ailleurs pas pour rien que la JVM a été ré-écrite pour android (dalvik) en utilisant une différente approche (machine à registres contre machine à pille).
En somme autant j’adore le langage Java qui pour moi est de loin le plus abouti de la famille C/C++, si j’avais à démarrer un projet cross-plateforme aujourd’hui, je m’orienterais plutôt sur haxe/necko.
Donc désolé mais les légendes ont parfois leur racine dans une réalité bien concrète. En tout cas si c’est une légende pour toi, tu dois avoir une meilleur expérience que la mienne, et donc je suis très intéressé par un coup de main sur du tunning de GC pour mon Solr qui plante :)
Argumenté comme ça c’est vrai que le bouzin prend du plomb dans l’aile (enfin dans Java).
Merci de m’expliquer comment fonctionne la JVM, mais je connais un peu.
Tu me parles de Solr pour me « prouver » que la JVM leak des ressources. WTF ? Je connais peu Solr, mais s’il conserve des « strong references » (désolé, je connais pas l’équivalent français), ben tu pourras faire tourner tous les algos de GC que tu veux, ça ne changera rien.
On pourrait coder une application qui bouffe toutes les ressources dans n’importe quel langage. Ça ne démontre absolument rien… Une fois, j’ai lancé photoshop, ça m’a bouffé toute ma RAM. Conclusion : C++ bouffe toute la RAM.
Quant au fait que Swing serait « lent », au mieux ça ne veut pas dire grand-chose, au pire c’est faux. C’est sûr que si tu fais tout un tas d’appels coûteux en temps dans les event handlers, tu vas avoir l’impression que Swing est lent. Sauf que ce n’est pas lui qui est lent, mais ton appli… Et puis, pour le rendu natif, ce n’est pas comme si ça avait une importance. On va prendre un exemple tout con que j’ai sous la main : Chromium n’a pas du tout un rendu « natif », il utilise son propre L&F (en fait, quasi aucune appli que j’utilise au quotidien n’a un rendu natif). Je ne pense pas que ça dérange grand-monde vu l’adoption de Chrome. Le truc, c’est que le rendu des composants Swing est relativement facile à personnaliser afin d’obtenir un rendu sympa, même s’il n’est pas natif. Mais pas mal de personnes préfèrent soit utiliser une librairie pour changer le look & feel, soit garder le rendu original, qui n’est pas terrible.
Oui, le JVM a un temps de démarrage assez long. Ca ne me semble pas rédhibitoire, vu le nombre d’appli pas écrites en Java qui ont de longs temps de chargement. Par ailleurs, si le temps de chargement est raisonnable (ce qui est le cas en Java si on ne fait pas n’importe quoi), il a rarement une importance pour une appli que tu vas lancer une fois pour toutes.
Java souffre de 2 problèmes :
– Les développeurs ont tendance à utiliser énormément de librairies, parfois pour faire des choses simples. En oubliant que ça a un impact sur les performances,
– Les développeurs ont tendance à complètement oublier l’aspect utilisation de la mémoire, parce que le GC est là, et que c’est censé être magique. Sauf que ça ne l’est pas.
Une application développée en Java avec l’idée de maximiser les performances aura de bonnes performances…
Merci pour l’information, je vais l’installer pour remonter les éventuels bug et faire avancer le projet.