Langage Java

1. Programation Orientée Objet (POO) Java

1.1. Popularité des langages de programmation

Source de l’image : The Incredible Growth of Python

• Langages de programmation “compilés”
• Langages de programmation “interprétés”

1.2. Présentation du langage Java

Java est un langage de programmation orienté objet créé par James Gosling et Patrick Naughton, employés de Sun Microsystems, avec le soutien de Bill Joy (cofondateur de Sun Microsystems en 1982), présenté officiellement le 23 mai 1995 au SunWorld.

La société Sun a été ensuite rachetée en 2009 par la société Oracle qui détient et maintient désormais Java.

La particularité et l’objectif central de Java est que les logiciels écrits dans ce langage doivent être très facilement portables sur plusieurs systèmes d’exploitation tels que Unix, Windows, Mac OS ou GNU/Linux, avec peu ou pas de modifications, mais qui ont l’inconvénient d’être plus lourd à l’exécution (en mémoire et en temps processeur) à cause de sa machine virtuelle. Pour cela, divers plateformes et frameworks associés visent à guider, sinon garantir, cette portabilité des applications développées en Java.

1.3. Présentation technique du langage Java

Le langage Java reprend en grande partie la syntaxe du langage C++.

Java permet de développer des applications client-serveur. Côté client, les applets sont à l’origine de la notoriété du langage. C’est surtout côté serveur que Java s’est imposé dans le milieu de l’entreprise grâce aux servlets, le pendant serveur des applets, et plus récemment les JSP (JavaServer Pages) qui peuvent se substituer à PHP, ASP et ASP.NET.

Java a donné naissance à un système d’exploitation (JavaOS), à des environnements de développement (eclipse/JDK), des machines virtuelles (MSJVM, JRE) applicatives multiplate-forme (JVM), une déclinaison pour les périphériques mobiles/embarqués (J2ME), une bibliothèque de conception d’interface graphique (AWT/Swing), des applications lourdes (Jude, Oracle SQL Worksheet, etc.), des technologies web (servlets, applets) et une déclinaison pour l’entreprise (Java EE).

La portabilité du bytecode Java est assurée par la machine virtuelle Java, et éventuellement par des bibliothèques standard incluses dans un JRE. Cette machine virtuelle peut interpréter le bytecode ou le compiler à la volée en langage machine. La portabilité est dépendante de la qualité de portage des JVM sur chaque OS.

1.4. Cas d’usage Web côté client

Applets

Historiquement, la possibilité des navigateurs Web de lancer des applets Java était la seule solution pour afficher des applications clientes riches (RIA pour rich Internet application). Puis des technologies concurrentes ont émergé parmi lesquelles Macromedia Flash, le DHTML JavaScript, Silverlight basé sur XAML ou Xul.

Les applets sur le poste Client peuvent communiquer avec des servlets sur le Serveur, tout comme Javascript peut communiquer avec le Serveur au moyen d’AJAX. Flex utilise quant à lui la technologie Flash par le biais du Adobe Flash Player.

À une époque où JavaScript souffrait de problèmes de compatibilité inter-navigateurs, les applets Java avaient l’avantage de la portabilité car le portage d’interfaces complexes était difficile à assurer pour tous les navigateurs du marché.

Outre la retombée de la « mode » Java, les progrès faits dans les technologies concurrentes à Java ont amené la plupart des développeurs à se détourner des applets Java et des problèmes inhérents à cette technologie (incompatibilités entre les JVM, mauvaises performances, pauvreté des bibliothèques graphiques, complexité). Enfin, les navigateurs modernes n’incluent plus systématiquement l’environnement Java à cause de sa taille importante, et le taux de machines capables d’afficher des applets n’était plus que de 70 % en 2010, bien plus faible que pour Flash par exemple. En 2010, la quasi-totalité des applications clients riches utilisent des technologies alternatives ; Flash pour l’essentiel mais aussi GWT.

Enfin, la perspective de l’arrivée prochaine de HTML5, destiné à embarquer de nombreuses fonctionnalités RIA et multimédia, rend également les applets caduques.

JavaFX

Avec l’apparition de Java 8 en mars 2014, JavaFX devient l’outil de création d’interface graphique (‘GUI toolkit’) officiel de Java, pour toutes les sortes d’application (applications mobiles, applications sur poste de travail, applications Web…), le développement de son prédécesseur Swing étant abandonné (sauf pour les corrections de bogues). JavaFX est une pure API Java (le langage de script spécifique qui lui a été un temps associé est maintenant abandonné). JavaFX contient des outils très divers, notamment pour les médias audio et vidéo, le graphisme 2D et 3D, la programmation Web, la programmation parallèle, etc.

1.5. Cas d’usage Web côté serveur

Avec les serveurs d’applications, on utilise des EJB pour encapsuler les classes définies précédemment. Ces éléments sont utilisés dans des architectures Java EE pour des applications multicouches. L’avantage qu’on tire de ce travail est de pouvoir cacher au client l’implémentation du code côté serveur.

1.6. Cas d’usage sur poste de travail

L’utilisation native du langage Java pour des applications sur un poste de travail restait jusqu’à présent relativement rare à cause de leur manque de rapidité. Cependant, avec l’accroissement rapide de la puissance des ordinateurs, les améliorations au cours des années 2000, de la machine virtuelle Java et de la qualité des compilateurs, plusieurs technologies ont gagné du terrain comme NetBeans et l’environnement Eclipse, les technologies de fichiers partagés LimeWire, Vuze (ex Azureus), et I2P. Java est aussi utilisé dans le programme de mathématiques MATLAB, au niveau de l’interface homme machine et pour le calcul formel. Les applications Swing apparaissent également comme une alternative à la technologie .NET.

1.7. Cas d’usage sur mobile

Oracle annonce début octobre 2012 à la conférence JavaOne sa volonté de proposer des solutions Java pour le domaine des logiciels embarqués, pour processeurs moins puissants que ceux habituellement disponibles sur les PC. Oracle fédère autour d’elle tout un éco-système d’entreprises spécialistes de ces segments de marchés, comme l’éditeur MicroEJ ou encore STMicroelectronics qui propose du Java sur ses STM32 dont le cœur est un CortexM3/M4.

Java, notamment via Eclipse et NetBeans, offre déjà des environnements de développement intégrés pour mobile. Java est le principal langage utilisé pour développer des applications pour le système d’exploitation libre pour Mobile de Google : Android.

JavaFX peut aussi permettre l’utilisation de Java sur mobiles, bien que ce ne soit pas son objectif principal.

1.8. Versions de Java

Java version history

Source : Java (langage)

2. Installation de Java

Ce chapitre traite principalement de l’installation de Java sous Linux.

2.1. JRE et JDK

JRE est l’environnement d’exécution Java. C’est un paquet comprenant tout ce qui est nécessaire pour exécuter un programme Java compilé, y compris la machine virtuelle Java (JVM), la bibliothèque de classes Java, la commande java et autres composants d’infrastructure. Cependant, il ne peut pas être utilisé pour créer de nouveaux programmes.

Le JDK est un Java Development Kit, le SDK complet pour Java. Il a tout ce que le JRE a, mais aussi le compilateur (javac) et les outils (comme javadoc et jdb). Il est capable de créer et de compiler des programmes.

En général, si on s’intéresse uniquement à l’exécution de programmes Java sur ordinateur, on installe uniquement le JRE. C’est tout ce dont on a besoin. En revanche, si on prévoit de faire de la programmation Java, il faut installer le JDK à la place.

Parfois, même si on n’a pas l’intention de faire du développement Java sur un ordinateur, il faut quand même installer le JDK. Par exemple, si on déploie une application web avec JSP, techniquement, on n’exécute que des programmes Java à l’intérieur du serveur d’application. Pourquoi aurais-t-on besoin du JDK alors ? Parce que le serveur d’application convertira le JSP en servlets Java et doit utiliser le JDK pour compiler les servlets.

Source : What is the difference between JDK and JRE?

2.2. OpenJDK et Oracle JDK

OpenJDK et Oracle JDK sont tous deux créés et maintenus actuellement par Oracle uniquement.

OpenJDK et Oracle JDK sont des implémentations de la même spécification Java qui a passé le TCK (Java Technology Certification Kit).

La plupart des fournisseurs de JDK sont écrits sur OpenJDK en faisant quelques ajustements (principalement pour remplacer les pièces propriétaires sous licence / remplacer par des éléments plus performants qui ne fonctionnent que sur des OS spécifiques) sans casser la compatibilité TCK. De nombreux fournisseurs ont implémenté la spécification Java et ont obtenu l’approbation de TCK. Par exemple, IBM J9, Azul Zulu, Azul Zing et Oracle JDK.

Presque tous les JDK existants sont dérivés d’OpenJDK.

Comme beaucoup le suggèrent, l’octroi de licences est un changement entre les JDK. A partir du JDK 11, l’accès au support à long terme d’Oracle JDK/Java SE nécessitera désormais une licence commerciale. Vous devriez dès maintenant faire attention quel JDK vous installez car Oracle JDK sans abonnement pourrait cesser de fonctionner. source

Ref : Liste des machines virtuelles Java

Source : Differences between Oracle JDK and OpenJDK

2.3. Migration d’Oracle JDK vers OpenJDK sous Red Hat

Source : Migrating from Oracle JDK to OpenJDK on Red Hat Enterprise Linux: What you need to know

Oracle a annoncé que les versions Oracle JDK 8 publiées après janvier 2019 cessaient d’être gratuites pour un usage commercial. Les licences sous licence GPL + Classpath Exception (gratuites pour toute utilisation, sous réserve de cette licence) sont actuellement mises à disposition par Oracle via http://jdk.java.net/11/ .

Une alternative consiste à utiliser OpenJDK et des efforts sont en cours pour les rendre totalement interchangeables . Un certain nombre de sociétés qui utilisent actuellement Oracle JDK en production prennent la décision de passer à OpenJDK ou l’ont déjà fait.

Aspect d’architecture

Lorsqu’il s’agit d’exécuter Oracle JDK sur RHEL, une configuration rencontrée couramment consiste à télécharger le fichier zip JDK Oracle, à l’extraire dans un dossier particulier et à diriger l’application vers ce JDK. Parfois, l’équipe de développement d’applications envoie son application avec le kit JDK aux équipes de déploiement. Une autre approche consiste à télécharger le RPM et à l’installer.

La méthode de téléchargement de fichier zip est plus difficile à tenir à jour et n’est donc généralement pas recommandée. Dans les systèmes de production, les changements de système d’exploitation rompent l’application.

OpenJDK, en revanche, n’est pas disponible au format zip. Au lieu de cela, il est installé via yum, dnf ou rpm, yum étant la méthode recommandée. Plusieurs versions principales simultanées sur le même serveur sont entièrement prises en charge.

Pour les entreprises, cela signifie généralement que la maintenance et les mises à jour d’OpenJDK sont gérées par l’équipe d’infrastructure (ou par une personne disposant d’un accès root) et non par l’équipe de développement.

On doit également être attentif aux mises à jour OpenJDK. Bien que plusieurs versions majeures soient prises en charge (1.7, 1.8), avec yum, le système sera généralement mis à jour avec la dernière version mineure de chaque version majeure. (1.8 b60 -> 1.8 b191) et, par défaut, seule la dernière version mineure est laissée installée.

Les principales versions de LTS OpenJDK (7, 8 et 11) sur RHEL sont entièrement prises en charge par Red Hat et Red Hat s’engage à fournir des correctifs au niveau du code pour les corrections de bogues. Les versions principales sont prises en charge pendant au moins 6 ans. Par exemple, OpenJDK 1.8 est pris en charge jusqu’en juin 2023 . Les versions Red Hat OpenJDK ont adopté la version Java SE TCK appropriée mise à disposition par les tests Oracle et Red Hat et les prennent en charge avec les implémentations Java EE. Par exemple, Red Hat teste et prend en charge les implémentations Java EE telles que JBoss Enterprise Application Platform s’exécutant avec OpenJDK.

Paquets OpenJDK en Centos via dépôts

cat /etc/redhat-release
CentOS Linux release 7.6.1810 (Core)

yum search java | grep 'java-'

R-java-devel.x86_64 : Development package for use with Java enabled R components
abrt-java-connector.x86_64 : JNI Agent library converting Java exceptions to
canl-java-javadoc.noarch : Javadoc documentation for canl-java
dnsjava-javadoc.noarch : Javadoc for dnsjava
genders-java-devel.x86_64 : Java Development libraries
ghc-language-java-devel.x86_64 : Haskell language-java library development files
glite-jobid-api-java-javadoc.noarch : Java API documentation for
glite-lb-client-java-javadoc.noarch : Java API documentation for
java-atk-wrapper.i686 : Java ATK Wrapper
java-atk-wrapper.x86_64 : Java ATK Wrapper
java-dirq-javadoc.noarch : Javadocs for java-dirq
java-oauth-javadoc.noarch : Javadoc for java-oauth
java-runtime-decompiler-javadoc.noarch : Javadoc for java-runtime-decompiler
libdb-java-devel.i686 : Development files for using the Berkeley DB with Java
libdb-java-devel.x86_64 : Development files for using the Berkeley DB with Java
libdb4-java-devel.x86_64 : Development files for using the Berkeley DB (version
libguestfs-java-devel.x86_64 : Java development package for libguestfs
libthrift-javadoc.noarch : API documentation for java-thrift
libvirt-java-devel.noarch : Compressed Java source files for libvirt-java
libvirt-java-javadoc.noarch : Java documentation for libvirt-java
ovirt-engine-sdk-java-javadoc.noarch : Javadocs for ovirt-engine-sdk-java
rabbitmq-java-client.noarch : Java Advanced Message Queue Protocol client
rabbitmq-java-client-doc.noarch : Documentation for rabbitmq-java-client
rabbitmq-java-client-javadoc.noarch : Javadoc for rabbitmq-java-client
rxjava-javadoc.noarch : Javadoc for rxjava
voms-api-java-javadoc.noarch : Virtual Organization Membership Service Java API
xz-java-javadoc.noarch : Javadocs for xz-java
java-1.6.0-openjdk.x86_64 : OpenJDK Runtime Environment
java-1.6.0-openjdk-demo.x86_64 : OpenJDK Demos
java-1.6.0-openjdk-devel.x86_64 : OpenJDK Development Environment
java-1.6.0-openjdk-javadoc.x86_64 : OpenJDK API Documentation
java-1.6.0-openjdk-src.x86_64 : OpenJDK Source Bundle
java-1.7.0-openjdk.x86_64 : OpenJDK Runtime Environment
java-1.7.0-openjdk-accessibility.x86_64 : OpenJDK accessibility connector
java-1.7.0-openjdk-demo.x86_64 : OpenJDK Demos
java-1.7.0-openjdk-devel.x86_64 : OpenJDK Development Environment
java-1.7.0-openjdk-headless.x86_64 : The OpenJDK runtime environment without
java-1.7.0-openjdk-javadoc.noarch : OpenJDK API Documentation
java-1.7.0-openjdk-src.x86_64 : OpenJDK Source Bundle
java-1.8.0-openjdk.i686 : OpenJDK Runtime Environment
java-1.8.0-openjdk.x86_64 : OpenJDK Runtime Environment 8
java-1.8.0-openjdk-accessibility.i686 : OpenJDK accessibility connector
java-1.8.0-openjdk-accessibility.x86_64 : OpenJDK accessibility connector
java-1.8.0-openjdk-accessibility-debug.i686 : OpenJDK accessibility connector
java-1.8.0-openjdk-accessibility-debug.x86_64 : OpenJDK 8 accessibility
java-1.8.0-openjdk-debug.i686 : OpenJDK Runtime Environment with full debug on
java-1.8.0-openjdk-debug.x86_64 : OpenJDK Runtime Environment 8 with full debug
java-1.8.0-openjdk-demo.i686 : OpenJDK Demos
java-1.8.0-openjdk-demo.x86_64 : OpenJDK Demos 8
java-1.8.0-openjdk-demo-debug.i686 : OpenJDK Demos with full debug on
java-1.8.0-openjdk-demo-debug.x86_64 : OpenJDK Demos 8 with full debug on
java-1.8.0-openjdk-devel.i686 : OpenJDK Development Environment
java-1.8.0-openjdk-devel.x86_64 : OpenJDK Development Environment 8
java-1.8.0-openjdk-devel-debug.i686 : OpenJDK Development Environment with full
java-1.8.0-openjdk-devel-debug.x86_64 : OpenJDK Development Environment 8 with
java-1.8.0-openjdk-headless.i686 : OpenJDK Runtime Environment
java-1.8.0-openjdk-headless.x86_64 : OpenJDK Headless Runtime Environment 8
java-1.8.0-openjdk-headless-debug.i686 : OpenJDK Runtime Environment with full
java-1.8.0-openjdk-headless-debug.x86_64 : OpenJDK Runtime Environment with full
java-1.8.0-openjdk-javadoc.noarch : OpenJDK 8 API documentation
java-1.8.0-openjdk-javadoc-debug.noarch : OpenJDK 8 API documentation for
java-1.8.0-openjdk-javadoc-zip.noarch : OpenJDK 8 API documentation compressed
java-1.8.0-openjdk-javadoc-zip-debug.noarch : OpenJDK 8 API documentation
java-1.8.0-openjdk-src.i686 : OpenJDK Source Bundle
java-1.8.0-openjdk-src.x86_64 : OpenJDK Source Bundle 8
java-1.8.0-openjdk-src-debug.i686 : OpenJDK Source Bundle for packages with
java-1.8.0-openjdk-src-debug.x86_64 : OpenJDK Source Bundle 8 for packages with
java-11-openjdk.i686 : OpenJDK Runtime Environment 11
java-11-openjdk.x86_64 : OpenJDK Runtime Environment 11
java-11-openjdk-debug.i686 : OpenJDK Runtime Environment 11 with full debug on
java-11-openjdk-debug.x86_64 : OpenJDK Runtime Environment 11 with full debug on
java-11-openjdk-demo.i686 : OpenJDK Demos 11
java-11-openjdk-demo.x86_64 : OpenJDK Demos 11
java-11-openjdk-demo-debug.i686 : OpenJDK Demos 11 with full debug on
java-11-openjdk-demo-debug.x86_64 : OpenJDK Demos 11 with full debug on
java-11-openjdk-devel.i686 : OpenJDK Development Environment 11
java-11-openjdk-devel.x86_64 : OpenJDK Development Environment 11
java-11-openjdk-devel-debug.i686 : OpenJDK Development Environment 11 with full
java-11-openjdk-devel-debug.x86_64 : OpenJDK Development Environment 11 with
java-11-openjdk-headless.i686 : OpenJDK Headless Runtime Environment 11
java-11-openjdk-headless.x86_64 : OpenJDK Headless Runtime Environment 11
java-11-openjdk-headless-debug.i686 : OpenJDK Runtime Environment with full
java-11-openjdk-headless-debug.x86_64 : OpenJDK Runtime Environment with full
java-11-openjdk-javadoc.i686 : OpenJDK 11 API documentation
java-11-openjdk-javadoc.x86_64 : OpenJDK 11 API documentation
java-11-openjdk-javadoc-debug.i686 : OpenJDK 11 API documentation for packages
java-11-openjdk-javadoc-debug.x86_64 : OpenJDK 11 API documentation for packages
java-11-openjdk-javadoc-zip.i686 : OpenJDK 11 API documentation compressed in
java-11-openjdk-javadoc-zip.x86_64 : OpenJDK 11 API documentation compressed in
java-11-openjdk-javadoc-zip-debug.i686 : OpenJDK 11 API documentation compressed
java-11-openjdk-javadoc-zip-debug.x86_64 : OpenJDK 11 API documentation
java-11-openjdk-jmods.i686 : JMods for OpenJDK 11
java-11-openjdk-jmods.x86_64 : JMods for OpenJDK 11
java-11-openjdk-jmods-debug.i686 : JMods for OpenJDK 11 with full debug on
java-11-openjdk-jmods-debug.x86_64 : JMods for OpenJDK 11 with full debug on
java-11-openjdk-src.i686 : OpenJDK Source Bundle 11
java-11-openjdk-src.x86_64 : OpenJDK Source Bundle 11
java-11-openjdk-src-debug.i686 : OpenJDK Source Bundle for packages with debug
java-11-openjdk-src-debug.x86_64 : OpenJDK Source Bundle 11 for packages with
java-dirq.noarch : Directory based queue
java-oauth.noarch : An open protocol to allow API authentication
java-runtime-decompiler.noarch : Application for extraction and decompilation of
plplot-java-devel.x86_64 : Development files for using PLplot GNOME

Mais on peut aussi utiliser :

yum list *openjdk*

Installation d’une version de JDK

yum install java-1.8.0-openjdk-devel.x86_64

java -version
openjdk version "1.8.0_201"
OpenJDK Runtime Environment (build 1.8.0_201-b09)
OpenJDK 64-Bit Server VM (build 25.201-b09, mixed mode)

Installation de plusieurs JDK

yum install java-1.8.0-openjdk-devel.x86_64
yum install java-11-openjdk-devel.x86_64

Pour le choix de la version à utiliser deux options sont possibles :

• Option 1: Définition du JDK par défaut via alternatives
• Option 2: Coder en dur le chemin de JAVA_HOME dans la variable PATH

Option 1: Définition du JDK par défaut via alternatives

alternatives indique au système quel JDK utiliser pour l’ensemble du système. On distingue la version à utiliser pour l’exécution d’applications java et pour la compilation d’applications java.

alternatives --config java
alternatives --config javac

On peut vérifier avec la commande :

alternatives --list

Petit programme de test :

cat << EOF > jdkVersions.java
   public class jdkVersions {
      public static void main(String[] args) {
        System.out.println("This app runs on: " + System.getProperty("java.version"));
      }
   }
EOF

Compilation :

javac jdkVersions.java

Exécution :

java jdkVersions
This app runs on: 1.8.0_201

Option 2: Coder en dur le chemin de JAVA_HOME dans la variable PATH

Sous /usr/lib/jvm/, on peut trouver des liens symboliques pointant vers les dernières versions de Java (JRE et SDK) :

ls /usr/lib/jvm/
java                                             jre
java-11                                          jre-11
java-11-openjdk                                  jre-11-openjdk
java-11-openjdk-11.0.2.7-0.el7_6.x86_64          jre-11-openjdk-11.0.2.7-0.el7_6.x86_64
java-1.8.0                                       jre-1.8.0
java-1.8.0-openjdk                               jre-1.8.0-openjdk
java-1.8.0-openjdk-1.8.0.201.b09-2.el7_6.x86_64  jre-1.8.0-openjdk-1.8.0.201.b09-2.el7_6.x86_64
java-openjdk                                     jre-openjdk

Par exemple :

export JAVA_HOME=/usr/lib/jvm/java-11-openjdk
export PATH=$JAVA_HOME/bin:$PATH

java -version
openjdk version "11.0.2" 2019-01-15 LTS
OpenJDK Runtime Environment 18.9 (build 11.0.2+7-LTS)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+7-LTS, mixed mode, sharing)

javac -version
javac 11.0.2

2.4. Installation OpenJDK sur Ubuntu via dépôt

java -version

Command 'java' not found, but can be installed with:

apt install default-jre
apt install openjdk-11-jre-headless
apt install openjdk-8-jre-headless

javac -version

Command 'javac' not found, but can be installed with:

apt install default-jdk
apt install openjdk-11-jdk-headless
apt install ecj
apt install openjdk-8-jdk-headless

Par exemple

sudo apt update && sudo apt -y install openjdk-8-jdk-headless openjdk-11-jdk-headless

Les différentes versions se gèrent via update-alternatives ou la variable JAVA_HOME.

sudo update-alternatives --config java
sudo update-alternatives --config javac

Ces commandes donnent les chemins des différentes versions

On peut aussi peupler cette variable JAVA_HOME via /etc/environment ou manuellement :

export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64/bin/
export PATH=$JAVA_HOME/bin:$PATH

2.5. Installation Oracle Java SE

Installation Ubuntu via PPA

sudo add-apt-repository -y ppa:webupd8team/java && sudo apt-get update

sudo apt-cache search oracle-java
oracle-java8-installer - Oracle Java(TM) Development Kit (JDK) 8
oracle-java8-set-default - Set Oracle JDK 8 as default Java
oracle-java8-unlimited-jce-policy - Unlimited JCE Policy for Oracle Java 8

apt-get -y install oracle-java8-installer oracle-java8-set-default

Source de Oracle JAVA SE

Pour information on peut toujours obtenir les versions “sources” de Oracle Java SE dont le procédure d’installation ne mérite pas d’être détaillée ici.

On ira se rendre sur la page de téléchargement de Java for Linux, choisir sa version, cliquer sur “Download”, choisir le type de paquet (.deb, .rpm, .tar.gz, .mdg, .exe).

On peut aussi réaliser les téléchargement avec wget ou avec curl.

Java SE Development Kit 11.0.2 targz

wget --no-check-certificate -c --header "Cookie: oraclelicense=accept-securebackup-cookie" http://download.oracle.com/otn-pub/java/jdk/11.0.2+9/f51449fcd52f4d52b93a989c5c56ed3c/jdk-11.0.2_linux-x64_bin.tar.gz

Java SE Development Kit 11.0.2 rpm

wget --no-check-certificate -c --header "Cookie: oraclelicense=accept-securebackup-cookie" http://download.oracle.com/otn-pub/java/jdk/11.0.2+9/f51449fcd52f4d52b93a989c5c56ed3c/jdk-11.0.2_linux-x64_bin.rpm

Java SE Development Kit 11.0.2 deb

wget --no-check-certificate -c --header "Cookie: oraclelicense=accept-securebackup-cookie" http://download.oracle.com/otn-pub/java/jdk/11.0.2+9/f51449fcd52f4d52b93a989c5c56ed3c/jdk-11.0.2_linux-x64_bin.deb

Java SE Development Kit 8u202 targz

wget --no-check-certificate -c --header "Cookie: oraclelicense=accept-securebackup-cookie" https://download.oracle.com/otn-pub/java/jdk/8u202-b08/1961070e4c9b4e26a04e7f5a083f551e/jdk-8u202-linux-x64.tar.gz

Java SE Development Kit 8u202 rpm

wget --no-check-certificate -c --header "Cookie: oraclelicense=accept-securebackup-cookie" https://download.oracle.com/otn-pub/java/jdk/8u202-b08/1961070e4c9b4e26a04e7f5a083f551e/jdk-8u202-linux-x64.rpm

3. Le langage Java

3.1. Philosophie du langage Java

Lors de la création du langage Java, il avait été décidé que ce langage devait répondre à cinq objectifs :

• simple, orienté objet et familier ;
• robuste et sûr ;
• indépendant de la machine employée pour l’exécution ;
• très performant ;
• compilé, multi-tâches et dynamique.

3.2. Simple, orienté objet et familier

La première caractéristique, le caractère orienté objet (« OO ») et familier, fait référence à une méthode de programmation et de conception du langage et le fait qu’un programme écrit en Java ressemble assez fort à un programme écrit en C++.

Bien qu’il existe plusieurs interprétations de l’expression orienté objet, une idée phare dans ce type de développement est que les différents types de données doivent être directement associés avec les différentes opérations qu’on peut effectuer sur ces données. En conséquence, les données (appelées Propriétés) et le code les manipulant (appelé Méthodes) sont combinés dans une même entité appelée Classe d’objet. Le code devient logiquement découpé en petites entités cohérentes et devient ainsi plus simple à maintenir et plus facilement réutilisable, étant intrinsèquement modulaire.

D’autres mécanismes tels que l’héritage permettent d’exploiter toutes les caractéristiques d’une Classe précédemment écrite dans ses propres programmes sans même avoir à en connaître le fonctionnement interne — on n’en voit que l’interface (l’interface décrit les propriétés et les méthodes sans fournir le code associé). Java interdit la notion d’héritage depuis plusieurs classes parentes sauf si elles sont des interfaces.

3.3. Robuste et sûr

Cet élément contribue à la robustesse et à la performance des programmes, le ramasse-miettes (Garbage Collector) est appelé régulièrement et automatiquement pendant l’exécution du programme. Sur les systèmes multi-processeurs et/ou multi-coeurs, celui-ci emploie même des “threads” multiples à faible priorité afin de perturber le moins possible l’exécution du programme.

3.4. Indépendant de la machine employée pour l’exécution

L’indépendance vis-à-vis de la plate-forme signifie que les programmes écrits en Java fonctionnent de manière parfaitement similaire sur différentes architectures matérielles. La licence de Sun pour Java insiste ainsi sur le fait que toutes les implémentations doivent être compatibles. On peut ainsi théoriquement effectuer le développement sur une architecture donnée et faire tourner l’application finale sur toutes les autres.

Ce résultat est obtenu par :

• des bibliothèques standard fournies pour pouvoir accéder à certains éléments de la machine hôte (le graphisme, le multithreading, la programmation réseau…) exactement de la même manière sur toutes les architectures ;
• des compilateurs Java qui compilent le code source « à moitié » afin d’obtenir un bytecode (plus précisément le bytecode Java, un langage de type assembleur, proche de la machine virtuelle et spécifique à la plate-forme Java).

Ce bytecode a ensuite vocation à être interprété sur une machine virtuelle Java (JVM en anglais), un programme écrit spécifiquement pour la machine cible qui interprète le bytecode Java et fait exécuter par la machine les instructions traduites en code natif.

Même s’il y a explicitement une première phase de compilation, le bytecode Java est soit interprété, soit converti à la volée en code natif par un compilateur à la volée (just in time, JIT).

Après que Sun eut constaté que l’implémentation de Microsoft ne supportait pas les interfaces RMI et JNI, et comportait des éléments spécifiques à certaines plates-formes par rapport à sa plate-forme initiale, Sun déposa plainte en justice contre Microsoft, et obtint des dommages et intérêts (20 millions de dollars). Cet acte de justice renforça encore les termes de la licence de Sun. En réponse, Microsoft arrêta le support de Java sur ses plates-formes et, sur les versions récentes de Windows, Internet Explorer ne supporte pas les applets Java sans ajouter de plug-in. Cependant, Sun met à disposition gratuitement des environnements d’exécution de Java pour les différentes plates-formes Microsoft.

La portabilité est techniquement un objectif difficile à atteindre et le succès de Java en ce domaine est mitigé. Quoiqu’il soit effectivement possible d’écrire des programmes pour la plate-forme Java qui fonctionnent correctement sur beaucoup de machines cibles, le nombre important de plates-formes avec de petites erreurs et des incohérences a abouti à un détournement du slogan de Sun « Write once, run anywhere » (« Écrire une fois, exécuter n’importe où ») en « Write once, debug everywhere » (« Écrire une fois, déboguer partout ») !

Mais l’indépendance de Java vis-à-vis de la plate-forme est cependant un succès avec les applications côté serveur comme les services web, les servlets et le Java Beans aussi bien que les systèmes embarqués sur OSGi, utilisant l’environnement Embedded Java.

3.5. Hello World Java

Voici un exemple d’un programme “Hello world” typique écrit en Java :

public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello world!");
    }
}

Le fichier source porte presque toujours le nom de la classe avec l’extension “.java” (ici “HelloWorld.java”, ce serait même obligatoire si la classe avait l’attribut public dans sa déclaration — la rendant alors accessible à tout autre programme). On peut compiler puis exécuter cet exemple sur le terminal avec les commandes suivantes (sous Linux) :

javac HelloWorld.java
export CLASSPATH=.
java HelloWorld

La ligne « export CLASSPATH=. » sert à indiquer à Java qu’il doit également chercher les programmes class dans le répertoire courant. Ce chemin peut également être spécifié au lancement du programme par l’option -classpath (ou -cp en abrégé) :

java -cp. HelloWorld

3.6. Notion de classe

Une classe est la description de données appelées attributs, et d’opérations appelées méthodes. Il s’agit d’un modèle de définition pour des objets ayant le même ensemble d’attributs, et le même ensemble d’opérations. À partir d’une classe on peut créer un ou plusieurs objets par instanciation ; chaque objet est une instance d’une seule classe.

3.7. Notion d’attribut

Un attribut se définit en donnant son type, puis son nom, et éventuellement une partie initialisation.

3.8. Notion de méthode

Une méthode est définie par :

• Son type de retour : type de la valeur retournée par la méthode. Si la méthode ne retourne pas de valeur le type spécifié est alors void.
• Son nom
• Ses paramètres : les paramètres sont spécifiés par leur type et leur nom et sont séparés par des virgules.

3.9. Concepts POO Java à retenir

• Modularité et encapsulation
• Objet et méthodes
• Classe
• Héritage
• Délégation
• Interface
• Polymorphisme
• Paquet
• Threads

Voir le livre : LONCHAMP J., Conception d’applications en Java/JEE, 2e édition, Coll. InfoSup, Dunod, Paris, 2019.

3.10. Frameworks et API Java

Sun (Oracle) fournit un grand nombre de frameworks et d’API afin de permettre l’utilisation de Java pour des usages très diversifiés.

On distingue essentiellement quatre grands frameworks :

• Java SE (anciennement J2SE) : Ce framework est destiné aux applications pour poste de travail ;
• Java EE (anciennement J2EE) : Ce framework est spécialisé dans les applications serveurs. Il contient pour ce faire un grand nombre d’API et d’extensions ;
• Java ME (anciennement J2ME) : Ce framework est spécialisé dans les applications mobiles ;
• Java FX (à ne pas confondre avec JavaFX) : Ce framework est spécialisé dans les applications liées aux cartes à puces et autres SmartCards. Il recouvre notamment l’ancien Java Card.

La persistance est fondée sur les standards :

• JDBC (Java DataBase Connectivity) ;
• JDO (Java Data Objects) ;
• EJB (Enterprise Java Beans).

On trouve toutefois de nombreuses autres technologies, API et extensions optionnelles pour Java :

• Java Media Framework : framework multimédia, contenant notamment les API Java2D, Java 3D, JavaSound, Java advanced Imaging ;
• Java Telephony API ;
• Java TV ;
• JXTA : Système de peer-to-peer reposant sur Java ;
• Jini ;
• JAIN ;
• Java Dynamic Management Kit (JMDK) ;
• JavaSpeech ;
• JMI ;
• JavaSpaces.

4. Outils / environnements de développement (IDE)

La programmation peut se faire depuis une invite de commande en lançant un compilateur Java (souvent nommé javac), mais pour avoir plus de confort, il est préférable d’utiliser un environnement de développement intégré ou IDE, certains sont gratuits.

En programmation informatique, un environnement de développement est un ensemble d’outils qui permet d’augmenter la productivité des programmeurs qui développent des logiciels. Il comporte un éditeur de texte destiné à la programmation, des fonctions qui permettent, par pression sur un bouton, de démarrer le compilateur ou l’éditeur de liens ainsi qu’un débogueur en ligne, qui permet d’exécuter ligne par ligne le programme en cours de construction. Certains environnements sont dédiés à un langage de programmation en particulier.

Dans un environnement de développement « intégré » (abrégé EDI en français ou IDE en anglais, pour “integrated development environment”), les outils sont prévus pour être utilisés ensemble (le produit d’un outil peut servir de matière première pour un autre outil). Les outils peuvent être intégrés dès le départ, c’est-à-dire qu’ils sont construits dans le but d’être utilisés ensemble. Il peut aussi s’agir d’un ensemble d’outils développés sans lien entre eux et intégrés a posteriori.

L’objectif d’un environnement de développement est d’augmenter la productivité des programmeurs en automatisant une partie des activités et en simplifiant les opérations. Les environnements de développement visent également à améliorer la qualité de la documentation en rapport avec le logiciel en construction5. Certains environnements de développement offrent également la possibilité de créer des prototypes, de planifier les travaux et de gérer des projets.

Source : Environnement de développement

4.1. Offre d’IDE IDE Java EE

On peut citer les produits suivants dans le cadre d’un développement en Java :

• Eclipse
• NetBeans
• IntelliJ IDEA

On ira se renseigner utilement sur la page Choosing your Java IDE

Le pré-requis est l’installation des JDK 11 ou 8.

4.2. Installation de l’IDE Eclipse

Eclipse Installer 2019-03 R

4.3. Installation de l’IDE Apache NetBeans

Pré-requis : JDK 11.

Apache NetBeans 10.0

wget https://www.apache.org/dyn/closer.cgi/incubator/netbeans/incubating-netbeans/incubating-10.0/incubating-netbeans-10.0-bin.zip
unzip incubating-netbeans-10.0-bin.zip
mv netbeans/ /opt/
export PATH="$PATH:/opt/netbeans/bin/"
netbeans

5. Automatisation des builds

Un programme Java peut être produit avec des outils qui automatisent le processus de construction (c’est-à-dire l’automatisation de certaines tâches faisant appel à un nombre potentiellement grand de dépendances comme l’utilisation de bibliothèques, la compilation, la génération d’archives, de documentation, le déploiement, etc.). Les plus utilisés sont :

• Apache Ant (génération portable, décrite en XML) ;
• Apache Maven (génération portable, décrite en XML) ;
• Gradle (génération portable, en utilisant le langage Groovy) ;
• SCons (génération portable, en utilisant le langage Python)