JS version: create appropriate project directories; modify build script, etc

[AndreVanDelft]

In particular, java dependencies in the VM need to be isolated:

• synchronized
• Thread

Like the SwingCodeExecutorAdapter is now in the subscript.swing package, these java dependencies may go to package subscript.jvm. For the JS version, we may use a package subscript.js, which should have stubs for synchronized and for the executor that ThreadedCodeFragment uses.

How will the appropriate class from either of these packages be loaded at run time? The run time should know whether it runs on JVM, JS or maybe something else. How exactly is to yet be found out.

[AndreVanDelft]

Suppose there is a variable that describes the runtime system; could the JVM then have some code like:

val threadingSupportClass = runtimeSystem match {
  case "JVM" => subscript.vm.jvm.ThreadingSupport.class
  case "JS" => subscript.vm.js.ThreadingSupport.class
  case _ => // not supported
}
val threadingSupport = threadingSupportClass.newInstance.asInstanceOf[ThreadingSupportTrait]

with both ThreadingSupport classes implementing ThreadingSupportTrait.

Or is the .class a jvm thing, so that this is not available under JS?
Or will the compiler want to load subscript.vm.jvm.ThreadingSupport.class when it sees the code above?

[anatoliykmetyuk]

That's approximately how ScalaJS works. The compiler does two separate compilations for JS and JVM. It is possible to specify separate sources for each of these compilations by putting them into separate directories. You can get an idea by looking at this demo. Notice how it has projects for JS, JVM and the one shared between them.

Currently that's not the problem though. I was able to compile the SubScript code base under JS (with no separate JVM files, no idea why it compiled with synchronized), however I am unable to test it. This is due to the shared tests being not picked up by the compiler, most probably due to the SubScript SBT plugin. The plugin apparently needs to be adapted to ScalaJS.

[AndreVanDelft]

Thanks; so we can have one or a few more source files in two target-dependent versions.

In scala synchronized is not a keyword, as in java.
It is in fact a member of AnyRef, which is scala equivalent for java's Object.
https://stackoverflow.com/questions/7826822/why-this-synchronized-instead-of-just-synchronized-in-scala

That may well explain why synchronized compiles well.
Only the Thread dependency needs then to be addressed, I think.