Open source et architecture logicielle

Pour implémenter la classe StringBuffer, j'utiliserai par délégation les méthodes de l'objet String. D'ailleurs pour cette première implémentation, cette classe ne contiendra qu'une unique propriété string de type String. On pourrait donc considérer ici cette classe StringBuffer comme un wrapper du type String.

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
"use strict";
 
class StringBuffer{
  constructor(str){
		if (str)
			this.string = new String(str);
		else
			this.str =

...

En JavaScript nous avons le type String qui possède des méthodes intéressantes mais qui malheureusement est immuable. Les objets immuables sont des objets qui ne peuvent pas être modifier après leur création. Par exemple, si je crée un objet String qui s'appelle myString et que je l'initialise avec la valeur "my first sequence of char", je ne pourrai jamais la modifier pour qu'elle vaille "my amazing first sequence of char".

D'autre langage comme Java possède également ...

Lors de précédents billets, j'ai évoqué la migration d'application JEE vers des architectures JavaScript. Les migrations que j'ai expérimentées m'ont permis de porter des applications JEE vers AngularJS pour le front office et Node.js pour le back-office. Comme dans les blogs précédents, je rappelle que ces migrations sont envisageables pour des applications légères.
Dans ce billet, j'aborderai la migration des objets métier. En JEE ces objets métier sont des POJO (Plain Old Java Objects) ...

Je remarque que les applications basées sur Node.js que je déploie sont beaucoup moins voraces en ressources processeurs et RAM que celles basées sur JEE ou sur PHP.

L'économie se situe entre 30 et 70 % sur les dépenses processeurs et RAM.
J'ai quantifié cette économie en mesurant le différentiel moyen entre une architecture JEE et une architecture Node.js pour des applications de même niveau de qualité (performances – nombre d'utilisateurs – volumes d'objets métier – taille ...

L'objet de ce post n'est pas de revenir sur le désengagement d'Oracle vis-à-vis de JavaFX. Bouye l'a fait dans son actualité mieux que je ne saurais le faire.
Je ne parlerai pas non plus Swing qui date des années 1990 et qui a révolutionné la programmation multiplateforme.

Nous savons que les technologies Java tournées vers le client lourd sont soit vieillissantes (Swing) soit incertaines quant à leurs pérennités (JavaFX). Mais nous savons également que l'écosystème Java est ...