Demo: A physics drawing app in the browser with TeaVM

[Jeff Martin]

Check out my latest TeaVM demo - I'll bet it's the most advanced TeaVM app yet:

SnapStudio - a physics drawing app

http://reportmill.com/snaptea/SnapStudio/

jeff

[Jesse Pavel]

Hi Jeff,

I love the idea of running graphical Java applications on the browser via TeaVM, and that is an impressive demo.

Are these demos built using SnapKit and SnapTea?

~Jesse

[Jeff Martin]

Thanks! I agree - it's particularly nice to be able to write a desktop app for the JVM, with full desktop features/performance and easy dev cycle that Java IDEs offer, then be able to publish to the web with one click for easy deployment (no packaging, code signing, app-store submission for developer, no download/install for user).

I love that people can casually take these apps for a test drive in the browser. Then if they find they have more frequent or dedicated use, they can download the full native desktop app running on the JVM (embedded).

My demos all use SnapKit. SnapKit is just a lightweight but full-featured UI kit that runs on Swing, JavaFX or HTML DOM. It has the modern graphics features of JavaFX in the conventional style of Swing. SnapTea is just the adapter needed to map SnapKit to JS - you only need it for the final JS compile (in contains the compiler jars too).

TeaVM is remarkable - my apps all compile down to around 500-800k (compressed) and perform almost as fast in the browser as the desktop. I wish someone like Oracle, Google or JetBrains would get behind this technology.

[Jesse Pavel]

I've been looking for something like this for ten years.

Does one need to use SnapCode to (relatively easily) use SnapKit and SnapTea, or are they designed to be used in other project setups as well?

Thanks,

Jesse

[Jeff Martin]

Jesse, thanks for those kind words! I think Alexey has done the real heavy lifting, but I like to hear them anyway. :-)

You can use SnapKit with any Java IDE - it is trivial to build and has no external dependencies. I know I need to figure out Maven and/or Gradle - but it might be better to just clone the project and add it your custom app project in your favorite IDE.

prompt> clone https://github.com/reportmill/SnapKit.git

SnapCode is written with SnapKit - but the only SnapKit specific feature it has is that the UI builder is built-in. However, you can also clone the UI builder project and run it stand alone. It also kicks off the TeaVM compiler process, but that is easy to duplicate in a terminal:

java -cp MyApp/bin/:SnapTea/bin/:SnapTea/lib/* org.teavm.cli.TeaVMRunner mypkg.MyApp -d MyApp/bin/tea -G -g

You can also clone the UI builder project (also small and self-contained) and use it to generate a UI file (MyApp.snp). Then you can run your test app with a class like this:

prompt> clone https://github.com/reportmill/SnapBuilder

public class MyApp extends snap.view.ViewOwner {

public static void main(String args[])  { new MyApp().setWindowVisbile(true); }

}

The ViewOwner will automatically load the UI file with the same name. In fact, I’ll put all this in a getting started doc and post the link later today.

Also, feel free to send me a moch up of your UI and I’ll send you a UI file.

And feel free to call me to chat. :-)

jeff martin

214.513.1636

[Steve Hannah]

I didn't realize that your GUI kit was available on Github, Jeff.  What a nice library!

What license does SnapKit have?

--
You received this message because you are subscribed to the Google Groups "TeaVM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to teavm+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/teavm/9DA8B39C-DEDD-42F8-B6E4-FB05F2DDBE6D%40reportmill.com.

For more options, visit https://groups.google.com/d/optout.

--

Steve Hannah

Web Lite Solutions Corp.

[Jeff Martin]

Thanks Steve! I’m not so good at promotion. :-)

I mean for SnapKit to be free for almost any use - but for commercial entities that could afford it, I’d like to figure out a way for them to help me fund it. I don’t know if they’ve invented a license like that yet.

jeff

You received this message because you are subscribed to a topic in the Google Groups "TeaVM" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/teavm/yYPOwBHb1Jc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to teavm+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/teavm/CABiRg%2BQRGr%2BLnpcDNiAPzS%3DnezXXEZKuZgE%3D6MNJ7hn9W9wCQg%40mail.gmail.com.

[Jesse Pavel]

Thanks for the information and offers for help, Jeff  (and, as you said,  thanks to Alexey for his continuing magic with TeaVM)!

I'll give it a run and let you know if I hit any snags.

I saw that CheerpJ went 1.0 recently, but it feels so heavy compared to SnapTea/TeaVM apps.

Best,

Jesse

[Jeff Martin]

It’s hard to beat TeaVM for footprint - like I said, most of my apps compile down to an ~800k download, compressed. This makes Java apps look indistinguishable from JavaScript apps, since they load so fast. The conditional compile feature is amazing.

CheerpJ tends to result in a 10-12mb download, compressed. But it also compiles the full JVM runtime - so almost any Java app works, unmodified, which is very nice. They provide the shared runtime on a CDN, which should help - but I think the CDN is not as fast as it could be. Oracle, Google or Amazon could probably serve the same files in half the time.

And I think this space is coming together fast with WebAssembly. When TeaVM and CheerpJ fully switch to WASM, the downloads should be 20% smaller and compile dynamically as they download, speeding up start up significantly. WASM already runs faster than JS, but should increase even more as it matures, particularly when it adds things like multi-threading and a better JS-DOM bridge in the next year. And Java 9 has added modules and some conditional compile, which should also help.

jeff

[Alexey Andreev]

> It’s hard to beat TeaVM for footprint - like I said, most of my apps
> compile down to an ~800k download, compressed.

..of which about half is reflection metdata. If you learned
metaprogramming API and rewritten reflection code for TeaVM in MP, you
got much smaller output. All you need is just ask me if you don't
understand how to do it.

[Jeff Martin]

Ah, very interesting! Does the reflection metadata get added if the code encounters a reference to Method or Class.getMethod()?

Most of my demos don’t really use reflection, though the compiler probably wouldn’t know it, because it’s part of a conditional path for a “key chain expression” evaluator I have in SnapKit. I could probably refactor it out for TeaVM builds.

jeff

[Alexey Andreev]

Ah, very interesting! Does the reflection metadata get added if the code encounters a reference to Method or Class.getMethod()?

TeaVM performs static analysis of every occurrence of Class.getMethod()/getField()/getDeclaredMethod()/etc and builds upper approximation of set of class literals that can reach receiver of this call. For such classes it adds reflection metadata. You may disable minification and build SnapCode and see which classes are used in reflection. You should see something like this:

    Gk.$meta.methods = [{
        name: "<init>",
        modifiers: 0,
        accessLevel: 3,
        parameterTypes: [],
        returnType: $rt_voidcls(),
        callable: null
    }, {
        name: "doGetOrHead",
        modifiers: 0,
        accessLevel: 2,
        parameterTypes: [NVc, $rt_booleancls()],
        returnType: Qeb,
        callable: null
    }, {

(of course, I have only access to minified code of your example, but you should see more precise names). 

[Alexey Andreev]

> And I think this space is coming together fast with WebAssembly. When
> TeaVM and CheerpJ fully switch to WASM, the downloads should be 20%
> smaller

I don't think so. TeaVM produces more WASM than JavaScript. The reason
is JavaScript can handle exceptions and GC and virtual calls itself, v8
builds all necessary structures dynamically. With WebAssembly TeaVM has
to generate all mentioned data (i.e. call sites, exception handlers,
stack layout, class layout, virtual tables), which makes the binary large.

[Jeff Martin]

Ah, I didn’t know - my optimism was based on WASM stories I’ve read and promises from their roadmap for the next couple years. Still, if they are promising to add support for exceptions, threading, GC and more, would you expect the binary might be smaller in a couple years?

jeff

> On Apr 19, 2018, at 8:45 AM, Alexey Andreev <konsol...@gmail.com> wrote:
>
>
>> And I think this space is coming together fast with WebAssembly. When TeaVM and CheerpJ fully switch to WASM, the downloads should be 20% smaller
> I don't think so. TeaVM produces more WASM than JavaScript. The reason is JavaScript can handle exceptions and GC and virtual calls itself, v8 builds all necessary structures dynamically. With WebAssembly TeaVM has to generate all mentioned data (i.e. call sites, exception handlers, stack layout, class layout, virtual tables), which makes the binary large.
>

> --
> You received this message because you are subscribed to a topic in the Google Groups "TeaVM" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/teavm/yYPOwBHb1Jc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to teavm+un...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/teavm/3200b657-8dfa-5564-7f73-45717ef3275c%40gmail.com.

[Alexey Andreev]

Ah, I didn’t know - my optimism was based on WASM stories I’ve read and promises from their roadmap for the next couple years. Still, if they are promising to add support for exceptions, threading, GC and more, would you expect the binary might be smaller in a couple years?

Implementing these features does not necessarily simplifies things. Will they help or not depends on how they are going to implement there features. For example, they might implement GC, but will this GC support finalization and weak references? Another example is exception handling: will it be possible to read stack trace of thrown exception, are they going t throw exceptions on some system errors (like accessing memory out of bounds). As for threading, it's unclear what their memory model is going to be and is is compatible with Java's. Without this Java implementation over WASM would generate tons of code to workaround this and emulate GC, exceptions and threads.

Also, even if they implement things right way, my experience shows that binary formats are usually less efficient in terms of size than text formats augmented with some kind of compression. So I think WebAssembly is not about making small binaries. It's about faster loading, faster warm-up, allowing to benefit from code in lower-level languages like C. 

[Jeff Martin]

Thanks for that explanation - that makes a lot of sense.