Fork me on GitHub
hipster coder05:11:09

Micro Services with Actor Model for Web Chat

hipster coder05:11:34

Docker = Micro Services… not too sure about going through the GraalVM native image process for any of the JVM langs

hipster coder21:11:44

Ok, I need to make time, to try out the native images… I am trying to decide to use Graal on Docker, for microservices… Plugin AI, NLP into the back of my stack.

hipster coder21:11:09

I know JVM does not mix with Docker… But Graal is making it better with native image, compile ahead of time.


I don’t see why JVM would not mix with Docker. You need to be aware of memory use, and how that works to prevent running out. And you have start up times, but containers don’t need to live only for a short time.

hipster coder21:11:44

it just has problems with Java reflection… so any libraries using reflection will fail on Graal native image…. I read that


@nathantech2005 That's not true though. You can provide a config file so Graal will know what information to include to be able to do reflection.

hipster coder21:11:57

@borkdude wow, so what I read is not true

hipster coder21:11:22

I was worried, that just 1 java library could stop the entire native image process


it all depends

hipster coder21:11:09

I see some companies using Java with Micro Services… but I don’t know how


@nathantech2005 There are a couple of Java frameworks that are built with native-image in mind and include modules for dealing with reflection, etc. is one such framework.

hipster coder21:11:00

so these are alternatives to Spring Boot?


I think so, although I have never used either three of them. Spring Boot is also working on native-image support I think

hipster coder21:11:45

I am just in the planning mode, architecture


Note that native-image offers faster startup and lower memory consumption, but throughput is not as good as JVM with JIT. So be aware of this, it all depends on your use case.

hipster coder21:11:54

well… I might be processing audio, real time, with Node

hipster coder21:11:11

and one of the reasons, I was trying to stay on the VM, was faster node… and possibly python

hipster coder21:11:28

of course, nothing beats Cython for speed… or direct compilation to machine code, for Python

hipster coder21:11:06

but then I saw the talk by Docker… about JVM not mixing well… so Graal to the rescue


what do you mean with speed.

hipster coder21:11:34

running Node on Nashorn

hipster coder21:11:55

that’s the old JVM VM for Node, Nashorn


I'm not following, sorry

hipster coder22:11:48

Faster Javascript Engine, than V8


Nashorn is pretty slow. You should be using the GraalVM JS engine nowadays

hipster coder22:11:07

well… I have to test it, benchmark it

hipster coder22:11:17

yea, there is a newer one, on Graal

hipster coder22:11:20

I am going to bechmark it


With the release of Java 11, Nashorn is deprecated, and has been removed from JDK 15 onwards.[10][11] The GraalVM was suggested as a replacement.


From the same Wikipedia article


Note that native-image and running GraalVM JS are two separate things though. This is why I said: I'm not following. I'm asking about your use case for speed. What do you want: good startup time, or good throughput? These "speeds" are often opposed to each other.

hipster coder22:11:56

hmm, well, if it’s for audio processing… automated translation, between English, French, I’d say throughput ?


GraalVM has a "normal" JVM in which you can directly run Python, JS or Ruby programs that will run in a Truffle-based implementation. This "JVM" is a drop-in replacement for other JVMs. It will have the same startup characteristics, but probably better performance in some regards. The other part is the native-image tool which allows you to compile JVM bytecode to machine code/binary.

hipster coder22:11:06

sounds incredibly cool… dying to dive into testing it out