Write Now, Run Anytime talk

Just noticed a video of my keynote (Write Now, Run Anytime) from JDD in Krakow last October has finally gone online, should anyone be interested in 40min of me talking about and demoing live / interactive coding in Java with Praxis LIVE. Nothing like doing the first run of a new talk in front of ~700 Java devs at 9am.

May contain blinky visuals, cheesy techno and some poor tortured breakbeats! ;D


In other news, Praxis CORE (the hot code-reloading runtime part of all this) will be released under LGPL very soon!

Nice project, I’m not a music creator but this kind of IDE could be useful to build quick demos/intro to some projects. Because this is Java gaming, do you plan to add some kind of support to gaming build in the future ?

Thanks! :slight_smile: What sort of support exactly do you mean? I’m intrigued how much you watched, because there’s a lot of stuff that is not music specific. The core can work with any Java library, but there’s specific modules that wrap Processing, OpenGL / GLSL support, video, mouse / keyboard control, sensor controls, etc.

I’m not personally interested in creating traditional games, but I have created real-world gaming-like experiences with it - eg.
this was made with a very early version - http://www.java-gaming.org/topics/meeting-point-2014/34630/view.html Still, if there’s a feature you’d like to see, ask (or contribute!) - it’s on GitHub.

Praxis CORE is not specific to any particular use (video, audio, gaming, etc.), although there are optional modules for those purposes - it’s an attempt to bring some of the benefits of Erlang and Smalltalk to Java.

I said it often, but once again: Your work is really really awesome.

What exactly do you mean by that? Could you give some examples?

Thank you! ;D


OK, I’ll try a short version! :wink: Erlang is actor-model based, designed for soft real-time and distributed systems, and supports the ability to hot swap running code without stopping. Praxis CORE is also actor based (or an extension of), supports running across multiple processes / machines and allows for atomically hot swapping code. Now Java supports some limited hot swapping of code in development, and things like JRebel extend on that, but in my opinion updating the behaviour of an existing class usually ends up in problems. Instead, by using actors and throwaway classloaders, state injection, and splitting apart the idea of identity, state and behaviour it becomes possible to build an API that allows for runtime code replacement in a really stable way.

Likewise, Smalltalk is message-based, and influenced (although isn’t) the actor model. It also has really strong support for runtime introspection and coding, and image-based persistence. Praxis LIVE brings some of that in. It’s worth taking a peek at Pharo for an example of what a contemporary Smalltalk IDE can do. You also can start to get a sense of what OOP was meant to be about (hint, Java ain’t it!)

Nothing radical in any of the pieces I’m putting together there, just trying to arrange them in different ways! :slight_smile:

Hopefully that makes some sense - check out the “technical stuff” bit of the talk from 24:55 - it has some slides that might illustrate that better.

Incidentally, the title of that talk is actually comes via a quote about Erlang - “if Java is Write Once, Run Anywhere, Erlang is Write Once, Run Forever”.

Yes, certainly. I did a similar thing in my own game engine for reloading of textures, shader programs etc. during development, although my implementation is rudimentary I would say. I took a look at your projects some times already, but wasn’t able to figure out: Is everything you load/reload an asset in the project workspace, a file you can load from the hard drive? Or did you implement a way that your project can for example load precompiled versions of assets as well?
How did you do the separation between identity and state, how does this look like implementation-wise? I’m currently working with IDs and/or constructs similar to Ref here.

Yea, I learned some of this stuff at the university, one professor of mine was some rare kind of smalltalk god :slight_smile: Did you take a look at DCEVM?

In terms of Java code (and shaders actually), everything is a String property. Every time a component receives new code, it looks up another actor that provides compilation, etc. and sends it a message. When the compiled code comes back later the behaviour gets swapped. So javac is a key part of the runtime, although a bytecode cache is in development. This is also fun because you can write components (actors) that generate source code for other components.

There’s a slide for that! :wink: Quite simply really - there are 3 classes for each actor - identity (component) wraps state (context) wraps behaviour (delegate). The delegate is the user’s code. It uses annotations for defining state layout (and inputs/outputs, additional metadata). A context is created for each delegate - it analyses the delegate, maintains the defined state, and knows how to process the previous context to inject state forward, dispose resources, etc. The component is the bit that exists throughout.

That seems to be where to find them! I never learned any of this at university - mainly because I didn’t to computer science -
sometimes think I should have, but I seem to have ended up mostly doing it anyway! ;D

Yes, a bit. Still has the problem (in my opinion) of trying to change existing classes IIRC? One reason I like the simpler blank slate approach is that if you accidentally remove something essential it tends to fail immediately rather than 3 days later when you try to run the project again.