Discussione:
GraalVM
(troppo vecchio per rispondere)
M C
2023-04-27 19:42:52 UTC
Permalink
Qualcuno con esperienza diretta in ambiente di produzione con questo
prodotto?

Chiedo perché assumendo che l'incremento in performance e il ridotto
footprint siano sensibili, uniti al fatto di poter creare un eseguibile
binario senza bisogno del runtime Java sembrano giá da sé promesse molto
allettanti.

Da quello che leggo, il prodotto é ancora relativamente giovane (vabbé
data di nascita nel 2019 in ambito IT sembra il passato remoto ma
comunque..) e la differenza in performance non é cosí accentuata da
compensare il rischio dell'uso di un prodotto nuovo.
rootkit
2023-04-28 07:11:25 UTC
Permalink
Post by M C
Qualcuno con esperienza diretta in ambiente di produzione con questo
prodotto?
Chiedo perché assumendo che l'incremento in performance e il ridotto
footprint siano sensibili, uniti al fatto di poter creare un eseguibile
binario senza bisogno del runtime Java sembrano giá da sé promesse molto
allettanti.
Da quello che leggo, il prodotto é ancora relativamente giovane (vabbé
data di nascita nel 2019 in ambito IT sembra il passato remoto ma
comunque..) e la differenza in performance non é cosí accentuata da
compensare il rischio dell'uso di un prodotto nuovo.
ci avevo lavorato già un po' di tempo fa in abbinamento con quarkus.
diciamo che ad essere immaturo era quest'ultimo più che la graalvm, ora
credo le cose siano molto migliorate. dei miei ex colleghi lavorano con
kogito e me ne parlano molto bene, diciamo che in ambito cloud native o
più ancora serverless il ridotto footprint è determinante. certo non ti
aspettare che a compilare nativo un monolite legacy (ammesso e non
concesso di riuscirci) porti dei vantaggi prestazionali...
M C
2023-04-28 19:47:25 UTC
Permalink
Post by rootkit
ci avevo lavorato già un po' di tempo fa in abbinamento con quarkus.
diciamo che ad essere immaturo era quest'ultimo più che la graalvm, ora
credo le cose siano molto migliorate. dei miei ex colleghi lavorano con
kogito e me ne parlano molto bene, diciamo che in ambito cloud native o
più ancora serverless il ridotto footprint è determinante. certo non ti
aspettare che a compilare nativo un monolite legacy (ammesso e non
concesso di riuscirci) porti dei vantaggi prestazionali...
ok, grazie delle info, le premesse sono molto incoraggianti per cui vale
la pena investigare

piuttosto interessante il fatto di aver citato monoliti legacy senza che
io abbia detto niente, la lettura del pensiero funziona bene anche a
distanze elevate :-)

monoliti non ne abbiamo tanti ma di roba legacy fin sopra i capelli
rootkit
2023-04-29 09:51:40 UTC
Permalink
Post by M C
Post by rootkit
ci avevo lavorato già un po' di tempo fa in abbinamento con quarkus.
diciamo che ad essere immaturo era quest'ultimo più che la graalvm, ora
credo le cose siano molto migliorate. dei miei ex colleghi lavorano con
kogito e me ne parlano molto bene, diciamo che in ambito cloud native o
più ancora serverless il ridotto footprint è determinante. certo non ti
aspettare che a compilare nativo un monolite legacy (ammesso e non
concesso di riuscirci) porti dei vantaggi prestazionali...
ok, grazie delle info, le premesse sono molto incoraggianti per cui vale
la pena investigare
piuttosto interessante il fatto di aver citato monoliti legacy senza che
io abbia detto niente, la lettura del pensiero funziona bene anche a
distanze elevate :-)
monoliti non ne abbiamo tanti ma di roba legacy fin sopra i capelli
probabilmente non sarebbe neanche fattibile. ora è un po' di tempo che
sono fuori dal giro delle architetture software e non so se ci sono state
evoluzioni in tal senso, ma quando seguivo l'argomento c'era un problema
chiaro: il compilatore conosce il classpath di compilazione ma non
necessariamente quello a runtime, per cui come fa a soddisfare il
classloading che viene risolto esclusivamente a runtime? pensa ai driver
jdbc ad esempio, ma non solo, qualsiasi tecnica che prevede un
instanziamento dinamico di classi arbitrarie, plugin, etc...
diciamo che a parte il discorso legacy/non legacy la compilazione nativa
non è per tutti, bisogna fare delle scelte architetturali che in molti
casi non ha senso fare. in molti casi meglio imho la buona vecchia jvm :-)
Loading...