I have a C++ desktop application (written in wxWidgets) and I want to add support for some scripting language.
Scripting would mostly be used for run-time conversions of strings, numbers and dates by user supplied JavaScript code.
I'd like to use JavaScript because it is widely used and everyone is familiar with the syntax.
Googling around, it seems I have two options:
SpiderMonkey from Mozilla
JavaScriptCore from WebKit
Has anyone tried those? Which one would be easier to set up?
Do you know of some other implementation that is better for my needs?
BTW, I target Windows and Linux platforms.
There is also Google's V8 JavaScript engine, builds nicely on Linux, embedding API seems quite straightforward too: (Compared to SpiderMonkey's, never looked at the JavaScriptCore API)
http://code.google.com/apis/v8/get_started.html
Of course, you could also use Lua, which not only is designed specifically for this, it's vastly faster than any JS.
Also, it's has well-designed semantics, a very minimal core, simple C API, great portability, a very mature JIT, the most helpful online community I've seen, etc...
JavaScriptCore has a stable C API (and ABI), and has been available (and used as) a standard system framework on macos.
[edit: oh, and it works on linux and windows as a standalone library, although i believe only debian distributes it as such]
Related
I need my software which uses the Nashorn JavaScript engine to be compatible with Java 1.8 upwards.
If I use the one bundled with the JDK it will not work on Java >= 15. If I use the standalone Nashorn it will not be compatible with Java < 15.
Is there a way to keep compatibility? I have already thought about reflection but there might be more efficient ways.
Nashorn maintainer here. It should be possible to compile standalone Nashorn from sources for Java 11. I'm pretty sure we can't go below that, unfortunately. Are you using its API directly? In that case you unfortunately have a mismatch between built-in Nashorn's package names and the standalone version. If you can only rely on javax.script.* API then it should be possible to use both.
I want to understand your use case a bit better and help you arrive at a solution.
As you have noticed, Nashorn was deprecated in JEP 335 (JDK Enhancement Proposal) in Java 11 and it has subsequently been removed in JEP 372 that was delivered as part of Java 15. The motivation for the removal is
With the rapid pace at which ECMAScript language constructs, along with APIs, are adapted and modified, we have found Nashorn challenging to maintain.
Consequently, it will not be an option in the future. Instead I suggest that you take a look at options like GraalVM if you are looking for alternatives. As stated in the introduction:
It is designed for applications written in Java, JavaScript, LLVM-based languages such as C and C++, and other dynamic languages. It removes the isolation between programming languages and enables interoperability in a shared runtime.
If you cannot simply not distribute a standalone Nashorn JAR for JDKs <15, you should be able to build a multi-release version of it instead.
The root level should provide nothing, and then have all the actual classes in META-INF/versions/15/
Documentation: JAR Specification: Multi-release JAR files
I am developing a Thunderbird extension, which is mostly done in JavaScript. I want to use several functions from Mozilla's NSS (Network Security Services) library in JavaScript. There is one JavaScript wrapper built into Thunderbird, named WeaveCrypto.js, which I currently use. The problem with WeaveCrypto is its age (AES-256-CBC might have been good enough in 2010, but is not recommended today anymore, e.g. through the this. SHA1 is also not really recommended as the prf-Algorithm in PBKDF2 anymore.) and hardcoded values like iterations, algorithms and key lengths.
The JavaScript Crypto already made it to the "Archive of obsolete content", while DOMCrypt is only available in Firefox.
I am currently chatting with Justin Dolske, the developer of WeaveCrypto. His current take is that I could fork WeaveCrypto and if I only add algorithm IDs and change only small pieces of logic (like the hardcoded values to changeable ones) they would likely add my forked version to Thunderbird.
I will do that if I have to, but it sounds a bit strange to me, that the huge NSS library is not completely accessible and useable in JavaScript without extra effort, even though all logic of Firefox and Thunderbird extensions is written in this exact language (or did I miss something?).
Any ideas appreciated :)
Justin Dolske told me about the WebCryptoAPI which uses the NSS library from JavaScript. It is completely available in Firefox since version 34 (so probably also in Thunderbird since then). Most parts are, however, not supported by the famous Internet Explorer, making it more difficult to use it in browser applications. It seems still perfectly suitable for Firefox and Thunderbird extensions.
Its documentation is incomplete, but not bad. Here is some JavaScript Example Code.
Documentation on common crypto functions is also available.
The Personal Security Manager (PSM) also uses the NSS library, but does not seem to be intended for the usage in JavaScript Extensions.
BUT: The supported algorithms in NSS are not state of the art. There are JavaScript Libraries like the SJCL JavaScript Crypto Lib that contain stronger algorithms. Unfortunately, it is not really recommended to use crypto functions written in JavaScript (Javascript Cryptography Considered Harmful).
Conclusion: That is the reason why the NSS library seems like the way to go, since it is written in C and should therefore be faster and more secure than JavaScript implementations. But it should be updated to the latest security standards. In the NSS 3.3 Plan they already mention "Update the list of encryption technologies" under "Must Have" and "Elliptic Curve Cryptography (ECC)" under "Nice to Have". I cannot see much information about that in the NSS BurnDownList, but I hope there is more to come.
Do pardon the simplicity of the question: mother Google seems not to the have the answer to this one ...
So Java has Rhino, a Javascript engine written in Java. Is there a similarly shaped library out there for processing JavaScript in a Cocoa-touch environment? To be specific - this means not using the UIWebView.
On this (old) page, there’s mention of a bridge between SpiderMonkey (Mozilla’s C-based Javascript engine) and Objective-C. Maybe that’s something to explore?
Besides, isn’t JavascriptCore the iPhone’s javascript engine?
Lastly, perhaps this is what you’re looking for?
http://parmanoir.com/Taming_JavascriptCore_within_and_without_WebView
Perhaps the Google V8 JavaScript Engine could be built for iOS? It seems to build on Linux/ARM so iOS (Darwin/ARM), theoretically, couldn't be too far off =)
Webkit is a web browser engine. So, techincally any JavaScript interpreter/compiler is "outside of the Webkit".
V8 is used in Google Chrome (which uses Webkit) and Node.js, SquirrelFish Extreme is used in Safari (which uses Webkit), SpiderMonkey for Mozilla Firefox, and Chakra for IE9. Take your pick.
Javascript is widely used to create apps in the web. How about desktop, etc? Gnome Shell is made of it. I'm just curious if there's a way or something which allows devs to access Gnome/Clutter graphics libraries?
The three best options that I know of are Rhino (using Swing, or other Java graphics frameworks), Seed, and Gjs.
Seed and Gjs are both Gnome projects that bind the GTK+ and Gnome libraries to JavaScript. Seed uses the JavaScriptCore runtime from WebKit and Gjs uses Mozilla's Spidermonkey engine. Gnome Shell is using Gjs.
Another option that, as far as I know, is still pretty immature is Gom. Instead of just a JavaScript binding for GTK+, it has an HTML-like DOM interface.
There are various ways to do this. Besides Rhino, V8/node.js is one of them.
Yes using Rhino although it looks like a convolated path...
Check this recent post by Alan Knowles.
I dont know much about the Gnome/Clutter graphics access, But several SSJS (Server-side_JavaScript) available that can work on Linux environments.
I am interested in getting started with CommonJS.
With JavaScript frameworks getting faster all the time, and parsing engines and compilers making JavaScript incredibly quick, it is surprising that a project such as CommonJS has not been initiated sooner.
What steps are involved in getting a test project up and running with what has been created so far?
It really depends on what you're actually looking to do. Persevere, for example, is a JSON database that is built on top of Rhino but is capable of working with CommonJS modules and is being built up around JSGI (the web server interface) going forward.
Narwhal is a fairly robust library of JavaScript and is specifically looking to track the CommonJS standard as it evolves. Narwhal runs on top of Rhino by default, but you can also install JavaScriptCore (and possibly v8) as additional "engines". JSC is very fast.
There are various web frameworks available (including Helma NG).
Node.js has been getting a lot of attention as a fast, v8-based, event-driven network services stack for JS. Node recently changed to use CommonJS modules.
SproutCore has a branch ("tiki") that is built on CommonJS modules. I, personally, am using that now for Bespin of which the client side is entirely CommonJS modules. (Ironically, the server side is currently in Python, but we do have plans to migrate to CommonJS on the server as well.)
The thing to remember about CommonJS is that it's an API spec. It's possible for there to be many implementations. Thus far, the only part of the spec that is widely supported are the modules... the rest is still baking, but coming along nicely.
CommonJS is not yet to the level of interop of, say, CPython/Jython/IronPython, but it certainly has that potential going forward.
What steps are involved in getting a
test project up and running with what
has been created so far?
I found the Narhwal quick start to be the fastest way to get up and running.
Have you tried starting here?
What are you stuck on?
It's gelling. You're early, unless you like living on the edge.
By the way, your wikipedia link has links to the projects that use CommonJS. You had the answer before you got here.
I just started using Node.js at home. It works and seems great.
The only issue I've encountered so far is that Windows support seems somewhat distant.
I believe Rhino works with Windows since it's a Javascript interpreter written in Java, but that also means it's slower than the Javascript-C implementations like V8. I don't think Rhino itself implements the CommonJS specification, but you can run something like Narwahl on top of it - as was mentioned by Kevin and Jeff.
I just did a quick job of installing Rhino, Ant (to build Rhino) and trying to get Narwhal running with Windows, but wasn't successful.
I suggest trying Node.js on a Linux box since that was my environment and it worked flawlessly.