Archive

Posts Tagged ‘java’

Compiling nestedVM on Ubuntu 10.04 (Lucid Lynx)

2 septembre 2010 1 commentaire

nestedVM is a cool tool for translating running c/c++ code into java bytecode. I tried to follow the little tutorial that
can be found at http://wiki.brianweb.net/NestedVM/QuickStartGuide, but there were many problems with my favourite distro

Here is how i finally managed to compile the tool, and the mips cross compiler that comes with it :

1) check you own the following packages :
sudo apt-get install openjdk-6-jdk curl darcs texinfo g++

2) get the latest nestedVM release,

curl http://nestedvm.ibex.org/dist/nestedvm-2009-08-09.tgz > nestedvm-2009-08-09.tgz
tar -zxvf nestedvm-2009-08-09.tgz

3) arghh the old version of binutils that is used by default produces crashing executables, you’ll have to tell the
makefile that you want the latest one instead (binutils 2.20.1).

sed -i 's/version_binutils = 2\\.6/version_binutils = 2\\.20\\.1/'  ./nestedvm-2009-08-09/upstream/Makefile

4) as we changed the version for binutils, one of the provided patch do not work anymore

echo '' >  ./nestedvm-2009-08-09/upstream/binutils-no64.patch

5) the url for one file is outdated. In upstream/Makefile, I had to download it manually, and then replace the url_regex property in upstream/Makefile with
the pseudo-url of the manually downloaded file : url_regex = file:///home/julien/Telechargements/regex3.8a.tar.gz

TIP : During the installation, the makefile tries to download newlib from redhat ftp, which is REAL SLOW,
so gave up and tried an http mirror : In the file ‘upstream/Makefile’, I replaced ftp://sources.redhat.com/pub/newlib/
by  http://www.mirrorservice.org/sites/sourceware.org/pub/newlib/

TIP : If something fails during download, you’ll have to manually remove one of the files that were created
in the ./nestedvm-2009-08-09/upstream/tasks directory before relaunching make. removing the corrupted tar is not sufficient.

6) use the following make command, instead of simply typing ‘make’ :
cd ./nestedvm-2009-08-09/upstream && make CC='gcc -D_FORTIFY_SOURCE=0'

7) at the beginning of the compilation, you may have a complaint about a patch that was already applied. Just skip it (type y)

6) Wait a bit, have a coffe. or two.

When it’s over, you’ll have the mips-* tools compiled gently, you can follow the end of the initially suggested procedure

Publicités
Catégories :Uncategorized Étiquettes : , , ,

Gestion des exceptions en java…

Je déteste le système des exceptions en java, je le trouve lourd et inadapté aux problèmes de la vie réelle : aprés tout, si on développe un programme, c’est pour qu’il fasse des trucs, et par pour qu’il gère des exceptions ! Le paradoxe c’est que si on s’y prend mal, on finit par avoir du code source qui passe plus de temps a gérer des try/catch qu’a faire de vraies choses !

Voici un mémo que j’ai écrit il y a déja un certain temps concernant mon point de vue sur toutes ces questions :

En Java, une distinction est faite entre :

  • les exceptions déclarées dans la signature d’une méthode (CheckedException en Java) ; par exemple
   void foo () throws ThisExceptionType { ... },
  • les exceptions à l’exécution (RuntimeException en Java), qui correspondent à des évènements impossibles à localiser lexicalement à la compilation (les exceptions asynchrones), ou pouvant survenir à tout moment dans l’exécution du programme, comme les problèmes d’allocation mémoire. Il n’est pas nécessaire de déclarer ces exceptions (par exemple, NullPointerException, OutOfMemoryException etc…)

Les « checked exceptions » (i.e les exceptions qui héritent de java.lang.Exception) essayent de résoudre un problème de contrat. L’interface d’un module (d’une bibliothèque de classes) représente un contrat entre l’auteur du module et son utilisateur : l’argument est qu’un tel contrat ne devrait pas passer sous silence les exceptions susceptibles d’être propagées hors des frontières du module.

En spécifiant les exceptions dans les signatures des méthodes, on introduit toutefois un problème. En effet, les méthodes clientes doivent choisir dans l’alternative :

  • installer un gestionnaire d’exception (bloc try/catch pour les exceptions du module, ou bien
  • déclarer à leur tour qu’elles sont susceptible de lancer ces exceptions.

Les méthodes utilisant des checked exceptions contaminent leurs clients avec l’obligation de décorer leur signature s’ils n’installent pas de gestionnaire pour ces exceptions. Cette contamination trahit en partie le contrat d’indépendance entre le lieu du signalement d’une exception et le lieu de son traitement, en exposant toutes ces déclarations d’interfaces dans le chemin d’appel ; en somme elles nous ramènent aux inconvénients des langages de programmation sans SGE (transmission de l’exception par une valeur de retour spéciale, prévue en tout point de la chaîne d’appels). A l’opposé Les « checked exceptions » violent finalement la philosophie des exceptions (la non-localité entre le lieu du signalement du problème et le lieu de son traitement).

Du coup, la bibliothèque standard de Java utilise en pratique des runtime exceptions pour les opérations les plus triviales (arithmétique, collections, allocation mémoire) afin éviter la pollution lexicale des checked exception.

Donc en résumé :

  • Si on déclare ses méthodes « throws … », on force l’utilisateur a gérer l’erreur, ce qui alourdit le code, (multiplication des type d’exception a déclarer, catcher, etc)
  • Si on lance une exception non checkée, on risque de lancer des erreurs qui ne seront pas traitées correctement, mais on rend l’api plus simple.
  • Une exception checkée est plutot causée par une erreur de contexte (fichier manquant, imprimante pas prète, etc..) -> elle se résoud en changeant l’environnement d’éxecution du programme.
  • Une exception non checkée est plutot causée par une erreur de programmation pointeur null, division par zero, threads pas synchronisés, etc… -> Elle se résoud en corrigeant son programme.

Ce que j’ai vu :

throws Exception (ou « ma méthode plante des fois »)

Certains d’entre nous déclarent leurs méthodes comme « throws Exception », ce qui sémantiquement NE VEUT RIEN DIRE, on oblige juste l’utilisateur de sa méthode à l’encadrer d’un bloc try/catch, qui ne pourra rien faire d’intéressant si on ne connait pas la nature de l’erreur.. donc :

  • regle 1 :’ bannir throws Exception, on a le droit de lancer des exceptions non checkées

des print dans les catch

   catch(Exception e)
   {
      e.printStackTrace();
   }
  • 1) la console n’est pas une poubelle. La tradition veut qu’on utilise la sortie d’erreur standard d’un programme pour tracer les erreurs : Donc dans l’absolu :
e.printStackTrace(System.err)

Mais cela n’est pas trés important puisque :

  • 2) De toute façon, personne ne lit la console, surtout quand l’application est hébergée sur un serveur ! Donc utiliser un service de log (log4j) – Rechercher systématiquement les println dans le code source en fin de développement, afin de les éradiquer.
  • 3) faire juste un print n’est pas un traitement d’exception, c’est un constat d’impuissance. Si l’erreur va provoquer un plantage ailleurs, ou si tout simplement la méthode ne fera pas ce qui lui a été demandé a cause de cette erreur, il faut relancer une exception !! Soit en la transformant en une autre exception lancée explicitement par la méthode courante, Soit en relancant une exception non checkée (new RuntimeException(e), new IllegalArgumentException(e), NotImplementedException, etc.. etc…) Soit en ne la catchant pas !!!
  • 4) Si gestionnaire d’exception il y a (pour informer l’utilisateur, par exemple), il doit pouvoir être en mesure d’attraper le plus d’exceptions possibles, donc éviter de réinventer la roue carrée a longueur de temps ! par la peine de se fatiguer a faire de « catch print » partout, si de toute façon l’erreur pourrait être mieux gérée en amont par du code écrit exprès !

Comment je vois les choses :

Une solution en valant une autre, j’ai décidé de m’appliquer des conventions dans mon style de codage, et je vous invite a faire comme moi !

  • REGLE 1 : throws Exception n’est pas mon ami – éviter les throws n’importe quoi
  • REGLE 1 : Lancer des exceptions non checkée n’est pas un crime, surtout quand l’erreur est une erreur de programmation, (et pas de runtime) – si il ne tenait qu’a moi, la plupart des exceptions devraient être unchecked.
  • REGLE 3 : pas de gestionnaires sauvages, pas de gestionnaires longs (pas plus de 3 lignes), pas de gestionnaire qui font des trucs « métier », en particulier pas de print, pas d’envois d’email dans un catch (comme je l’ai déja vu…), etc…
  • REGLE 4 : Relancer une erreur (quitte a la rendre unchecked) plutot que de la gérer mal (en faisant un print)
/** Service "clients" - manipulation de l'entité "client" */
public class ClientServiceImpl extends JpaDaoSupport implements ClientService {

    /**
      *  Obtenir un client en fct de son id
      *  @param id un code client
      *  @return une instance de Client, ou null si pas trouvé.
      *  @throws RuntimeException quand une erreur empèche l'accés au données.
      */
    @Override
    @CacheResults(cache="clientServiceCache", maxAge=2000)
    public Client getClientById(int id)
    {
        try
        {
            return getJpaTemplate().find(Client.class,id);
        }
        catch(DataAccessException e)
        {
            //getLogger().error(e);//optionellement, on loggue, mais ça n'est vraiment pas obligatoire
            throw new RuntimeException(e);
        }
    }
}
Catégories :Uncategorized Étiquettes : , , ,

Do you know JFastCGI ?

JFastCGI est un projet sous licence BSD démarré il y a quelques mois maintenant. Le but est de permettre a un container de servlet (type tomcat ou jetty) de servir des pages générées par une application compatible fastCGI.

Cela permet par exemple de servir des pages PHP interprétées par le moteur PHP officiel sans avoir a utiliser un serveur apache.

La version 1.1 est « en prod », et la version 2.0, qui introduit la notion de pool de connexion entre une application tomcat et plusieurs « serveurs » fastcgi est en cours de tests (j’en ai profité pour créer un ensemble de tests unitaires, utilisant mockrunner). Elle permettra un énorme gain de performance pour les applications fortement sollicitées !

La version 2.0 ajoute aussi une meilleur intégration avec Spring, en implémentant HttpRequestHandler.

Des contacts ont même étés pris avec l’équipe de développement de Glassfish, dont jfastcgi pourrait devenir un module optionnel de la version 3 …

Bref, cette librairie semble promise a un bel avenir, et permet d’utiliser les serveurs en java de manière moins « fermée » mais ce projet demande à gagner en maturité, votre aide est la bienvenue !

EDIT : un post sur le blog de Cay Horstmann sur java.net

Support This Project

Catégories :Uncategorized Étiquettes : , , , ,

How to expose Spring beans as GWT rpc services

25 septembre 2009 Laisser un commentaire

1) create this servlet :

public class GWTRPCServlet extends RemoteServiceServlet {

	private static final long serialVersionUID = 8940035753925233840L;

	private ApplicationContext applicationContext;

	@Override
	public void init(ServletConfig config) throws ServletException {
		super.init(config);
		applicationContext = WebApplicationContextUtils.
          getRequiredWebApplicationContext(config.getServletContext());
	}

	@Override
	public String processCall(String payload) throws SerializationException {

		try {
			// find service using URI

			String serviceName = getThreadLocalRequest().getRequestURI()
					.replaceAll(".*/([^/]+)\\.rpc$", "$1");
			Object service = applicationContext.getBean(serviceName);

			// decode request
			RPCRequest rpcRequest = RPC.decodeRequest(payload, service
					.getClass());

			// invocation
			return RPC.invokeAndEncodeResponse(service, rpcRequest.getMethod(),
					rpcRequest.getParameters());
		} catch (Exception e) {
			return RPC.encodeResponseForFailure(null, e);
		}
	}
}

2) declare this servlet in your web.xml to catch all the requests that end with « .rpc »:

	<servlet>

		<servlet-name>GWT-RPC</servlet-name>

		<servlet-class>com.elosystemes.gwt.GWTRPCServlet</servlet-class>

	</servlet>

	<servlet-mapping>

		<servlet-name>GWT-RPC</servlet-name>

		<url-pattern>*.rpc</url-pattern>

	</servlet-mapping>

3) when you declare a service client in GWT, use the spring bean name + « .rpc » as the remote path of the service, just as above :

@RemoteServiceRelativePath("remoteService.rpc")
public interface HelloworldService extends RemoteService {
     public void hello(String name);
}

4) on server side, just declare the implementing bean as usual in your application context :

  @Service("remoteService")
  public class HelloworldServiceImpl implements HelloService {
      public void hello(String name) {
           System.out.prinlnt("Hello, "+name);
      }
  }

This is the simpliest way i’ve found for interfacing Spring and the GWT RPC layer…

Catégories :Uncategorized Étiquettes : , , ,

Trop lourd

19 août 2009 1 commentaire

Aujourdh’ui j’ai démarré dans le cadre de mon boulot un projet web… Ajax. Bien que j’ai toujours trouvé TRES discutable d’utiliser les technologies du web pour construire des vraies applications de gestion, j’en ai fait mon métier…

j’architecture donc le machin : une appli pour conteneur de servlet (tomcat) :

accés bdd gérés par ibatis ( l’appli fonctionne avec une ancienne base… sinon j’aurais bien poussé openJPA…)

  • – spring 2.5
  • – icefaces 1.8 (par dessus myfaces 1.2)
  • – facelets

La maquette de l’appli tient dans un war de 12 Mo !!!!. La, je marque un arrêt :

C’est INCROYABLE a quel point les développement j2ee sont bloatées ! c’est effrayant. A force de d’ajouter des frameworks de frameworks d’injection d’ajax de webservice d’orm de mes deux, on n’arrive même plus a envisager de démarrer le moindre développement sans au moins 10 Mo de jars…

Revenons a la simplicité, pitié, pourquoi toujours ajouter des solutions compliquées pour régler des problèmes simples ?

Ou sont les demos 64k de notre enfance ? (64 Ko, vous vous rendez compte !)

Imaginez que visicalc (en tout cas sa version pour pc),  un logiciel tableur complet, tient dans un executable de 27,5 ko !
Sérieusement, je pense que l’on est allé beaucoup trop loin dans la course à l’armement.

Au lieu de normaliser des solutions élégantes, légères et fiables, l’état de l’art nous impose d’essayer continuellement de réaliser l’irréalisable avec des technologies (ici, l’html) qui ne sont pas faites pour ça !

C’est tellement grotesque qu’on ne se rend même plus compte :

« un clic sur un bouton (balise html) va provoquer l’éxecution d’un javascript qui, gràce à une extension « plus ou moins disponible selon le navigateur (xmlhttp), va effectuer une requete HTTP, vers un serveur d’application (java). Un traitement est effectué, (peut-être même un peu de SQL, ou un appel a un webservice), avant de répondre a la requete par un document JSON (type mime application/json) , qui sera a son tour parsée et traitée par du javascript pour modifier le html »

Bien sur, a chaque que l’on passe d’un domaine a l’autre, on se repose les mêmes questions, et a chaque la roue a été inventée d’une manière différente : conversion de format, modèle conceptuel, sécurité, confidentialité, cache, accés concurrents…. sans compter les bugs et les spécifités des : navigateurs/proxy/routeur/serveur/base de donnée/os.

Est-ce que vous pensez vraiment que toute cette chaine est conceptuellement intelligible, et saine .Pensez vous que c’est une bonne manière de mettre en oeuvre ses besoins logiciels ?

Catégories :Uncategorized Étiquettes : , , ,

Spring, aop, caches…

1237036892[reprise d’un ancien article : j’ai vu depuis des librairies mieux écrites pour faire le meme genre de choses, mais cet article reste intéressant si vous voulez comprendre des mécanismes des annotations java, et un vrai exemple de programmation orientée aspect (AOP) ]

Introduction

Annotations

Les annotations java5 permettent d’ajouter des méta-données au classes, et déclarations de méthode. Ces informations peuvent être disponible au runtime. On peut savoir programmatiquement si telle ou telle méthode comporte telle ou telle annotation.

C’est une manière syntaxique élégante pour enrichir la définition des classes, et leur ajouter des informations non prévues dans le modèle de programmation propre a java.

AOP

L’AOP (aspect-oriented programming) est un paradigme de programmation permettant l’injection de code supplémentaire (‘advice’) par dessus un programme existant (‘subject’), de manière a implémenter de nouvelles fonctionnalités (‘concern’).

Le principe est de cibler les évenement d’un programme (appel d’une méthode, instanciation d’un objet, etc..) et de permettre l’execution de code arbitraire sur ces évenements. On utilise l’AOP pour ajouter des fonctions transverses a un programme sans modifier tout le code, et en évitant de mélanger des activités différentes dans un même code (typiquement : la sécurité, le logging, le tracage,…)

Spring fournit en interne une gestion de l’AOP, via la librairie AspectJ

Je me propose d’utiliser ces techniques pour implémenter une gestion automatique de cache.

principe de cache

Pour moi cache est un objet permettant de stocker des couples clé / valeur de manière a éviter de réeffectuer un traitement long.

Il s’agit donc de trouver une manière simple pour décrire qu’une méthode quelconque peut utiliser un cache, c’est a dire stocker/retrouver des résultats de manière transparent au lieu d’effectuer un traitement lors de chaque appel.

Interfaces

Je défini donc l’interface d’un cache :

public interface Cache {
      public void put(String key, Object valueToStore);
      public CacheResult get(String key);
}

et

public interface CacheResult {
     public boolean isAvailable();
     public String getKey();
     public Object getData();
}

partant ces ces deux interfaces, j’ai implémenté plusieurs types de cache (je ne copie pas le code ici, mais je peux vous envoyer un zip si vous demandez gentillement…)

  • une implémentation « dummy » qui ne stocke rien, et renvoie tout le temps des CacheResult « pas trouvé »
  • une implémentation « maison », la classe Cache ne fait qu’embarquer une hashmap.
  • une implémentation basée sur memcached, en utilisant la librairie de http://www.whalin.com/memcached/
  • une implémentation basée sur EHCache.

Annotation

Je définit une annotation : celle ci me permettra de « marquer » les méthodes :

import java.lang.annotation.Documented;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Documented
@Retention(RetentionPolicy.RUNTIME) //annotation conservée a l'execution
@Target(ElementType.METHOD) // l'annotation s'applique aux méthodes
public @interface UseCache {

String cacheName(); //cacheName est le parametre de l'annotation
}

Vous remarquerez a quel point il est simple de créer ses propres annotations !
La syntaxe « cacheName(); » paraitra un peu bizarre pour aux vieux briscard du java, mais c’est bien la syntaxe qui permet d’ajouter des paramètres aux annotions…

appliquer l’annotation par AOP

Annoter son code c’est bien, faire en sorte que ça fasse des trucs, c’est mieux ! J’utilise aspectJ + Spring pour associer a mon annotation « UseCache » un comportement spécifique au runtime.

Une annotation spécifique permet de déclarer la classe qui va se charger d’éxecuter du code quand on tente d’éxecuter les méthodes annotées « useCache » :

@Aspect
public class CachingInterceptor implements ApplicationContextAware {

private static final Log _logger = LogFactory.getLog(CachingInterceptor.class);

private ApplicationContext applicationContext;

@Around("@annotation(net.jr.caching.annotation.UseCache)")
public Object aroundCachedMethod(ProceedingJoinPoint jp) {
// find the cache, and the called method.
Method invoked = getMethod(jp);
Annotation annotation = invoked.getAnnotation(UseCache.class);
String cacheKey = Integer.toHexString(invoked.hashCode()) + "_"
+ buildCacheKey(jp.getArgs());

_logger.debug("the cache key for this call is "+cacheKey);

Cache cache = (Cache) getApplicationContext().getBean(
((UseCache) annotation).cacheName());

// try to retrieve data from cache
if (cache != null) {
CacheResult result = cache.get(cacheKey);
if (result.isAvailable()) {
_logger.debug("cache hit !");
return result.getData();
}
}

// no data available, so we call the original method.
_logger.debug("no data found in cache for key "+cacheKey+", calling original method code...");
try {
Object result = jp.proceed(jp.getArgs());
if (cache != null) {
_logger.debug("... putting method call result in cache with the key "+cacheKey);
cache.put(cacheKey, result);
}
return result;
} catch (Throwable ite) {
throw new RuntimeException(ite);
}
}

protected String buildCacheKey(Object... objs) {
int hash = 0;
for (Object arg : objs) {
hash ^= arg.hashCode();
}
return Integer.toString(hash);
}

@SuppressWarnings("unchecked")
protected Method getMethod(JoinPoint jp) {
MethodSignature met = (MethodSignature) jp.getSignature();
try {
Method method = jp.getSourceLocation().getWithinType().getMethod(
met.getMethod().getName(),
met.getMethod().getParameterTypes());
method.setAccessible(true);
return method;
} catch (NoSuchMethodException e) {
throw new RuntimeException(e);
}
}

protected Cache getCache(String name) {
return (Cache) getApplicationContext().getBean(name);
}

@Override
public void setApplicationContext(ApplicationContext applicationContext)
throws BeansException {
this.applicationContext = applicationContext;
}

protected ApplicationContext getApplicationContext() {
return applicationContext;
}

Ce code mérite quelques explications :

Création de l’Advice

l’advice est l’execution de la méthode « aroundCachedMethod »

l’execution consiste

  1. a trouver le cache dans l’applicationContext d’aprés sont nom,
  2. A frabriquer une ’empreinte’ (xor entre les hashcodes) a partir de la combinaison des paramètres d’entrée de la méthode « wrappée »
  3. chercher dans le cache la valeur stockée pour cette empreinte, la renvoyer directement quand elle est trouvée
  4. sinon, éxecuter la méthode originale et stocker la valeur de retour dans le cache.

Définition des pointcuts

les pointcuts ( = expression définissant le type d’évenement a surveiller) est également définit par annotation !

@Around("@annotation(net.jr.caching.annotation.UseCache)")

Veut dire  » A la place de (toute méthode comportant l’annotation ‘UseCache’)  »

Une documentation complète sur la syntaxe des pointcuts est disponible sur le site d’AspectJ

Intégration dans Spring

Dans le fichier de conf Spring, il faut déclarer l’utilisation de l’aop :

<beans
xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:aop="http://www.springframework.org/schema/aop"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://www.springframework.org/schema/aop
http://www.springframework.org/schema/aop/spring-aop-2.0.xsd">

    <aop:aspectj-autoproxy proxy-target-class="false" />

....

Puis on déclare notre « Interceptor » :

<bean id="cachingInterceptor" />

Puis on déclare un cache :

<bean id="monCache" />

C’est magique, Il suffit maintenant dans le code d’utiliser l’annotation pour qu’une méthode tire partie de notre cache :

class MyClass
{
@UseCache(cacheName="monCache")
     public String rechercheCompliquee(String criteres) {
          ....
     }
}

CONCLUSION :

cette méthode d’application de vos annotations vous permet d’appliquer des aspects sans avoir a modifier la manière dont le code est compilée. L’intégration avec Spring est également appréciable.

Par contre, faites attentions a l’impact sur les performances de ce type d’aop. Je me pose également des questions dans le cas ou un autre système de modification de bytecode (par exemple hibernate) est dèja en place…

Catégories :Uncategorized Étiquettes : , , ,