Reprise du message précédent :

Si j'ai bien suivi, ça ne concerne que Java WebStart en Java 7. En tout cas, vu le peu de sérieux avec lequel Oracle a traité la question, ça va accélérer la migration vers C# dans les DSI.

Euuuuuuuh. Quelqu'un peut m'expliquer?

UTC+2 devient CEST (Central european summer time) sur windows et MEST (Middle european summer time) sur Solaris

Du coup j'ai un TU qui compare des toString() de dates, je suis fucké?

C'est la même timezone, MEST est un nommage obsolète pour la tz mais solaris power.
 
Accessoirement, c'est pas trop stable la transfo d'une tz statique en une tz nommée, en hivers ton truc va sortir eastern european time à la place.

Faut voir si tu peux pas normaliser tes timezones, ou bien re-transformer ça en statiques UTC

Ok, l'ennui vient du fait que le truc testé produit des String contenant des dates générées par Date.ToString(), lequel utilise un format "EEE MMM dd HH:mm:ss zzz yyyy" qui produit ce résultat incertain qui d'ailleurs n'est pas reparseable par SimpleDateFormat à moins d'être en Locale.US

Tiens autre truc marrant, sous solaris File.lastModified() a systématiquement les millisecondes à zéro

ya pas qqun (much?) qui cherchait un truc du genre récemment ? http://zvtm.sourceforge.net/index.html

Ouais ben t'es fucké complet, même en étant moins porcos que vous (parser la string, non mais , BTW, si vous voulez vraiment faire ça, vous avez probablement plus de chances avec le format normalisé http://fr.wikipedia.org/wiki/ISO_8601 ), utiliser Date pour tout ce qui est gestion de dates internationales, c'est se tirer une balle dans le pied. J'en sais qq chose, notre produit est en retard (en partie) à cause de ça. Je pensais que Calendar avait fini par être utilisable mais non, c'est tjrs aussi galère. On est donc en train de remplacer tous les Date et Calendar par des Joda DateTimes et des long. C'est le seul moyen d'avoir un truc qui fonctionne conformément aux attentes.

Au fait, le pb était simplement dû à deux occurences de la balise <entry-point/> dans le gwt.xml, probablement à cause d'un merge auto foireux.
Je me suis rendu compte que l'appli était lancée deux fois, et Chrome n'aime pas ça (mais FF ne bronche pas). Reste à rendre IE compatible pour être parfait, mais bon, c'est pas trop important pour nous.

Merci, ça m'a l'air pas mal du tout, surtout que ça gère une accélération OpenGL.

 
ouais, normalement tu peux avoir plusieurs entry point dans un module.
 
Ca doit plutôt être ce que faisait l'entry point qui posait problème à Chrome si c'était fait 2 fois.
 

écrire un brol qui ouvre le port 80 (ou un autre), qui écoute ce qu'il passe (protocole) , prend ce qu'il trouve sur l'input stream (string), tripote la data par la méthode et écrit sur l'output la réponse (string).

non ?

du coup chuis allé voir les nouveautés de jdk 7 (y'a effectivement des nouvelles choses sur les sockets), et je tombe là dessus:
http://docs.oracle.com/javase/7/do [...] vider.html
des retours sur ce truc ? C'est un remplacement plausible pour Commons VFS (ainsi que d'autres trucs qui ont implementé la meme chose, genre http://jackrabbit.apache.org/api/2 [...] stem.html)

bah tu m'étonnes que tu l'as simplifié, il fait tout pour toi
sorry, j'avais pas checké ce qui était dispo...

Je vais peut-être démarrer un projet extra-pro d'ici peu, possible que je sois pas le seul à bosser dessus.

Je veux un truc léger, aussi bien en terme de développement que de déploiement, écosystème Java, ça sera un portail web tout con. vous utilisez quoi pour ce genre de proto ?

J'aime beaucoup la mécanique de Jersey, mais je trouve ça assez peu adapté pour servir de la page web (cookies, sessions, redirections... ça tombe bien c'est pas fait pour ça). J'ai un peu tripoté Play! à l'époque de la version 1.x, c'est sympa aussi mais c'est vraiment une mécanique à part, plus proche de Rails, les éventuels développeurs si je suis pas seul venant tous d'un background JEE "classique". C'est malgré tout un candidat potentiel.

D'autres propositions (frameworks, modules) ? Je suis pas fermé à faire de l'assemblage du style un langage de templating, un FW REST et je sais pas quoi pour le BO si l'ensemble est cohérent et facile à maintenir.

Definis d'abord "portail web tout con".

C'est pour de l'associatif.
 
Édition du profil perso, gestion des droits basiques (comptes en lecture seule, admin...), un peu de news, des pages statiques et dynamiques, deux ou trois petits trucs spécifiques... gestion de mailing list et publipostage aussi, même si c'est un sujet à part.
 
On a pas mal autopsié CMS, portails et services en ligne, pour le même rien ne cadre vraiment (mais si on peut éviter le dev, on le fera, d'où le conditionnel dans ma demande de base).
 
Comme effectivement j'aurais peut-être pas le besoin (mettons qu'on trouve le CMS qui colle), la question peut se résumer à "quels outils pour du web light en Java ?"

Ok, donc ce n'est pas un portail dans le sens "on a des portlets independants qui ont leur propre cycle de vie".
 
Dans la categorie CMS, tu peux regarder XWiki. Je sais, c'est un wiki, mais tu peux faire en sorte que cela ne se voit plus.
 
Sinon, vu le peu de besoin en dynamique que tu indiques, Play (1 ou 2) ne t'apportera pas grand chose en plus face a une stack JavaEE 6.

Je jetterais un oeil sur XWiki. je suis également tombé pendant mes recherches sur DropWizard, qui à l'air plutôt prometteur.

Moi je dirais Grails mais bon je suis pas totalement impartial sur ce coup la (même si ça reste le meilleurs framework Web du moment   )

 
Jamais essayé, à voir. Si j'ai arrêté Rails pour le dev' perso parce que ça me sortais par les trous de nez, tu penses que c'est un conseil valable ?
 

Qqun a de l'expérience avec Chef ici ? En particulier pour le déploiement d'applis (web) Java, bien sur.

C'est quoi qui t'as gavé dans Rails ? Comme ca je pourrais te dire si tu retrouveras ça dans Grails

 
Peut-être de mauvaises raisons, pour le contexte j'y ai un peu touché entre la 2.1 et la 2.3.
 
Le gros moins pour moins, c'était le côté "magic" qui était mis en avant. Sur le principe ça me dérange pas si on me donne les infos sur la tuyauterie qu'il y a derrière. La doc est bonne tant que tu ne sors pas du cadre pour laquelle elle a été rédigée, et la doc de l'API est vraiment imbitable et pas à jour (ça n'engage que moi).
C'est une remarque plus générale que la simple doc d'ailleurs, j'ai trouvé le FW vraiment chiant dés qu'on sort du cas "convention over configuration", qui est souvent nécessaire et trop peu documenté.
 
Le second point, c'est l'environnement Windows et les plugins et le bordel de versions. Je dev sous Windows, que ce soit bien ou pas, et parfois derrière un proxytaff. Les utilisateurs de cet OS sont clairement mis à l'écart, les install marchent uns fois sur deux, les gems sont compatibles sous une bardée de conditions... Je trouve que les plugins et API ne sont pas documenté et souvent pas à jour, ou spécifiques a une version très ciblées de Rails / Ruby / whatever, genre au numéro de build près. Et le gap Ruby 1.8.x / 1.9.x   ca engendre tellement de saloperie que je ne comprend même pas pourquoi y'a pas de changement de numérotation majeure, ou plus de restriction quant aux versions de Rails supportées par chacun.
 
Le reste est mineur et certainement dû à mon manque d'expé sur le sujet, donc je détaille pas.
 
Disclaimer après la bataille : c'est une expérience et un avis perso, en aucun cas un avis éclairé ni même à prendre en compte vu mon manque de (bonne) pratique sur le sujet.
 

 
Coté "magic", Grails risque peut être de te déranger également. Mais sortir des conventions est assez simple, d'autant plus si on a un minimum de connaissance de la stack Spring/Hibernate.  
Coté doc, ils se sont beaucoup amélioré et la mailing list est aussi bien réactive.
Coté OS, il n'y pas de soucis à priori.
Coté version, il y a eut un léger gap entre la 1.3.7 et la 2.0 mais si tu commences, tu prendras tout de facon la 2.0 (voir 2.1)

OK. J'utilise pas Spring mais je pense pas que ça soit dérangeant. Groovy m'embête un peu plus vu que j'avais commencé Scala, mais ça devrait être jouable également.
Je jetterais peut-être un œil à l'occasion, merci de ton retour détaillé
Contributeur j'imagine ?

Contributeur de plugins essentiellement mais vu que je pars travailler chez la "concurrence" (red hat/JBoss) je vais beaucoup moins contribuer je pense.

J'ai un soucy avec le gwt-maven-plugin (v2.4.0), qui ne met pas forcément à jour le Javascript généré: une modif du code source Java n'est pas reflétée dans le Javascript (bien que la compilation se soit bien passée après un mvn clean). Ca ne le fait que sous Linux en ligne de commande, la compile sous eclipse se passe bien. Je vois bien des fichiers statiques temporaires être créés puis supprimés sous /tmp, mais je ne sais pas où sont créé les .js temporaires. Des idées ?

un petit "mvn clean install -x" te donne pas plus d'infos ? Sous eclipse ca utilise aussi le plugin maven ?

Hello les djeunzs !    
 
J'aimerais me lancer dans la programmation Java notamment pour développer des applis sous Android.
 
Je bosse dans l'informatique mais je n'ai pas programmer depuis des années.
J'ai surtout touché à des "vieux" langages PL1, Cobol et un peu de smalltalk (objet)
 
Remettre les mains dans le code ne me fait pas peur, mais je ne sais pas comment démarrer.
 
J'ai vu qu'on parle de l'environnement Eclipse pour développer.
 
 
Pouvez vous me conseiller de bon tuto, DL, livres pour apprendre au plus vite ?
Y'en a tellement sur ce sujet qu'on ne sait pas quoi attaquer.
 
Merci    

java - vm - monitoring - toussa...  
combien ça coûte en ram un file descriptor sur un linux 64bits ?
 
paske là j'ai des serveurs avec théoriquement 3.5GB de RAM de libre et dans les faits, il leur en reste 300MB... je cherche donc les coupables (entre les native threads comme les gc, les file descriptor, ...)

3.5gb de ram physique ou allouée à ta jvm? Oublie pas que le GC va pas collecter si y'a pas besoin...,

C'est un host avec 8GB de RAM, il reste théoriquement 3.5GB physique après addition des diverses Xmx et PermGen (4 jvms sur ce host)
 
Ces 3.5GB qui restent devraient être suffisants pour faire passer les native threads mais j'arrive à sec régulièrement.
 
Ca ne me dérange pas que le GC ne passe pas car le host a suffisamment de mémoire physique pour avoir les 4 JVMs full packed sans swapper.  
 
Je sais que le GC bouffe pas mal à côté de heap/permgen en fonction de la charge user mais une des JVMs bouffe dans les 5500 fichiers ouverts (pas de leak, c'est monitoré) juste à cause de ses 40 apps déployées.
 
D'où la question sur le coût d'un FD.

Oups désolé, j'ai pas vu ta réponse. Pas encore essayé le -x<; oui sous eclipse on builde aussi avec maven (et heureusement qu'il fonctionne, lui, sinon on n'aurait pas pu livrer).

T'as qu'à écrire un prog qui ne fait qu'ouvrir des tas de fichiers et voir ce qui se passe avec top/htop.

 
 
Je pense que pour toi, le mieux est de passer par un bouquin sur le dev Android.
Et après mets toi à java sur des cas concrets.
 
Perso j'ai un Eyrolles, mais t'as une liste là http://android.developpez.com/livres/
 
 
Et après seulement, une fois que ton environnement de dev est monté, commence à te poser des questions sur comment faire ci, comment faire ça.
Ne te laisse pas impressionner par l'étendue et la diversité des API ou bibliothèques : en Java les choses changent souvent de nom...  

Bon, au final, il suffisait de faire un mvn gwt:clean, encore fallait-il le savoir...

Je veux afficher une date UTC en fonction de la TZ système, et j'ai l'impression que ledit système ne prend pas en compte la DST, il me manque une heure.
 
Genre à l'arrache :
 

private static void utc(final String utcTime) throws ParseException {
        System.out.println("Raw UTC time: " + utcTime);
        final SimpleDateFormat parseTimeFormat = new SimpleDateFormat("HHmmss.ss" );
        parseTimeFormat.setTimeZone(TimeZone.getTimeZone("GMT" ));
        final Date time = parseTimeFormat.parse(utcTime);
        final SimpleDateFormat displayTimeFormat = new SimpleDateFormat("HH:mm:ss" );
        displayTimeFormat.setTimeZone(TimeZone.getTimeZone("GMT" ));
        System.out.println("TZ is " + displayTimeFormat.getTimeZone().getDisplayName() + " time is " + displayTimeFormat.format(time));
        displayTimeFormat.setTimeZone(TimeZone.getDefault());
        System.out.println("TZ is " + displayTimeFormat.getTimeZone().getDisplayName() + " time is " + displayTimeFormat.format(time));
        displayTimeFormat.setTimeZone(TimeZone.getTimeZone("Europe/Paris" ));
        System.out.println("TZ is " + displayTimeFormat.getTimeZone().getDisplayName() + " time is " + displayTimeFormat.format(time));
        System.out.println("DST value: "+displayTimeFormat.getTimeZone().getDSTSavings());
        System.out.println("DST enabled?: "+displayTimeFormat.getTimeZone().useDaylightTime());
    }

 
Je rate forcément quelque chose, mais quoi ? C'est aussi de la curiosité, donc Joda Time n'est pas une réponse valide

Essaye avec UT au lieux de GMT
EDIT ou UTC tiens