HOAB

History of a bug

Jinit Jinitiator Java7

Rédigé par gorki Aucun commentaire

Le problème :

Avec les vieilles versions d'Oracle Forms (10g2 - 10.1.2.0.2), un système existait pour remplacer le Java web start (JWS).. le Jinitiator (*fear !*).

Sauf que ce vieux système n'est plus maintenu. Donc rien ne se lance. Comme toujours une recherche donne des indices dont :

- réduire la version de Java

- Modifier Oracle Forms pour ne pas utiliser Jinitiator, c'est possible avec la 10g2 je crois

Mais comme par hasard, tout ça ne marche pas chez moi.

Solution :

Ce n'est pas simple... (testée avec la JVM 32bits 1.7.0_55-b13)

0) Activer la console Java pour tous les lancements, vérifier que vous avez l'erreur

ClassNotFoundException : oracle.forms.engine.Main

1) repérer où l'application Java est téléchargée... (Panneau de configuration -> Java -> Général -> PAramètres des fichiers temporaires -> Empalcement, exemple :

C:\Users\<user>\AppData\LocalLow\Sun\Java\Deployment\cache

2) Recherche l'archive de lancement dans les sous répertoires - un fichier de  1,151 Mo). C'est le fichier frmall_jinit.jar indiqué dans la source de la page de l'applet.

3) Surprise c'est un jar dans un jar ! Voilà pourquoi mon java ne pouvais pas lancer l'appli, une astuce Jinit...

3) Extraire le jar : forms.jar

4) Remplacer le fichier du cache par le fichier extrait forms.jar => Dans mon cas j'ai du remplacer ce fichier (conserver le nom du cache évidemment) :

C:\Users\<user>\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\0\2d74c040-2640a8d0

5) Actualiser la page et hop ! ça affiche quelque chose, mais ça plante encore... Eh oui, il y a une vérification de la version de Java dans la classe HTTPConnexion

oracle.forms.net.HTTPConnexion

6) décompilation, suppression du test, mise à jour du HTTPConnexion.class dans l'archive, recopie dans le cache, relance... easy ou presque.

 

A noter que cette astuce ne devrait pas servir souvent  :

  1. soit vous êtes admin et dans ce cas, modifiez votre configuration Oracle Forms pour utiliser JWS
  2. soit vous êtes un utilisateur courant et vous faites remonter le problème à votre admin
  3. sinon, comme moi, vous êtes utilisateur ponctuel et vous n'avez pas envie de réinstaller une VM XP Java 2 juste pour ça...

 

Cependant ça peut servir pour toutes les applets Java hein, un truc vous embête, modification, remplacement du cache et hop ça roule. C'est déjà utilisé couramment pour modifier les scores des jeux ^^ (java, flash ou autre)...

Personne ne trouve bizarre qu'un mec finisse un niveau en 0.1 seconde ou qu'un score grimpe à 999 999 999 ?!! :)

 

 

SimpleDateFormat - erreur/incohérence de parse - weekyear

Rédigé par gorki Aucun commentaire

Le problème :

SimpleDateFormat ne me retourne pas la date correcte :

        try {

            SimpleDateFormat sdf = new SimpleDateFormat("dd/MMM/YYYY:HH:mm:ss", Locale.US);
            Date date = new Date();
            String formatted = sdf.format(date);
            System.out.println(formatted); // 19/Jun/2013:13:31:16
            System.out.println(sdf.parse(formatted)); // Sun Dec 30 13:32:15 CET 2012
        } catch (ParseException e) {
            e.printStackTrace();
        }

Pas cohérent !

Solution :

Ce petit test est un bon moyen de vérifier votre formatter SimpleDateFormat.

1) vérifier la locale. C'est courant d'avoir une date à parser "01/Jun/2013" et de ne pas préciser la locale. Du coup SimpleDateFormat prend votre locale par défaut, souvent FR, et esssaiera de trouver le mot Juin, mais ça vous le verrez assez : erreur de parse, etc....

2)... et ça, la bêtise : il ne faut pas utiliser YYYY mais yyyy. cf documentation (nouveau depuis Java 7)

Au moins je suis pas tout seul : ici, surtout là

 

Donc :

SimpleDateFormat sdf = new SimpleDateFormat("dd/MMM/yyyy:HH:mm:ss", Locale.US);

 

Fil RSS des articles de ce mot clé