BreizhCamp 2013, FastConnect était là !

Comme je l’avais annoncé précédemment, nous étions présents les 13 et 14 juin au BreizhCamp 2013, LA conférence de l’Ouest :)

Il faut avouer que cette année la concurrence est rude :). Et oui, après avoir vu notre beau stand de l’édition 2012 (nous étions le seul sponsor à avoir un stand :)), tous les autres sponsors ont sorti leur artillerie lourde cette année.

Mais grâce à nos démos de MuleStudio, JRules et de notre portail de déploiement « votre custom PaaS dans votre Cloud » (basé sur Cloudify, entre autres, et développé par le Centre d’Expertise Cloud — contactez nous si vous voulez voir une démo :)), qui a été le point d’orgue de la 1ère journée (tout s’est très bien déroulé — à l’exception du petit effet démo avec PowerPoint qui s’est figé :(), nous n’avons pas peur de dire qu’il y avait du monde à notre stand :)

La 2ème journée a été tout aussi intense avec les démos en continu (et après le CI, nous avons mis en place le Continous Demo :)) et un très bon moment de détente avec beaucoup de participants à notre jeu FastDraw, dessinez c’est gagné, version geek où il y avait de nombreux lots à gagner :)

Bref, ce fut une expérience enrichissante… et un événement très bien organisé ! Merci à l’équipe organisatrice du BreizhCamp !

Et je tiens également à remercier l’équipe FastConnect Rennes, en particulier Matthieu, Antoine, Yoann et Violaine, pour leur implication et préparation. Bien entendu, les démos ne seraient pas aussi intéressantes sans les experts du CE Cloud : spécial dédicace donc à Gauvain, Mathias, Noureddine (et j’en oublie d’autres… et je m’en excuse). Et pour finir, un grand merci à Laure, notre chargée de recrutement préférée, qui s’est aventurée en terre bretonne pour l’occasion et qui m’a appris un nouveau mot : kakémono :)

20130614_132814 IMG_1452 IMG_1455 IMG_1464 IMG_1469

Rendez vous au Devoxx France 2013

Si vous êtes un peu geek (ça doit être le cas, car vous êtes sur notre blog :)) et si vous surfez sur le web pendant votre temps de travail (?? :) ), vous savez certainement que le Devoxx France aura lieu le 27 mars prochain. Et comme pour la 1ère édition, FastConnect fait de nouveau parti des sponsors de cet événement.

Et une fois de plus, nos consultants se plient en 4 (ou en 2 .. ça dépend de l’agilité de chacun :)) pour vous préparer une petite surprise ici.

Donc rendez vous sur notre stand ou sur cette page à partir du 27 mars.

On vous attend ! Comment ? Vous n’y allez pas ? Oh .. vous allez nous manquer :(…. Mais rassurez-vous, vous pouvez toujours venir nous voir sur notre stand au BreizhCamp 2013, une conférence chez les bretons pour les bretons et les non bretons dont FastConnect est également sponsor.

A bientôt…

Soirée FastConnect avec Software AG / Terracotta

Le Mardi 22 Janvier 2013 s’est déroulée une soirée FastConnect, et nous avons eu le plaisir d’accueillir Software AG / Terracotta pour nous parler de EhCache / BigMemory.

Personnellement, je trouve que cette solution répond à pas mal de besoins que je rencontre chez les clients.
De plus, la force de la solution est de pouvoir commencer avec un « petit cache » à l’aide d’EhCache (opensource, et qui s’intègre avec Hibernate ou Spring), puis bénéficier du cache « off-heap » avec BigMemoryGO, puis le rendre distribué avec BigMemoryMax.

600_198449722

A titre d’information, cette solution a été mise en production chez un client pour de la détection de fraude en temps réel, avec un volume de 16To en mémoire! Le mot « BigData » prend tout son sens.

Capture d’écran 2013-01-24 à 16.14.58

Je ne vous en dit pas plus, et je vous laisse découvrir EhCache / BigMemory à travers la documentation officielle.

Les 5 mercenaires du Devops au Devoxx France

Du 18 au 20 avril 2012 s’est tenu la première édition du Devoxx France. A cette occasion, j’ai eu la chance de découvrir le mouvement Devops grâce à la présentation de ses 5 mercenaires que sont :

Devops est une contraction de Développeur et Opérationnel. Ce mouvement tente de réconcilier les développeurs et les opérationnels.

Malgré l’arrivé des méthodologies Agiles dans la plupart des structures, le monde des développeurs et des opérationnels reste scindé en deux. D’un coté, nous avons les développeurs qui fournissent aux opérationnels un « livrables », pendant que les opérationnels tentent de déployer le dit livrable.
Très souvent, la définition du livrable n’est pas la même que l’on se trouve du point de vue du développeur ou de l’opérationnel.
L’une des recommandations du DevOps est de définir un livrable compréhensibles par les deux parties.
Pendant la présentation, les 5 mercenaires nous montrent une forme de livrable depuis un Jenkins. Les livrables sont des packages natifs, des RPMs en l’occurrence.
Cette forme de livrable  :
  • est auto-suffisante
  • peut être facilement déployé
  • peut être rollbacké
  • est archivable
  • est configurable

Dans leur exemple, ils proposent de livrer des RPMs contenant le conteneur Tomcat ainsi que le War de l’application. Cela permet aux développeurs de maintenir une configuration du conteneur répondant aux besoins de leur application.

Une partie du déploiement de l’application peut être configurable et/ou laissée à la main des opérationnels afin de configurer les éléments dédiés aux environnements de production (mot de passe de la base de données, etc…).
Les RPMs peuvent être construits par Jenkins et mis à disposition des opérationnels sur un dépôt Maven.
Les opérationnels peuvent alors aller chercher une version spécifique du livrable pour le déployer, voir même utiliser Jenkins; ou tout autre outil de Build continu.
En allant même un peu plus loin, il est possible de configurer le Jenkins afin de déployer régulièrement l’application. Nous parlons alors de déploiement continu.
Cette approche permet
  • une meilleur entente entre les opérationnels et les développeurs
  • d’améliorer la qualité du livrable
  • d’augmenter la satisfaction des utilisateurs

Cependant, la mise en place de cette recette miracle peut rencontrer quelques difficultés :

  • Une résistance forte du au choc culturel. Toutes les structures ne sont pas prête à accepter une étroite collaboration entre les opérationnels et les développeurs.
  • Généralement, il est fortement recommandé d’avoir une application qui pratique déjà l’intégration continu. Oui, ça peut peut-être faire sourire, mais les applications qui pratiquent l’intégration continue ne sont pas aussi courantes.

Dématérialiser son application sous forme de services Clouds sans se lier à une plate-forme ou un fournisseur.

Le Cloud est un concept révolutionnaire qui transforme notre vision sur la façon de fournir des services informatiques à nos utilisateurs.
Les services Cloud sont dématérialisés et faciles d’accès, disponibles à la demande, élastiques, et nous permettent de ne consommer que ce dont nous avons besoin.

Mais quid de l’existant et de sa complexité ? Cela veut-il dire que la richesse applicative dont nous disposons déjà ne peut être fournie à vos utilisateurs en mode Cloud ? Et avons nous les outils nécessaires pour exposer nos nouveaux services dans le Cloud de manière portable, réversible et à coûts contrôlés ?

J’ai le plaisir de présenter une approche d’architecture basée sur des outils Open Source et des cas d’utilisation de clients ayant franchi le pas, à l’Open World Forum, Jeudi 11 Octobre à 15h30.
Voir ici pour le programme de ce track : http://openworldforum2012.sched.org/event/bcfdb68972df051b8d20be3977f86cf5

J’espère vous y retrouver nombreux.

Cette session vous éclairera sur les capacités de mise en place de services applicatifs Cloud, à travers l’utilisation de la plate-forme PaaS Cloudify (http://www.cloudifysource.org/), permettant de dématérialiser le socle d’exécution de vos applications, sans changement de code, ni lock in : « Any App, Any Cloud, Your Way ».

À cette occasion seront abordés les thèmes suivants :

  • Les bénéfices du PaaS – Platform as a Service
  • Automatisation et résilience pour améliorer le temps de mise à disposition des applications et les SLA applicatifs
  • Portabilité data-center, Cloud privé et Cloud publics
  • Cloudify et DevOps
  • Cas d’utilisation : L’intégration de Cloudify au sein d’un portail Appstore afin de délivrer des services applicatifs (Apps) à la demande, en plus de services d’infrastructure (Compute, Storage)
  • Cas d’utilisation : L’intégration de Cloudify au sein d’une plate-forme de livraison continue (continuous delivery) pour le développement et les tests d’une application d’analyse des réseaux sociaux
  • FastConnect Inside : le vendredi du connaisseur

    Pour notre session de juillet du « Vendredi du connaisseur » (session technique où chacun parle d’un sujet/problématique qu’il a rencontré pendant le mois), nous avons choisi de faire simple : pizza pour tous & prez en freestyle.

    Finalement au menu, nous avons eu droit à :

    • une introduction résumée de la formation MongoDB que Mael & Florian ont suivie le mois dernier dans les locaux de FastConnect à Issy (en partenariat avec 10gen)
    • une petite présentation sur la gestion de la mémoire par la JVM et le pourquoi du classique « java.lang.OutOfMemoryError: PermGen space » par Arnaud
    • un survol sur le fonctionnement du SSO & intégration CAS accompagné d’une démo qui marche :) par Marc

    Sans oublier les 6 pizzas (de 2 personnes) : Ananas, Cap Horn, Bolognaise, Catalane, Los Angeles et Orientale ;)

    Rendez vous à la prochaine session …

    Équipe FastConnect Rennes

    Paris JUG Juillet 2012 – Couchbase

    Mardi 3 Juillet s’est déroulé le Paris JUG. Cette session était orientée 100% NoSQL.

    La première partie fut animée par Raghavan « Rags » N. Srinivas sur une présentation de Couchbase.


    Attention : on parle bien de Couchbase, pas de CouchDB !
    Je reviendrai sur la différence entre les deux dans quelques lignes…

    Avant de parler de Couchbase, Rags nous explique l’intérêt du NoSQL, comme la scalabilité horizontale et donc un coût maitrisé.
    Si vous n’êtes pas encore convaincu, je vous suggère de voir leur document « Why NoSQL ? » sur le site de Couchbase : http://www.couchbase.com/why-nosql/nosql-database

    Qu’est-ce que Couchbase ?

    Maintenant se pose la grande question : qu’est-ce que Couchbase ?
    La réponse courte : C’est une base NoSQL, orienté « clé/valeur » mais avec des fonctionnalités orientées « document ».

    Avant Couchbase, il y avait Membase : un Memcached survitaminé, avec réplication des caches, persistances, une interface d’admin Web bien sympa, etc.
    Membase n’existe plus, Couchbase le remplace et l’intègre.

    On peut donc utiliser Couchbase comme un cache mémoire pure, en mode clé/valeur, avec l’API cliente de Memcached.

    Mais alors, quel est le rapport entre Couchbase et CouchDB ?
    Couchbase intègre CouchDB !
    Pour prendre un exemple simple : quand vous sauvegardez un document JSON, ce dernier va être envoyé dans le cache Memcached, puis persisté sur disque avec le moteur de CouchDB (de manière asynchrone).

    On peut comparer le processus avec celui de MongoDB, à la différence que MongoDB ne possède pas son module de Caching, mais délègue cette gestion à l’OS à l’aide de « Memory-mapped files », qui va flusher sur disque de temps en temps.

    Pour mieux illustrer mes propos, voici l’écran de monitoring lorsque je fais une écriture massive :

    On remarque un pique de « ops per second » : ce sont mes écritures massives
    Mais la donnée se trouve seulement en mémoire, pas encore sur le disque !
    On voit alors que le « disk write queue » augmente d’un coup : c’est la file d’attente avant persistance sur disque.
    Quelques secondes plus tard, on voit que cette dernière diminue petit à petit.
    En même temps, on voit que la base augmente sur le disque dans « couch disk/data size ».
    Et toujours en même temps, on voit des « creates per sec » pendant cette phase de persistance.

    Pour comprendre comment fonctionne Couchbase, et comment il intègre CouchDB, vous pouvez lire ceci : http://www.couchbase.com/couchdb

    Comment lire/écrite dans Couchbase (en Java) ?

    Couchbase est donc très orienté performance, puisqu’on va exploiter au mieux la mémoire.
    De plus, les opérations de l’API sont de type « fire and forget » : quand on demande de sauvegarder un document, l’API nous rend la main tout de suite sans savoir si la sauvegarde a bien fonctionné !
    Pour cela, il va y avoir un mécanisme semblable aux « Future » en Java, ou au « Write Concern » en MongoDB ou Cassandra.
    L’API va donc nous renvoyer un objet « OperationFuture », sur lequel on va pouvoir, plus tard, demander d’attendre la fin de la sauvegarde.
    Voici un exemple de code, plus parlant je l’espère :)

    CouchbaseConnectionFactory factory = new CouchbaseConnectionFactory(
      Arrays.asList(URI.create("http://localhost:8091/pools")),
      "default",
      "");
    client = new CouchbaseClient(factory);
    
    GsonBuilder builder = new GsonBuilder();
    Gson gson = builder.create();
    
    // on stocke ici les futures des opérations d'insertion
    List<OperationFuture<Boolean>> futures = new ArrayList<OperationFuture<Boolean>>();
    
    for (int cpt = 0; cpt < 80000; cpt++) {
    
     // création d'un document
     People people = new People();
     people.setFirstname("Mathias");
     people.setLastname("Kluba");
    
     // j'utilise ici GSON pour construire mon JSON à partir de mon POJO
     String json = gson.toJson(people);
    
     // on va générer un ID pour chaque item
     UUID uuid = UUID.randomUUID();
    
     // sauvegarde de l'objet
     OperationFuture<Boolean> setResult = client.set(
     uuid.toString(),
     0,
     json);
    
     // on conserve le future pour plus tard...
     futures.add(setResult);
    }
    
    // maintenant qu'on a balancé les sauvegarde sur le server,
    // on attend la fin de chacune d'entre elles,
    // et on vérifie que la sauvegarde a réussie
    for (OperationFuture<Boolean> f : futures) {
     Assertions.assertThat(f.get()).isTrue();
    }
    
    

    Ce qui est sympa, c’est que même la lecture peut être asynchrone : on balance plein de requête au serveur, et on demande ensuite le résultat en asynchrone à l’aide du Future.

    Comme tout fonctionne en mode asynchrone, cela peut poser des problèmes lors de l’écriture : comment gérer les écritures concurrentes ?
    En base relationnelle, on va vouloir faire une transaction, pour être sûr que personne ne modifie la même donnée.
    Mais Couchbase ne supporte pas les transactions !
    Ceci dit, il y a moyen de gérer la concurrence de manière « Optimiste » : on va admettre que tout va bien dans la plupart des cas, et s’il y a un problème de concurrence, alors on va gérer l’erreur au niveau de l’application.

    Pour ça, il y a le mécanisme de CAS (Check and Set).
    Le CAS va se servir d’une sorte de Checksum qui va nous permettre de vérifier si quelqu’un n’a pas modifié le même objet entre temps.
    Ex :

    • Je récupère un objet avec son CAS
    • Je le modifie en mémoire
    • Quelqu’un d’autre le récupère aussi, le modifie et le sauvegarde en base
    • Lorsque je le sauvegarde, je précise la valeur du CAS que j’ai obtenu
      • ERROR : la valeur du CAS fournie n’est pas le même en base : quelqu’un a modifié le même objet entre temps : la sauvegarde échoue

    Comme Linus Torvalds disait : TALK IS CHEAP. SHOW ME THE CODE !

    GsonBuilder builder = new GsonBuilder();
    Gson gson = builder.create();
    
    // création d'un document
    People people = new People();
    people.setFirstname("Mathias");
    people.setLastname("Kluba");
    
    // j'utilise ici GSON pour construire mon JSON à partir de mon POJO
    String json = gson.toJson(people);
    
    // on va générer un ID pour chaque item
    UUID uuid = UUID.randomUUID();
    
    // sauvegarde de l'objet
    OperationFuture<Boolean> future = client.set(
     uuid.toString(),
     0,
     json);
    
    Assertions.assertThat(future.get()).isTrue();
    System.out.println(future.getStatus());
    
    // obtient l'objet avec son CAS
    CASValue<Object> withCas = client.gets(uuid.toString());
    
    people = gson.fromJson((String)withCas.getValue(), People.class);
    people.setFirstname("Roi Mathias 1er");
    
    json = gson.toJson(people);
    
    // tente de mettre à jour l'objet avec son CAS
    CASResponse response = client.cas(uuid.toString(), withCas.getCas(), people);
    
    Assertions.assertThat(response).isEqualTo(CASResponse.OK);
    
    // tente de mettre à jour une seconde fois:
    // mais qui ne va pas marché car on n'a pas le bon CAS
    
    response = client.cas(uuid.toString(), withCas.getCas(), people);
    
    Assertions.assertThat(response).isEqualTo(CASResponse.EXISTS);
    
    

    Un autre truc sympa, hérité de Memcached, c’est la notion de TTL (Time To Live).
    Si je reprends le code de la sauvegarde, on remarque un 2 ème argument de type Integer :

    
    // sauvegarde de l'objet
    OperationFuture<Boolean> setResult = client.set(
     uuid.toString(),
     0,
     json);
    
    

    C’est en fait le TTL en seconde : je peux ainsi dire « sauvegarde moi cette donnée, mais elle expire dans 60sec ».
    Ici, cas particulier, je ne veux pas d’expiration, la valeur du TTL est donc 0.

    Bon, faire un « set/get » en mode clé/valeur, c’est bien mais parfois ça peut être limitant…
    Et si je veux maintenant requêter sur le « lastname » ?

    C’est là que l’approche « orienté document » de Couchbase est intéressante :
    Ils prennent pour postula que la majorité de vos requêtes seront de type « clé/valeur ».
    Tout d’abord, quand vous sauvegardez une valeur au format JSON, cette valeur sera traitée de manière très spéciale par Couchbase.
    Mais par défaut, on ne peut donc pas requêter sur les champs de votre JSON. Pour ce faire, il faut créer une sorte d’index sur les champs que vous avez besoin de requêter.

    Je dis bien « une sorte d’index », car en Couchbase on appelle ça une « Vue » (comme les Vue SQL), mais le plus fun c’est qu’on code cette vue avec une fonction de Map-Reduce (ou Map seulement) ;)

    En résumé : les Vues sont des « Map-Reduce » à la demande.

    Quand on interroge une vue, on peut demander le résultat déjà calculé au préalable, ou re-indexer la base en re-exécutant la fonction de Map-Reduce.
    Voici ce qui se passe si j’interroge une vue en forçant la re-indexation :

    Voici un exemple de Vue et son utilisation en Java :

    
    Query query = new Query();
    
    query.setReduce(false);
    query.setIncludeDocs(false);
    query.setStale(Stale.FALSE);
    
    View view = client.getView("people", "bylastname");
    
    Paginator paginator = client.paginatedQuery(view, query, 500);
    
    while (paginator.hasNext()) {
     ViewRow row = paginator.next();
     System.out.println(
      "ID: " + row.getId() +
      " Key: " + row.getKey()  +
      " Value: " + row.getValue());
    }
    
    

    Et voilà à quoi ça ressemble coté Couchbase :

    Petit détail : si vous forcer la re-indexation, ça ne s’applique bien sûr qu’aux nouvelles données ou aux données changées… donc si vous avez déjà 80000 items, que le Map-Reduce est terminé, et que vous ajoutez 80 items, le Map-Reduce sera plus rapide :)

    Pour conclure sur les aspects requêtages, Couchbase, offre une API Memcached (pour de la haute performance) mais offre aussi une API REST, beaucoup plus « Web friendly ».
    Les applications Web peuvent alors récupérer le JSON avec une URL REST qui ressemble à cela :
    http://localhost:8091/couchBase/default/00006e0b-4b58-465d-b045-e2a485baaa51

    Pour obtenir le résultat d’une vue, cela ressemble à cela :
    http://localhost:8091/couchBase/default/_design/dev_people/_view/bylastname?limit=10&skip=0

    La présentation de Couchbase s’arrête à peu près là. On voit alors que Couchbase est orienté Web, Performance, Scalabilité Horizontale, et que son installation et utilisation est très simple.

    Couchbase et Cluster

    Mais je souhaite aller plus loin,  j’ai voulu savoir comment fonctionne les aspects « scalabilité horizontale » de Couchbase.
    Premièrement : tout comme Cassandra, chaque nœud Couchbase fonctionnent de la même manière, aucun n’est spécialisé.

    Couchbase utilise Memcached, donc exploite le même mécanisme de répartition de charge grâce au « Consistent Hashing » : les données sont uniformément réparties sur tous les nœuds disponibles.
    Et si j’ajoute un nœud ?
    Et bien il n’est pas exploité tout de suite : il est en attente de Re-Balancing.
    Cette opération vous permet donc de re-balancer les données sur plusieurs nœuds à la fois, si vous en ajoutez plusieurs :

    Attention : c’est une opération bloquante et elle peut prendre du temps, ce qui rend donc votre serveur indisponible. Il faut alors choisir le moment de son exécution judicieusement…. mais au moins, ce n’est pas automatique, et ça ne va pas planter votre prod lors d’une forte charge !

    Le même mécanisme fonctionne quand on supprime un nœud :

    Tout ça, c’est pour répartir la charge, et donc :

    • Exploiter le disque + mémoire de plusieurs machines pour accélérer les requêtes de lecture/écriture
    • Exploiter le CPU de plusieurs machines pour accélérer le Map-Reduce des Vues

    Mais qu’en est-il de la résilience ?
    Elle est assuré grâce à la réplication, et on configure ça au niveau d’un « Bucket ».

    Un « Bucket » c’est l’équivalent d’une base en SQL.
    Il n’y a pas de notion de « table » (ou « collection » comme en Mongo), si vous voulez séparer des données alors il faut créer un autre Bucket.
    Ce dernier possède un quota en mémoire, et un nombre de réplica.
    Si le nombre de réplica est 1, alors la donnée sera écrite sur 2 nœuds.

    Conclusion

    En conclusion, j’ai été agréablement surpris.
    Premièrement, j’ai confondu Couchbase et CouchDB : Couchbase c’est un mixe des meilleurs choses de Memcached et CouchDB, c’est donc pas mal :)
    L’approche « Vue avec Map-Reduce » est intéressante : on ne ralentit pas les écritures pour mettre à jour un index, ou construire un « b-tree », alors que finalement on va requêter sur seulement quelques champs du document…
    Il y a donc de très bonnes idées, même si, à mon avis, il reste des choses à améliorer.
    Couchbase est donc différent des autres solutions NoSQL, avec ses avantages et ses inconvénients.
    Vous avez donc une base de données qui vient étoffer votre panel de solutions NoSQL, ce qui vous donne encore plus de choix, mais ce qui rend la tâche encore plus complexe :)

    DevoxxFR 2012, c’est fini

    DevoxxFR 2012 est terminé.

    Nous avons animé notre stand de manière festive et nous avons présenté, avec un succès certain, notre société et nos métiers.

    Notre quiz en ligne a été un succès. Plus qu’un concours il s’agissait d’une des démonstrations que nous avions préparée pour illustrer notre savoir-faire. L’application s’exécutait dans un data center en Irlande et nous avions automatisé son déploiement à l’aide de Cloudify, un outil de PaaS fabric réalisé par GigaSpaces.

    Nous publierons bientôt les vidéos de ces démonstrations. En attendant, voici un extrait des questions que nous avons posées.

    le premier gagnant de notre quiz

    A constructor is used to

    • Free memory
    • Initialize a newly created object
    • Import packages
    • Create a JVM for applets

    What is the number of bytes used by Java primitive long?

    • The number of bytes is compiler dependent
    • 2
    • 4
    • 8

    Which of the following statement is False?

    • The throw keyword denotes a statement that causes an exception to be initiated
    • A class that is declared without any access modifiers is said to have package or friendly access
    • A class inherit the constructors of its superclass
    • The primitive types are byte, char, short, int, long, float, double, and boolean

    A mechanism of moving the session from one server to another in case of server failure is called as

    • Session Hijacking
    • Session Migration
    • Session Tracking
    • None of the Above

    Which one of the following method is not Agile?

    • The Scrum method
    • The XP method
    • The Rache method
    • The RAD method

    Who did create the mechanical calculator in 1642?

    • Blaise Pascal
    • Sir Isaac Newton
    • Gottfried Wilhelm Leibniz
    • Alan Mathison Turing

    What is Corba?

    • A free Java tool that calculates the percentage of code accessed by tests
    • A broker for building distributed object-oriented applications
    • A member of the family Elapidae
    • A man with a Psycho-Gun in his left arm

    le second gagnant de notre quiz

    Consider the following piece of code byte x = 0; x += 1;

    • Results in x having the value 1
    • Will require a cast (byte) before 1
    • Will give syntax error
    • Will cause an error during execution

    What are Java varargs?

    • A keyword to denote non-constant values
    • A syntax to write methods that took an arbitrary number of arguments
    • An object reference that may be updated atomically
    • A keyword to indicate that a variable’s value will be modified by different threads

    In java, which mechanism allows to use a same function with different argument types?

    • Inheritance
    • Overriding
    • Overloading
    • Encapsulation

    Choose the statement that best describes the relationship between JSP and servlets.

    • Servlets are built on JSP semantics and all servlets are compiled to JSP pages for runtime usage.
    • JSPs are built on servlet semantics and all JSPs are compiled to servlets for runtime usage.
    • Servlets and JSP are competing technologies for handling web requests.
    • JSP and servlets are unrelated technologies.

    In java, which one of these statements is true?

    • An anonymous class can be declared as both extending a class and implementing an interface
    • An anonymous class can extend a class or implement an interface
    • An anonymous class can only extend a class
    • All statements above are false
    • An anonymous class can extend a class or implement an interface

    Which of the following is not a programming language?

    • Luminaire
    • Eiffel
    • OCaml
    • Smalltalk

    What means JIT in Java?

    • Java interface transaction
    • Just in time transaction
    • Just in time compiler
    • Juvenile in training