I'm developing a Azure Function in VS 2019 with .NET Core and want to use Chilkat.CkString
I'm using ChilkatDnCore 9.5.0.87 Nuget package.
However CkString isn't available, CkDateTime and CkObject etc. are.
Is there a problem with the Nuget package/version or I am doing something wrong?
MikeW
I'm sorry for the confusion. I'll try to update the documentation somewhere..
The CkString and CkByteData classes won't be available in .NET Core (it's intentional).
You should instead use the Chilkat.StringBuilder and Chilkat.BinData classes.
The CkString and CkByteData classes were original classes created about 20 years ago, and don't fit well into the multi-language API design. They were created with C/C++ in mind. Obviously they'll remain present in the places where they currently exist, but for any new languages supported going forward, they won't be included. If there's something CkString provides that Chilkat.StringBuilder doesn't, then let me know..
I'd like to update java classes dynamically at runtime (just like hot deployment) . Is there solution for that ? Thanks
The way to update a class that has already been loaded by the JVM is bytecode instrumentation. Java instrumentation agents can use methods redefineClasses and retransformClasses of the java.lang.instrument.Instrumentation class. Native agents can use respective functions RedefineClasses and RetransformClasses of the JVMTI API.
I want to use the Increment method from the DataCache documentation but the method is not available on my DataCache object. Clearly I don't have the version of Microsoft.ApplicationServer.Caching.Client.dll that matches the documentation but I can't seem to figure out what version contains that method and where to get the assembly???
The version I have 1.0.4632.0
I am using the AppFabric for Windows 1.1.
This method is part of Azure and not Windows Server. AppFabric exists in two versions : one for Windows Server and one for Azure. There are only a few differences (here is one of them).
If you're targeting Azure, simply add the package Microsoft.WindowsAzure.Caching. You will find a detailed introduciton here.
It you're targeting Windows Server, do it by yourself !
I'm looking for a module system for Nashorn. From what I can tell, CommonJS is the way to go concerning modules for JS. I have looked through the list (here and here) and have found little in the way of a CommonJS implementation for Java.
Narwhal is no longer active and it's documentation is no longer hosted on GitHub. Is there an existing CommonJS implementation which supports Java or should I start a new project?
Have a look at jvm-npm here https://github.com/nodyn/jvm-npm. This project is used by nodyn as the CommonJS module system. It is NPM-aware, meaning you can load modules directly from NPM, but it does not provide any of the Node.js API.
Here is a simple example usage:
$ npm install pegjs
npm http GET https://registry.npmjs.org/pegjs
npm http 200 https://registry.npmjs.org/pegjs
pegjs#0.8.0 node_modules/pegjs
$ jrunscript
nashorn> typeof require
undefined
nashorn> load('./jvm-npm.js')
nashorn> typeof require
function
nashorn> var PEG = require('pegjs');
nashorn> typeof PEG
object
It is primarily all Javascript, but the actual loading of files from the filesystem and such is done using Java.
I asked a very similar question on the Nashorn mailing list a little while back, here's Sundar's (Nashorn Engineer) reply:
From: A. Sundararajan
To: nashorn-dev#openjdk.java.net
I forgot to add. Nashorn does not contain any builtin module system.
But, if a module system is pure JS + Java, it must be possible to run
on nashorn.
Nashorn supports "load" (loads scripts from URL, File, resources) and
"loadWithNewGlobal" (loads script but into a fresh global scope)
primitives in addition to the good old 'eval'. So, it should be
possible for any module system to be implemented on top of nashorn in
pure JS or perhaps with a bit of Java code.
-Sundar
I've been looking for such an implementation for a while. I've been using a little patched version of Rhino-Require. Although Rhino claimed to be CommonJS compatible, AFAIK, it implemented only modules and not packages (package.json) can't be parsed.
RingoJS should be compatible. But Nashorn will never be see.
Laterly, Oracle announced project Avatar which relies on Avatar.js or here. It's the official project of what was unofficially called Node.jar. But as of now, you have to compile it by yourself. The project is very young.
Another very young project is Nodyn which relies on dyn.js.
So, if understood well, CommonJs should work with avatar-js and nodyn, but those two are still pretty young. I don't understand why avatar-js in not fully distributed along with nashorn though.
A kind of solution would be to add a CommonJS compatibility script like the one for Rhino which adds importClass/importPackage (mozilla_compat.js) which would add CommonJS compatibility into nashorn, kind of Rhino-Require shim thoroughly tested.
I had the same need, and I used jvm-npm for a while, but I needed something that would work even without allowing usage of Java packages inside JavaScript, so I wrote my own version here: https://github.com/coveo/nashorn-commonjs-modules
It's implemented entirely in Java and supports loading modules from elsewhere than the filesystem (Java resources, a custom database, etc.)
It's published on Maven Central if someone wants to use it.
There's also nashorn-require, you can get that off of github too. I've used it, I was able to do
engine.eval(reader("src/main/javascript/nashorn-require.js"),bindings);
engine.eval("var initRequire = load('src/main/javascript/nashorn-require.js');",bindings);
engine.eval("initRequire({mainFile : 'src/main/javascript/foo', debug : true})", bindings);
engine.eval("var babel = require('babel');",bindings);
and then transpile JSX React components to ES5 with
Buffer input = findTemplateSource(fileLocation,context);
bindings.put("input",input.toString());
result = engine.eval("babel.transform(input,{ presets: ['react', 'es2015'] }).code;",bindings);
Then when I pulled react and react-dom into my browser and loaded the resulting js components, things worked fine, so I'm sure Babel was perfectly happy, though I'm not sure about if it will find 3rd-party plugins or not...
I am cleaning up a build system for a product that uses Jetty. Currently the project has
javax.servlet.jsp:jsp-api:2.1
as a dependency. Given that I am using Jetty for my project I suspect using
org.mortbay.jetty:jsp-api-2.1:6.1.5
would be the better option. Am I right/wrong? Can they be used interchangeably? Does jsp-api-2.1 leverage a different implementation? Or is it simply a repackage if jsp-api to assert compatibility with Jetty?
I've been trying to find information about this on the web, so far nothing has come up.
Update: Seems like org.mortbay.jetty:servlet-api-2.5:6.1.5 and javax.servlet.jsp:servlet-api:2.1 have the same relationship.
Jetty has a long and colorful history with jsp, having no jsp implementation of our own we have leveraged other implementations often, judging by the version numbers your looking at those are very old versions where we were maintaining patches on top of the glassfish jsp implementation. I think it was a patch for supporting logging in jetty and then a bug fix or three.
Now a days we have been using the jsp artifacts from the java.net project which was spun out from glassfish a while back. However that doesn't seem to be tracking bug fixes very regularly either so we are kicking around trying the jasper implementation in tomcat.
Back on your question, the jsp-api artifacts are typically just repackaged artifacts since the api doesn't change frequently. We historically rebundled them to keep them paired with the patched implementation.
Now, you are obviously using a jetty-6 setup since your still using org.mortbay packaging but jetty6 and jetty7 are both servlet-api 2.5 so you might be able to get away with using the jetty7 jsp setup, we have a handy pom that declares these artifacts here:
http://central.maven.org/maven2/org/eclipse/jetty/jetty-jsp/7.6.5.v20120716/jetty-jsp-7.6.5.v20120716.pom
These are glassfish bundles as well, repackaged and made into osgi bundles in the process so they can be used with jetty in osgi environments....they ought to work normally though, we package them in our jetty7 distributions.