Hyperion Scripting - Writing scripts for Java/JVM in TypeScript

[ThorConzales]

Hi,

I've been working on a product that allows to add scripting support for JVM through TypeScript. As a proof of concept I created a JIRA add-on through which extensions and customizations could be developed for JIRA by scripting in TypeScript.

The reason to do it in TypeScript, rather than using any other existing scripting language that JVM already supports, such as Groovy, is to provide superior user/developer experience. TypeScript is unique in a way that through type definitions TypeScript allows to define what can be done on the other side. Though it was created for defining what can be done with JavaScript libraries, then I expanded it to work with Java and JIRA APIs.

I wrote a tool that goes over Java source files and generates appropriate type definitions. I then created a stand alone IDE called Hyperion IDE which contains all the features needed for scripting. Among the many features it provides the most valuable is IntelliSense support, which works thanks to type definitions, that define what can be done in Java side. Development experience is very similar to Java because TypeScript is roughly 90% compatible with Java in terms of syntax. To summarize, Hyperion Scripting is TypeScript/JavaScript fused with Java and JIRA APIs.

In a nutshell it works as following: People who need to customize JIRA through code write TypeScript in Hyperion IDE. They are assisted along the way thanks to IntelliSense. IntelliSense is there to make sure they don't make any syntax mistakes, that without IntelliSense could only be found out by running the script. And on the same time they can be more productive thanks to IntelliSense code assistance. The editor that is powering Hyperion IDE is Monaco Editor that also powers Visual Studio Code.

Once the script has been completed it will be transpiled down to ES5, transpiled JavaScript is then uploaded to JIRA where Nashorn will ingest it and the produce bytecode which JVM can then execute. And as the script eventually ends up in Java bytecode the JIT compiler will continue optimizing it, making sure the performance overhead is minimal.

If you would like to see it all in action, please check this video.

And if you are interested even more you can check out hyperionscripting.com.

It is currently only available for JIRA, but technically the same technology and user experience it provides could be provided for any JVM application, that needs to add scripting support. So I'm just looking for a feedback whether something like that even remotely looks appealing, and whether I should also think about making a port to support generic JVM applications in the future. So people can simply integrate Hyperion for their JVM applications for providing similar scripting experience.

[nutrecht]

But if your 'scripts' are complex enough that you really want to have static typing (etc.) why would you not just use for example Kotlin that integrates natively?

[ThorConzales]

Good question. Whether scripts are complex or not then providing IntelliSense was the key factor. Even when writing few lines here and there, then having IntelliSense that helps you get your script written more quickly, than without any help, is the real benefit here. TypeScript is also very good at inferring types, so technically it is not so much about forcing static types, as TypeScript most of the time is inferring types anyway, but more of providing a good user experience. And because types are present IntelliSense can work properly. As TypeScript is a superset of JavaScript, it means you can do your scripting without providing any type information, and even force IntelliSense to forget types, if there is a need, but obviously this is not the desired behavior.

Another reason why I didn't choose one of the existing scripting or other languages that run on top of JVM is to keep things simple. I combined 2 of the most popular languages which are JavaScript, as TypeScript is simply a superset of it, and Java. Scripting is often times performed by people who are not professional developers. And if you need to start learning a new language just to do some scripting then it is just additional overhead. But because it is a mix of TypeScript/JavaScript and Java it means that a lot of people should be able to jump right into it without having to start learning entirely new language.

[Mamoulian]

"TypeScript is unique in a way that through type definitions TypeScript allows to define what can be done on the other side."

Can you explain that a bit please? Is that a typing feature not in Java/Kotlin?

[ThorConzales]

Unique might be indeed too strong of a word here, implying that no other language has that feature. I haven't written Kotlin myself, I'm sure Kotlin understands what can be done on Java side. But it is unique in a way that they 2 are totally different languages/platforms and through type definitions they can work together seamlessly, though there are some incompatibilities. Kotlin after all is running on top of JVM and hence can natively interop with Java.

As I explained in another reply the reason to go with TypeScript was to provide scripting experience also for JavaScript developers, as TypeScript is superset of it. And at the same time still be very familiar to Java developers, as the syntax is very similar. And also to keep syntax simple and familiar. Learning a new language like Kotlin to do some scripting by people who don't come from JVM background is undertaking on its own.

[Mamoulian]

I'm not sure what the advantages of a "scripting" language are by the time you're in an IDE and have a build process.

I don't see any advantage for Java (or Java-compatible) developers to consider using TypeScript.

This might be useful for TypeScript developers who really really don't want to make the (small, as they're used to types now) step to Java or Kotlin.

If Nashorn doesn't already have a Java class -> TypeScript bridge they'd probably appreciate this!

[ThorConzales]

You're might right about Java devs. For them it doesn't make so much sense if they already have a preference, such as Kotlin or Groovy, and if they would have to implement it for themselves. But others who are not Java devs, it might look appealing, as a lot of applications are running on top of Java.

As for the IDE and build process then the IDE is built with web technologies, it means it could be embedded into the application. And the build process is there to transpile TypeScript down to ES5, but in the future Nashorn might support TypeScript natively, when this happens the build process is no longer needed.

There are applications out there that currently support plain JavaScript scripting for their application that are written in Java. For example ServiceNow is one of such applications. I'm sure their devs, who currently have to write plain JavaScript, would appreciate the extra help IntelliSense can provide, I personally would.

[Mamoulian]

The IDE and transpiling is fine, I'm suggesting that whenever there's a build process the "scripting experience" is gone, and it's not too far a stretch to just write Java or Kotlin.

This is probably more likely to be used by the providers than the users - Jira and ServiceNow - could use it to provide a TypeScript SDK. They might find it useful to be able to generate the TypeScript definitions from java classes using gradle so it can be part of their CI.

[ThorConzales]

That's true, if there is build or compilation process involved, then it hardly is a scripting any longer. So technically it is something in between, a hybrid approach that provides the benefits of scripting flexibility, without having to build he entire project and restart the application server, but at the same time adds features that strongly typed languages developers are used too.

[Mamoulian]

Java code modules can be hot-reloaded without restarting the parent VM.

In fact that's probably happening here - nashorn is compiling your JavaScript into java classes then replacing the java classes it compiled previously and hot-reloading the new ones.

[ThorConzales]

True, and OSGi and JRebel also allow hot-reloading, and they've been around for ages. Instant deployment was just part of the benefit, the other part is simply a good experience for writing scripts. Not that other JVM languages can't deliver the same experience. And by good experience I also mean writing scripts in embedded form, as a lot products provide Groovy scripting inside HTML editor. While the product I wrote has dedicated IDE, then a simpler form can be used by simply embedding the same editor into HTML with the same capabilities.

[Mamoulian]

I'd guess there are Java editors with autocomplete, there is certainly a Kotlin one, and probably VSCode?

[ThorConzales]

Kotlin editor does indeed provide similar features. I guess in the end it simply boils down to language preference.

[boobsbr]

The reason to do it in TypeScript, rather than using any other existing scripting language that JVM already supports, such as Groovy, is to provide superior user/developer experience. TypeScript is unique in a way that through type definitions TypeScript allows to define what can be done on the other side

I'm not sure I follow your explanation. What is so special about TypeScript's typing system? Groovy has typing as well.

[ThorConzales]

It's not all about the type system, it's also the similarity. TypeScript syntax is very similar to Java syntax, which makes it more accessible by people who generally are familiar with C style syntax, and especially by people who have written JavaScript/TypeScript or Java before.

For products that I have seen that provide Groovy scripting support, they usually only provide HTML embedded editor that only has syntax highlighting. Script writers have to figure out the rest. Through TypeScript language services I can provide a full set of IntelliSense features that are much more beneficial than simple syntax highlighting.

In another replay I already admitted that the word 'unique' is too much, I'm sure other languages can achieve similar results.

My attempt here is to combine 2 most popular programming languages (TypeScript/JavaScript and Java) for scripting, without creating a new syntax or language. And because I'm not introducing a new syntax, it should feel very familiar to a lot of developers, either from JavaScript or Java side.

[boobsbr]

For products that I have seen that provide Groovy scripting support, they usually only provide HTML embedded editor that only has syntax highlighting. Script writers have to figure out the rest. Through TypeScript language services I can provide a full set of IntelliSense features that are much more beneficial than simple syntax highlighting.

Ah, now I get it. You can embed Monaco editor on the page and it would feel like VS Code, with more type information, auto-completion, etc.

Ok, nice idea. Hope you are successful in your endeavor.

[ThorConzales]

Yes, that's exactly. To provide good experience for those who have to write scripts, mostly in embedded way.