While I appreciate Grakkit for what it is, there is no need for anyone using ScriptCraft to migrate to a new plugin. ScriptCraft documentation can be enhanced with links and other assistance to install GraalVM, and a new version of ScriptCraft for JRE 15 can include:
ScriptEngine graalEngine = new ScriptEngineManager().getEngineByName("graal.js");

While this is of course a big deal, this is not at all "life threatening" to ScriptCraftJS.

I understand that @walterhiggins doesn't have the time for this. I'm just trying to help direct the course of this ticket - and avoid the idea that migration away is required.

Let's be clear about what Grakkit is and is not, and I hope @hb432 will get onboard with this.

Grakkit is a different way of approaching JS for Minecraft. It is/will be a plugin-development option for anyone who already knows JavaScript.
ScriptCraft has always been a vehicle for helping newcomers to programming to learn JavaScript through their game of choice. It serves as a vehicle for education as well as a tool for plugin development. ScriptCraft has unique value that will never be a part of Grakkit, because Grakkit was created by programmers for programmers, and the people working on Grakkit are not inclined to be a part of the ecosystem of new programmers, educational code camps, and other aspects attributed to ScriptCraft.

So these are two different tools for different purposes. They do not compete. There is no "overtake" scenario. Let's ensure that people are aware of the value of each tool so that they can make informed choices. That starts with a clear recognition of the distinctions of these tools here.

This also implies that effort doesn't need to be added to allow Grakkit to support ScriptCraft. Anyone who is capable of creating a ScriptCraft plugin will have the understanding later to choose one or the other. Given the state of ScriptCraftJS right now, it's extremely unlikely that there are more than just a few plugins where the author might consider preserving the functionality and migration to a new plugin core. SC just isn't that big. If you picture a union (a Venn diagram) of SC plugins with Grakkit (as it develops), the intersect point will be so tiny that compatibility features aren't warranted. Since ScriptCraft is FOSS, there's no harm in copying and incorporating similar features - why recreate code that's already there? But this shouldn't be done with the intent to provide a convenience for migrations ... the SCJS world doesn't have a wealth of established plugins to justify that.

In fact, I would suggest that compatibility features should be left to other developers later, to be created as they require, for PR to Grakkit. This frees @hb432 and team to focus on strengthening the core of Grakkit to ensure it avoids some of the shortcomings that have caused SC to flounder. In other words, help the Grakkit community to grow by leaving secondary addons for others, while you focus on things that they probably cannot or will not do.

And ... appreciating ScriptCraft for what it is, if Grakkit does include internal features that would help ScriptCraft, please consider PRs back here.

Nashorn will be removed from Java 15 - need to migrate to GraalVM #444

Description

Activity

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions