En quoi Java est-il différent de Javascript ? Comparaison de Java et JavaScript. Plus difficile ou quoi - Quelle est la différence entre JavaScript et Java

À première vue, Java et JavaScript sont deux langages de programmation portant des noms très similaires et souvent confondus. Et ce sont tous deux des langages de programmation orientés objet. Mais ce n’est qu’à première vue ; en fait, il y a bien plus de différences que de similitudes entre eux.

Pour commencer à parler des différences entre JAVA et JavaScript, il est nécessaire de définir clairement ces deux concepts. JavaScript est un langage de programmation et Java peut également être compris comme une plateforme de développement. Pour permettre de comparer ces deux concepts, nous entendrons ci-dessous Java non pas comme une plateforme de développement, mais comme un langage de programmation.

Objectifs JAVA et JavaScript

JAVA est un langage de programmation orienté objet, initialement développé pour la programmation d'appareils électroménagers (appelé Qak). Plus tard, le langage Java a commencé à être utilisé pour écrire divers types de logiciels, d'applets, d'applications de bureau et de serveur.

JavaScript est un langage de programmation de script orienté objet dont le but initial était d'écrire des scripts pour les pages HTML actives. Un langage de programmation de script est utilisé pour contrôler et automatiser un système ou une application existant.

Si l’on compare ces langages de programmation en fonction de leurs définitions, on peut déjà voir leur principale différence. Java est un langage de programmation permettant de créer différents types d'applications, et JavaScript est un langage de support utilisé dans les applications déjà créées et également comme langage de programmation supplémentaire.

3 différences fondamentales entre les langages de programmation Java et JavaScript :

1. JAVA est un langage de programmation orienté objet et JavaScript est un langage de script orienté objet.

2. À l'aide de JAVA, des applications sont créées et s'exécutent sur des machines virtuelles ou dans des navigateurs, tandis que JavaScript ne s'exécute que dans les navigateurs.

3. Le code JAVA doit être compilé et le code JavaScript est utilisé sous forme de texte.

Le fait est qu'à l'origine JavaScript s'appelait LiveScript, mais après que le langage de programmation Java soit devenu mondialement célèbre, LiveScript a été renommé JavaScript pour des raisons commerciales.

Utiliser JavaScript dans le WEB

De par sa simplicité et sa commodité, JavaScript est très souvent utilisé dans le monde WEB. À mesure que la complexité des sites et des diverses applications WEB augmente, son utilisation commence par le changement dynamique des éléments du site, avant leur génération et le développement de la partie serveur (architecture client-serveur) de différents types d'applications. Avec son aide, divers frameworks et bibliothèques sont créés qui offrent des solutions toutes faites aux problèmes de programmation typiques dans le domaine WEB.

JavaScript est le plus souvent utilisé pour l'interaction interactive de l'utilisateur avec l'interface de l'application, lorsque, lors de l'exécution de certaines actions, l'application modifie son style de conception, comme si elle interagissait avec l'utilisateur. De telles réactions aux actions des utilisateurs, dans des limites raisonnables, peuvent rendre l'interaction avec l'application plus pratique et informative.

JavaScript a ce qu'on appelle une « faible barrière à l'entrée », c'est-à-dire que pour l'apprendre, vous devez avoir un peu de connaissances dans le domaine du WEB, notamment les concepts de base du HTML et du CSS.
Il existe désormais de nombreuses ressources gratuites pour apprendre JavaScript : livres, articles, forums, tutoriels vidéo, cours en ligne, etc., qui vous aident à maîtriser facilement JavaScript du niveau débutant jusqu'à une utilisation avancée.

Si vous regardez les statistiques de GitHub, vous verrez que JavaScript et Java sont les deux hégémons du monde de la programmation moderne, devant C/C++, Python, PHP et Ruby. Malgré le fait que leurs noms soient similaires, que JavaScript, à en juger par son nom, soit une version plus légère, compréhensible et plus pratique de Java, il n'y a toujours presque rien de commun entre eux.

Dans cet article, nous examinerons les principales caractéristiques de ces langages, montrant que le nom commun n’est rien de plus que l’idée initiale des développeurs.

Java

Le langage Java, appelé « Oak » et « Green » lors de son développement, est officiellement né en 1995. Il a beaucoup emprunté au C/C++, mais a promu de nouveaux concepts incluant une programmation simple et sûre. Java était donc initialement perçu comme l’héritier de ces langages les plus populaires.

Le principe de base du code Java est que le programmeur peut écrire le code une seule fois afin qu'il puisse fonctionner n'importe où. Au lieu de compiler des fichiers différents pour chaque plateforme, un fichier JAR est créé ici. Et si le système prend en charge Java, alors le fichier est exécuté.

Pour mettre en œuvre cette idée, la JVM, ou Java Virtual Machine, est utilisée. Ce n'est rien de plus qu'un ensemble d'instructions qui déterminent la compilation spécifique à la plate-forme et l'exécution ultérieure du code. Ce principe est appelé juste à temps.

Principales applications de Java :

• Applications Android. C’est la langue officielle du système d’exploitation le plus populaire aujourd’hui. Cela signifie que pour obtenir les meilleurs résultats et utiliser le maximum de fonctionnalités, Java est le langage idéal.
• Applications de bureau. De plus, Java est l'un des outils permettant de créer des logiciels multiplateformes. JavaFX et SWT pour vous aider.
• Systèmes d'entreprise. Dans les secteurs liés au traitement des données personnelles (banque, finance, commerce), Java est utilisé comme un langage fiable, facile à maintenir et rapide.
• Systèmes embarqués. Les montres intelligentes, certains contrôleurs, feux de circulation et même certains systèmes de voitures hybrides utilisent Java. Le vecteur de développement le plus actuel est l’Internet des objets.
• Recherche scientifique. MATLAB et Python sont ici beaucoup plus populaires, mais Java s'adapte également bien aux tâches complexes, telles que le traitement du langage ou la gestion de l'intelligence artificielle.

Javascript

JavaScript a été développé contre les énormes limitations du HTML. Netscape Communications prévoyait le besoin imminent d'un Web dynamique et fonctionnel. En seulement 10 jours, ils ont créé un langage appelé LiveScript en 1995.

Plus tard, les développeurs ont eu l'idée d'ajouter des fonctionnalités utilisant Java. C'est ainsi qu'est né le nom final et une syntaxe similaire. Certes, c'est là que s'arrêtent toutes les similitudes. Pour des raisons évidentes, Java n'était pas encore lancé sur le Web à cette époque, tandis que JavaScript a rapidement gagné en popularité, devenant, avec HTML et CSS, les principaux piliers de l'Internet moderne.

Contrairement à Java, dont le code est compilé, le code JavaScript est interprété. Autrement dit, lorsque vous visitez une page Web, votre navigateur reçoit le code écrit en JavaScript et l'exécute immédiatement. Pour cela, des moteurs spéciaux sont utilisés, chaque navigateur utilise le sien : V8 - Chrome, SpiderMonkey - Firefox, Chakra - Edge, etc.

Aujourd’hui, cependant, JavaScript n’est plus un outil réservé aux navigateurs. Depuis plus de deux décennies depuis sa création, JavaScript s'est imposé comme l'un des langages de programmation les plus flexibles, également utilisé dans d'autres domaines :

• Applications Web. JavaScript est incroyablement efficace pour le développement front-end et back-end. Dans le premier cas, cela implique une manipulation du DOM côté navigateur (animation, insertions de données, mises à jour), dans le second - côté serveur (routage, traitement des données, interaction avec la base de données).
• Applications mobiles. Des outils comme React Native et PhoneGap vous permettent de créer des applications mobiles complètes en utilisant uniquement JavaScript. Ces frameworks sont divisés en deux types : ceux qui traduisent JavaScript en code natif et ceux qui utilisent eux-mêmes le moteur JavaScript.
• Applications de bureau. Vous pouvez mettre JavaScript hors ligne à l'aide de frameworks tels qu'Electron et NE.js. Le moteur est regroupé dans un fichier exécutable et le code HTML/CSS/JS est exécuté dans la fenêtre qui s'ouvre.

Alors que choisir ?

Compte tenu du niveau de développement actuel des deux langages, le choix se résume en fait aux exigences spécifiées en matière de performances, de fonctionnalités et de vitesse d'exécution.

Java est un langage légèrement plus complexe avec plus de restrictions. Les applications Java sont moins sujettes aux erreurs et généralement plus fonctionnelles que celles créées à l'aide de JavaScript. Mais cela a aussi un prix, le principal étant le temps et la complexité du développement. Les applications JavaScript nécessiteront moins d'efforts de votre part, mais leur exécution prendra plus de temps, davantage d'erreurs apparaîtront lors du débogage et il est peu probable que vous souhaitiez écrire du code complexe.

Par conséquent, il est préférable d'utiliser JavaScript pour le Web et de laisser le développement de logiciels complexes et complexes à Java. Lorsqu’il s’agit de créer des applications de bureau et mobiles, c’est une question de goût. Je recommanderais d'utiliser Java car cela garantira un code propre et moins d'erreurs. D’un autre côté, JavaScript convient également à cela.

J'ai promis d'écrire un article sur l'utilisation de GraalVM pour mélanger Java et JS. La voici.

Quel est le problème ? Dans la pratique quotidienne, nous rencontrons souvent des applications composées de deux parties : un frontend JavaScript et un backend Java. Organiser une interopérabilité entre eux demande des efforts. En règle générale, ils sont effectués par des personnes de différents côtés des barricades, et lorsqu'ils tentent de pénétrer dans la zone de quelqu'un d'autre, ils commencent à souffrir. Il existe aussi des développeurs web full-stack, mais tout est clair chez eux : ils doivent toujours souffrir.

Dans cet article, nous examinerons une nouvelle technologie qui peut rendre le processus un peu moins pénible. Plus précisément, la méthode existe depuis assez longtemps, mais a en quelque sorte retenu l'attention du grand public.

Si l'un des Javaistes n'a pas encore écrit en React, il y aura ici un tutoriel qui vous permettra de le faire. Si l'un des Javascripteurs n'a pas essayé d'écrire en Java, alors dans ce didacticiel, vous pourrez en parler (bien que sur une seule ligne et via les liaisons JS).

JS->Java. Faisons bouger les choses : Nashorn

Si vous souhaitez une interopérabilité Java->JS, il existait une telle technologie dans le JDK il y a longtemps, et elle s'appelle Nashorn (lire : « Nashorn »).

Prenons une situation réelle. De temps en temps, d'année en année, les gens continuent d'écrire des validateurs « serveur » en Java et des validateurs « client » en JS. Le cynisme particulier ici est que les contrôles coïncident souvent à 80 %, et toute cette activité est en fait une forme particulière de perte de temps.

Imaginons que nous ayons un validateur très stupide :

var validate = function(target) ( if (target > 0) ( return "success"; ) else ( return "fail"; ) );

Nous pouvons le lancer sur les trois plateformes :

• Navigateur
• Noeud.js

Dans un navigateur, c'est trivial. Nous intégrons simplement ce morceau de code n'importe où, et cela fonctionne.

Dans Node.js, vous devez soit respecter leur approche feng shui de l'utilisation de require, soit le pirater avec ce code simple :

var fs = require("fs"); var vm = require("vm"); var includeInThisContext = function(chemin) ( var code = fs.readFileSync(chemin); vm.runInThisContext(code, chemin); .bind(this); includeInThisContext(__dirname + "/" + nom de fichier);

Préparez-vous au fait que si vous utilisez de telles techniques, vos collègues pourraient bientôt commencer à vous considérer comme un épouvantail. Nous, Javaistes, n'y sommes pas étrangers, mais les Javascripteurs professionnels peuvent être gênés.

Maintenant nous allons faire la même chose, mais sous Nashorn en Java.

public class JSExecutor ( private static final Logger logger = LoggerFactory.getLogger(JSExecutor.class); moteur ScriptEngine = new ScriptEngineManager().getEngineByName("nashorn"); invocable invocable = (Invocable) moteur; public JSExecutor() ( try ( File bootstrapFile = new ClassPathResource("validator.js").getFile(); String bootstrapString = new String(Files.readAllBytes(bootstrapFile.toPath())); engine.eval(bootstrapString) catch (Exception e) (logger. error( "Impossible de charger le bootstrap JS!", e); ) ) public Object perform(String code) ( Object result = null; try ( result = engine.eval(code); ) catch (Exception e) ( logger. error( "Impossible d'exécuter JS !", e); ) return result; ) public Object executeFunction(String name, Object... args) ( Object result = null; try ( result = invoker.invokeFunction(name, args) ; ) catch (Exception e) ( logger.error("Can"t run JS!", e); ) return result; ) )

Comme vous pouvez le voir, vous pouvez extraire à la fois du code arbitraire et une fonction distincte par son nom.

Il existe bien entendu des problèmes qui ne peuvent être résolus que manuellement. Par exemple, vous pouvez créer un polyfill comme ceci :

var global = ceci ; var fenêtre = ceci ; var processus = (env:()); var console = (); console.debug = imprimer; console.log = imprimer; console.warn = imprimer; console.erreur = imprimer;

Si vous souhaitez que le code du validateur soit parfaitement identique sur le serveur et sur le client, vous devrez écrire des stubs pour les méthodes « serveur », qui sont poussées uniquement dans le navigateur. Ce sont déjà des détails d’une implémentation spécifique.

À propos, ab sur mon ordinateur portable (ab -k -c 10 -n 100 http://localhost:3000/?id=2) affiche 6 à 7 000 requêtes par seconde pour ce code, et peu importe quoi il fonctionne sur Nashorn ou Node.js. Mais il n'y a rien d'intéressant à cela : d'une part, ab sur localhost mesure la météo sur Mars, et d'autre part, on pense déjà qu'il n'y a pas d'erreurs évidentes dans ces moteurs, ce sont des concurrents.

Il est clair que si vous vivez dans la « zone rouge » de la courbe Sh. vous ne pouvez pas utiliser Nashorn sans allumer votre cerveau et écrire des benchmarks. Si vous réfléchissez bien, vous pouvez écrire un benchmark où Nashorn s'affaissera, et il serait plus correct d'écrire du code natif. Mais nous devons clairement comprendre que le monde ne se limite pas aux thèmes de forte charge et de performance, parfois la commodité d'écriture est plus importante que n'importe quelle performance.

Java->JS. Problème

Essayons de pousser les données dans la direction opposée, de Java vers JS.

Pourquoi cela pourrait-il être nécessaire ?

Premièrement, et surtout, dans de nombreuses entreprises, il existe un axiome indiscutable : nous utilisons Java. Dans certaines banques. Deuxièmement, lors de la résolution de problèmes quotidiens, de tels problèmes surviennent constamment.

Prenons un cas de jouet de la vie réelle. Imaginez : vous devez générer un front avec webpack et vous souhaitez écrire la version actuelle de l'application dans le coin supérieur droit de la page Web. Il est probable que la version backend puisse être extraite de la manière normale uniquement en appelant du code Java (hérité). Cela signifie que vous devez créer un projet Maven qui fonctionnera en deux passes : attacher à une phase du cycle de vie de build Maven l'assemblage de quelques classes et leur lancement, ce qui générera un fichier de propriétés avec un numéro de version, qui être récupéré par npm appelé manuellement dans la phase suivante.

Je ne donnerai pas d'exemple d'un tel pom.xml ici, car c'est dégoûtant :)

Plus généralement, le problème est que la culture moderne soutient et encourage les programmeurs polyglottes et les projets écrits dans plusieurs langues. De là découlent les points suivants :

• Les développeurs souhaitent utiliser le langage qui convient le mieux au problème posé. Il est très pénible d'écrire une interface Web en Java (au moins jusqu'à ce que la JVM et OpenJDK se stabilisent sur WebAssembly), mais en JS c'est simple et pratique.
• Souvent, vous souhaitez développer plusieurs bases de code en parallèle. Par exemple, il y a une base en JS - front et une autre base en Java - back. Je voudrais développer des projets, en réécrivant lentement l'intégralité de l'application dans Node.JS, y compris le code du serveur - dans les endroits où Java n'est pas vraiment nécessaire. Il ne devrait pas y avoir de « jour numéro zéro » lorsque l'ensemble du backend Java ou du frontend JS va à la casse, et laisser le monde entier attendre que nous en écrivions un nouveau.
• Lorsque vous franchissez une frontière linguistique, vous devez écrire manuellement beaucoup de code inutile qui fournit l'interopérabilité.

Parfois, il existe des solutions toutes faites - par exemple, franchir la frontière Java/C se fait à l'aide de JNI.

L’utilisation d’une telle intégration est également une bonne chose car, comme aiment le dire les programmeurs fonctionnels, « ce qui n’existe pas ne se brisera pas ». Si nous prenons en charge les pom.xml infernaux, les fichiers de propriétés et XML et autres interopérabilités manuelles dans notre code, alors ils ont tendance à se briser dans les moments les plus désagréables. Si cette couche a été écrite par de vrais nerds du combat, comme Oracle ou Microsoft, elle ne se casse presque pas, et quand elle se casse, ce n'est pas à nous de la réparer.

Revenant à l'exemple précédent : pourquoi devons-nous nous lever deux fois et faire des miracles avec Nashorn, si nous ne pouvons pas nous lever du tout et écrire l'intégralité de l'interface utilisateur uniquement sur Node ?

Mais comment faire cela, étant donné que vous devez aspirer de manière transparente les données de Java ?

La première pensée qui me vient à l’esprit est de continuer à utiliser Nashorn. Aspirez-y toutes les bibliothèques nécessaires, classez-les et peut-être qu'elles démarreront même. Si parmi eux personne n’a besoin d’extensions natives. Et émulez manuellement l’ensemble de l’infrastructure Node. Et autre chose. Cela semble être un problème. En général, il existait déjà un tel projet, il s'appelait Projet Avatar et, malheureusement, il est mort. Si les développeurs d'Oracle n'ont pas pu le réaliser, quelle est la chance qu'ils puissent le faire eux-mêmes ?

Java->JS. Graal

Heureusement, nous avons un autre projet assez nouveau et intéressant : Graal.js. C'est-à-dire la partie de Graal responsable de l'exécution de JavaScript.

Les projets innovants du monde du JDK sont souvent perçus comme quelque chose de lointain et d’irréel. Graal est différent à cet égard : il est apparu très soudainement en tant que concurrent mature.

Graal ne fait pas partie d'OpenJDK, mais un produit distinct. Il est connu que dans les dernières versions d'OpenJDK, vous pouvez basculer le compilateur JIT de C2 vers celui fourni avec Graal. De plus, Graal est livré avec le framework Truffle, qui peut être utilisé pour implémenter divers nouveaux langages. Dans ce cas, les développeurs d'Oracle Labs ont implémenté la prise en charge de JavaScript.

Pour avoir une idée de sa simplicité et de sa commodité, examinons un exemple de projet de jouet.

Imaginons que nous abattions un OVNI sur Habré.

Dans la première version de Slashing, UFO pourra bannir des personnes aléatoires, et le bouton s'appellera « Ban quelqu'un ! » Dans la deuxième version, le bouton interdira soit les trolls, soit les spammeurs, et ceux que nous interdisons maintenant seront chargés depuis Java. Afin de minimiser l'exemple, seule l'étiquette du bouton changera ; nous ne modifierons pas la logique métier.

Il existe de nombreuses étapes pour créer une application React, elles sont donc soigneusement divisées en étapes. Au final, j'obtiens une application fonctionnelle, j'ai vérifié.

Partie 1. Préparation de la demande1. Téléchargez le GraalVM « entreprise » (via le lien) et définissez les variables d'environnement Java habituelles.

La version Enterprise est nécessaire car c'est la seule version qui dispose de GraalJS.

Vous pouvez, par exemple, écrire ceci dans .bash_profile :

graalvm () ( export LABSJDK=/Users/olegchir/opt/graalvm-0.33/Contents/Home export LABSJRE=/Users/olegchir/opt/graalvm-0.33/Contents/Home/jre export JDK_HOME=$LABSJDK export JRE_HOME=$LABSJRE export JAVA_HOME=$JDK_HOME export PATH=$JDK_HOME/bin:$JRE_HOME/bin:$PATH )

Et puis après avoir redémarré le shell, appelez cette fonction : graalvm.

Pourquoi est-ce que je suggère de créer une fonction bash distincte et de l'appeler selon les besoins, plutôt que d'un seul coup ? Tout est très simple ici : une fois que GraalVM est entré dans le PATH, votre système npm normal (par exemple, /usr/local/bin/npm sur macOS) sera remplacé par notre version Java spéciale ($JDK_HOME/bin/npm). Si vous êtes un développeur JS, un tel remplacement permanent n'est pas la meilleure idée.

2. Créez un répertoire pour le projet mkdir -p ~/git/habrotest cd ~/git/habrotest 3. npm init (remplissez judicieusement, mais vous pouvez simplement cliquer sur le bouton Entrée)4. Installez les modules nécessaires : Webpack, Babel, React npm i --save-dev webpack webpack-cli webpack-dev-server npm i --save-dev babel-core babel-loader babel-preset-es2015 babel-preset-react npm je --save réagir réagir-dom

Notez que npm peut être légèrement obsolète (par rapport à la version "réelle") et vous demandera de le mettre à jour. Cela ne vaut pas la peine d'être mis à jour.

5. Créez les répertoires dans lesquels le travail aura lieu : mkdir -p src/client/app mkdir -p src/client/public mkdir -p loaders 6. Apprenez nos langages Babel :
( "presets" : ["es2015", "react"] ) 7. Configuration du webpack :

./webpack.config.js :

var p = require("chemin"); var webpack = require("webpack"); var BUILD_DIR = p.resolve(__dirname, "src/client/public"); var APP_DIR = p.resolve(__dirname, "src/client/app"); var config = ( sortie : ( chemin : BUILD_DIR, nom de fichier : "bundle.js" ), entrée : APP_DIR + "/index.jsx", module : ( règles : [ ( test : /\.jsx?/, include : APP_DIR , chargeur : "babel-loader" ) ] ) ); module.exports = config;

8. Créez une page pour notre application :

./src/client/index.html

Bienvenue dans la timonerie d'UFO 9. Créez un index (afin que nous puissions ensuite y insérer le composant de démonstration) :

./src/client/app/index.jsx

importer React depuis « react » ; importer (rendu) depuis « react-dom » ; importer NLOComponent depuis "./NLOComponent.jsx" ; la classe App étend React.Component ( render () ( return (

Bienvenue dans la timonerie, OVNI

);

importer React depuis « react » ; la classe NLOComponent étend React.Component ( constructor(props) ( super(props); this.state = (banned: 0); this.onBan = this.onBan.bind(this); ) onBan() ( let newBanned = this. state.banned + 10; this.setState((banned: newBanned)); render() ( return ( Interdire quelqu'un ! 11. Exécutez le build : webpack -d

Tout devrait s'assembler avec succès et produire quelque chose comme :

joker:habrotest olegchir$ webpack -d Hash : b19d6529d6e3f70baba6 Version : webpack 4.5.0 Temps : 19358 ms Construit à : 2018-04-16 05:12:49 Taille de l'actif Morceaux Noms des morceaux bundle.js 1,69 Mo main main Point d'entrée main = bundle. js [./src/client/app/NLOComponent.jsx] 3,03 KiB (principal) [./src/client/app/index.jsx] 2,61 KiB (principal) + 21 modules cachés 12. Vous pouvez maintenant l'ouvrir dans le browser./src/client/index.html et profitez de la vue suivante :

La première partie du tutoriel est terminée, vous devez maintenant apprendre à changer l'étiquette du bouton.

Partie 2. On glisse des variables13. Essayons d'implémenter dans notre composant les variables « nom du bouton » (buttonCaption) et « liste d'options » (buttonVariants), dont on ne sait rien en JS. À l'avenir, ils seront extraits de Java, mais pour l'instant vérifions simplement que leur utilisation entraîne une erreur : import React from "react" ; la classe NLOComponent étend React.Component ( constructor(props) ( super(props); this.state = (interdit : 0, bouton : buttonCaption); this.onBan = this.onBan.bind(this); ) onBan () ( let newBanned = this.state.banned + 10; this.setState((banned: newBanned, bouton: boutonVariants)); render() ( return ( Nombre de bannis : (this.state.banned) (this.state.button) ) ; ) ) exporter le NLOComponent par défaut ;

Nous voyons une erreur honnête :

NLOComponent.jsx?8e83:7 Uncaught ReferenceError : ButtonCaption n'est pas défini dans le nouveau NLOComponent (NLOComponent.jsx?8e83:7) dans constructClassInstance (react-dom.development.js?61bb:6789) dans updateClassComponent (react-dom.development. js?61bb:8324) sur beginWork (react-dom.development.js?61bb:8966) sur performUnitOfWork (react-dom.development.js?61bb:11798) sur workLoop (react-dom.development.js?61bb:11827) ) sur HTMLUnknownElement.callCallback (react-dom.development.js?61bb:104) sur Object.invokeGuardedCallbackDev (react-dom.development.js?61bb:142) sur EnsureGuardedCallback (react-dom.development.js?61bb:191) at replayUnitOfWork (react-dom.development.js?61bb:11302) (anonyme) @ bundle.js:72 réagir-dom.development.js?61bb:9627 L'erreur ci-dessus s'est produite dans le composant : dans NLOComponent (créé par App) dans div (créé par App) dans l'application 14. Faisons maintenant connaissance avec la manière légale de transmettre des variables dans Webpack. Ce sont des chargeurs.

Tout d'abord, vous devez réécrire légèrement la configuration du webpack afin de charger facilement les chargeurs personnalisés :

var p = require("chemin"); var webpack = require("webpack"); var BUILD_DIR = p.resolve(__dirname, "src/client/public"); var APP_DIR = p.resolve(__dirname, "src/client/app"); let defaults = ( sortie : ( chemin : BUILD_DIR, nom de fichier : "bundle.js" ), entrée : APP_DIR + "/index.jsx", module : ( règles : [ ( test : /\.jsx?/, include : APP_DIR , chargeur : "babel-loader" ) ] ), solveLoader : ( modules : ["node_modules", p.resolve(__dirname, "loaders")] ) ); module.exports = fonction (contenu) ( let dd = valeurs par défaut; dd.module.rules.push(( test: /index\.jsx/, chargeur: "preload", options: () )); return dd; );

(Notez que vous pouvez mettre n'importe quelle donnée dans les options du chargeur, puis la lire en utilisant loaderUtils.getOptions(this) à partir du module loader-utils)

Eh bien, maintenant, en fait, nous écrivons un chargeur. Le chargeur est conçu bêtement : nous recevons le code original en entrée du paramètre source, nous le modifions à volonté (nous ne pouvons pas le modifier) ​​puis le renvoyons.

./loaders/preload.js :

const loaderUtils = require("loader-utils"), schemaUtils = require("schema-utils"); module.exports = function main(source) ( this.cacheable(); console.log("applying loader"); var initial = "Ban the troll!"; var variants = JSON.stringify(["Ban the troll!"; , " Bannissez le spammeur ! "]); return `window.buttonCaption=\"$(initial)\";` + `window.buttonVariants=$(variants);` + `$(source)` );

Nous reconstruisons en utilisant webpack -d .

Tout fonctionne bien, il n'y a aucune erreur.

Partie 3. Ajouter du code Java15. Maintenant, vous vous demandez : d'accord, nous avons appris un sale petit hack de Webpack, mais qu'est-ce que Java a à voir avec cela ?

Ce qui est intéressant ici, c'est que notre chargeur ne s'exécute pas comme ça, mais sous le Graal. Cela signifie qu'en utilisant une API similaire à celle de Nashorn, vous pouvez travailler à partir de JS avec des types Java.

const loaderUtils = require("loader-utils"), schemaUtils = require("schema-utils"); module.exports = function main(source) ( this.cacheable(); console.log("applyingloader"); //Nous pouvons obtenir des types Java et créer des objets de ce type var JavaString = Java.type("java.lang . String"); var initial = new JavaString("Ban le troll!"); //Nous pouvons convertir les données dans les deux sens var jsVariants = ["Ban le troll!", "Ban le spammeur!"]; var javaVariants = Java .to(jsVariants, "java.lang.String"); var variants = JSON.stringify(javaVariants); //Mais l'interopérabilité n'est pas toujours bonne, et vous devez ensuite utiliser des béquilles return `window.buttonCaption=\"$ (initial)\ ";` + `window.buttonVariants=$(variants);` + `$(source)`; );

Et bien sûr, webpack -d .

16. Lorsque nous essayons de construire avec webpack, nous voyons l'erreur : ERREUR dans ./src/client/app/index.jsx La construction du module a échoué : ReferenceError : Java n'est pas défini dans Object.main (/Users/olegchir/git/habrotest /loaders/preload.js:9:19)

Cela se produit parce que les types Java ne sont pas disponibles par défaut et sont activés par un indicateur spécial --jvm , qui n'est disponible que dans GraalJS, mais pas dans Node « normal ».

Par conséquent, vous devez le récupérer avec une commande spéciale :

nœud --jvm node_modules/.bin/webpack -d

Comme taper tout cela est assez fastidieux, j'utilise un alias dans bash. Par exemple, dans .bash_profile vous pouvez insérer la ligne suivante :

alias graal_webpack_build="node --jvm node_modules/.bin/webpack -d"

Ou quelque chose d’encore plus court pour rendre la frappe agréable.

17. BÉNÉFICES !

Le résultat peut être consulté dans mon référentiel GitHub. Les fichiers collectés sont directement déposés dans le référentiel afin que vous puissiez les visualiser sans même parcourir le didacticiel jusqu'à la fin.

Conclusion

De cette manière simple et pratique, nous pouvons désormais intégrer Java et JS. Tout cela est loin d’être un cas isolé ; de nombreuses pistes d’application peuvent être envisagées.

Enfin, une goutte de pommade dans la pommade. Quel est le piège ?

• GraalJS n'est pas encore Open Source, même si, selon les rumeurs, ils souhaitent l'ouvrir ; Tout est déjà en ordre.
• Java npm est toujours lent. Pourquoi – nous devons étudier. C'est npm qui ralentit, pas le moteur JS lui-même ;
• Derrière tout cela se cache une magie féroce, et lorsque vous essayez d'y entrer, vous devrez étudier beaucoup de choses supplémentaires ;
• Tout cela est collecté par rapport au JDK8. Vous devrez attendre assez longtemps pour les nouvelles fonctionnalités de Java 11 ;
• Graal est un projet expérimental. Il faut en tenir compte lorsqu'on tente de l'intégrer dans une entreprise très sanglante, sans droit à l'erreur.

Balises : Ajouter des balises

Java et JavaScript sont des langages de programmation utilisés pour développer des applications ou des fonctions sur des pages Web. Leur code présente certaines similitudes, mais il existe des différences entre eux.

Ces langages sont désormais pertinents et très souvent utilisés. Ce ne sont pas les langues les plus récentes, mais vous ne pouvez même pas les nommer.

La plus grande différence entre ces langages réside dans le type d’applications qu’ils créent. Lors de la programmation en Java, ils seront soit exécutés à partir du bureau, soit lancés dans une page Web. Dans la plupart des cas, les applications créées dans un tel langage sont autonomes et peuvent être ouvertes comme une fenêtre de programme normale. Pour qu'ils fonctionnent, Java doit être installé sur l'ordinateur. Mais JavaScript est fourni avec tous les navigateurs modernes et tant qu'il est activé, son code sera exécuté lors du chargement de la page Web.

Le langage de programmation JavaScript est couramment utilisé dans le développement Web et fournit des fonctionnalités supplémentaires aux pages ou peut créer une application au sein de la page Web elle-même. Certains jeux vidéo ont été développés à l'aide de JavaScript et peuvent être joués directement dans une fenêtre de navigateur Internet. Par exemple, sur le site de jeux pour enfants http://igryman.ru/view_360, JavaScript est utilisé pour les fonctionnalités du site et les jeux eux-mêmes sont créés en Flash.

Les programmes Java effectuent généralement des calculs et des informations de base côté serveur ou dans une applet Java, qui doit être chargée en premier. JavaScript, quant à lui, effectue des calculs et « réfléchit » toujours du côté client, l'ordinateur sur lequel la page Web est ouverte. Pour cette raison, JavaScript est souvent plus rapide, parfois presque instantanément. Les applications Java prennent un peu plus de temps à traiter.

Les programmes Java peuvent parfois nécessiter beaucoup de mémoire informatique pour fonctionner, ce qui peut ralentir l'ordinateur ou d'autres programmes. Bien que Java puisse être utilisé pour créer des éléments très puissants, sa consommation de mémoire plus élevée constitue son inconvénient. Cependant, JavaScript utilise moins de mémoire (dans certains cas très peu) pour effectuer correctement le traitement et les fonctions. Il s'agit d'un langage de programmation couramment utilisé dans de nombreuses pages Web aujourd'hui (y compris celle-ci) en raison de ses faibles besoins en mémoire et de sa capacité à fournir de nombreuses fonctionnalités différentes sur une page Web.

Qu'est-ce que Java Qu'est-ce que JavaScript Pourquoi JavaScript a-t-il été appelé ainsi ? Comment Java a été créé Quelle est la différence entre Java et JavaScript

Commençons par ce que sont Java et Javascript.

Qu’est-ce que Java ?

Java est un langage de création de programmes, une plateforme informatique. Ceux. un programme qui traite les codes d'octet et transmet les instructions d'interprétation au matériel. Sun Microsystems a été fondée en 1995. Une application Java est un bytecode spécial qui s'exécute sur n'importe quel ordinateur utilisant une machine virtuelle Java.

Par conséquent, de nombreux sites Web ne peuvent pas fonctionner sans Java. Java lui-même fonctionne rapidement, présente un bon niveau de sécurité et de fiabilité. Java est partout : dans les consoles de jeux, dans nos téléphones et même dans les centres de données informatiques. De plus, Java est absolument gratuit, vous pouvez toujours le mettre à jour vers la dernière version, ce que d'ailleurs ils disent que vous devriez toujours faire.

Qu’est-ce que Javascript ?

Voyons maintenant ce qu'est Javascript. Javascript est un langage de création de sites Web multi-paradigmes. Il comprend des styles tels qu'impératif, fonctionnel et orienté objet. Autrement dit, il est nécessaire pour créer des sites Web « en direct ». Contrairement à Java, Javascript a été inventé par Netscape, Inc. Cela signifie qu’il n’est en aucun cas lié à la plate-forme Java.

Aujourd’hui, Javascript est un langage de création de sites Web sécurisé et polyvalent. Il ne fonctionne pas avec les outils de bas niveau permettant de travailler avec la mémoire et les processus, car a été configuré sur le navigateur dès le début.

Pourquoi Javascript a-t-il été nommé ainsi ?

Plus tôt, nous avons découvert que Javascript avait été créé par des personnes complètement différentes. Alors pourquoi porte-t-il toujours un nom similaire ?

Cela est dû au fait que le langage de programmation Java était très célèbre à cette époque, ils ont donc décidé de tricher et l'ont appelé JavaScript. Ils l'appelaient à l'origine LiveScript. Ces gens avaient prévu qu'il soit le petit frère de Java. Mais maintenant, tout est complètement différent, Javascript s'est fortement développé et ne dépend plus de Java ni n'a rien à voir avec lui.

Il a été indiqué ci-dessus que Javascript ne devrait être utilisé que dans les navigateurs, mais maintenant JavaScript est également utilisé sur le serveur, il peut aujourd'hui être utilisé partout.

Comment Java a-t-il été créé ?

Dès le début, ils avaient prévu de l'appeler Oak. James Gosling a créé Java en tant que programme permettant de programmer des appareils électroniques du quotidien. Plus tard, renommant Oak en Java, ils ont décidé de l'utiliser pour écrire des applications client et des logiciels serveur. Ils ont décidé de lui donner le nom du café "Java". C'est pourquoi l'emblème de la langue représente une tasse de café chaud.

Regardons les principales différences.
Java est exprimé comme un langage orienté objet pour écrire divers programmes. Mais Javascript est un langage fonctionnel permettant de produire des scripts.

Contrairement à Javascript, qui s'exécute principalement dans le navigateur, Java est nécessaire pour programmer diverses applications exécutées dans une machine virtuelle.

Javascript est généralement rendu tel qu'écrit, mais le code Java doit être compilé.

Pour eux, vous devez connecter des modules différents les uns des autres.

Je suppose que cet article était très informatif et intéressant pour les lecteurs.