Running Java methods from JavaScript page

[akadeev]

I am trying to use new documentation page: Running Java methods from JavaScript. But both in master and new-object branches I am facing this in attempt to load http://localhost:8080/

Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check http://xhr.spec.whatwg.org/.

localhost/:1 Uncaught SyntaxError: Unexpected end of input
n.onreadystatechange @ XmlHttpRequest.js:163
c @ XmlHttpRequest.js:172
e._requestFileSync @ async.js:17
e @ XmlHttpRequest.js:316
(anonymous function) @ (index):17

XmlHttpRequest.js:318 Uncaught Error: Unable to find listing at URL: listings.json
e @ XmlHttpRequest.js:318
(anonymous function) @ (index):17

Looks like something wrong with generated listings.json. Are you sure this guide working on latest master?

[jimfb]

I'm pretty sure the guide works.

Are you using OS X by chance? For whatever reason it appears to be a platform issue that results in the listings.json file being corrupt/invalid. Anyway, I'd recommend trying on Linux and see if that works better for you. Not sure what the root cause of the bad listings file in osx is.

[jvilk]

If you're not updated to the latest new-objects commit (which fixed this bug, but also changed the natives API), you can retrofit whichever commit you're on by changing the last line of tools/gen_dir_listings.coffee from:

process.on('exit', (-> console.log JSON.stringify(fs_listing)))

...to:

console.log JSON.stringify(fs_listing))

Apparently there's a race condition between the program exiting and the log statement completing that only triggers in some scenarios. The process.exit I had in there is a remnant from when gen_dir_listings operated asynchronously a long, long time ago. Hurray for code rot! :(

Closing as fixed. Reopen if it's still broken.

[akadeev]

For latest new-object on attempt to run: npm install

execsync v1.0.2] Attempting to compile native extensions.
[execSync v1.0.2]
    Native code compile failed!!
npm WARN prefer global marked@0.3.5 should be installed with -g
npm WARN prefer global npm@3.3.10 should be installed with -g

node v4.1.2 npm 2.14.4

[jvilk]

@akadeev new-objects does not depend on execSync, marked, or npm anymore. See the package.json file here. Are you sure you aren't accidentally on the master branch?

[akadeev]

Yeah, looks like there was some issue with branches, I have cloned repo again to make sure and npm install worked. Then bower install was silent (isn't it weird?). Then grunt release finished without errors, but vendor directory contains only java_home and websockify. But that is not good afaik - it has to contain browserfs for src="doppio/vendor/browserfs/dist/browserfs.min.js" Probably something broken inside of my npm, not sure.

I have tried to do the same on master branch, everything goes well, but that leads to jvmObject is undefined in index.html }, function(err, jvmObject) {

[jvilk]

I changed the build system on new-objects so bower is not required. :)

BrowserFS is now in node_modules/browserfs/dist/browserfs.min.js. I plan to merge new-objects into master, perform a new release of doppio, and update the doppio-demo repository to depend on the release this week. The current blocker is some weirdness in the unit tests and the Jython/JRuby issue, which I'm currently sorting out.

Do I still reference the old location of BrowserFS somewhere?

[jvilk]

As an aside, note that I switched from require.js to Browserify -- thus, I am able to depend on NPM modules like browserfs in browser code, and I rely on Browserify to replace references to Node modules with their BrowserFS equivalents (Buffer, path, fs, etc).

[akadeev]

Old location of browserfs contains in guide: Running Java methods from JavaScript. :)

Can you check out that guide, as looks like it is not valid for latest new-objects?

[jvilk]

You are correct, @akadeev. The guide is slightly out-of-date. I'm prioritizing fixing the unit test issues before updating documentation. I won't be able to get to it until tomorrow.

The changes should be fairly superficial, though. I've changed the API, but doppioh will take care of generating correct code, and the native methods in DoppioJVM use the new API. The location of BrowserFS is different, but the BrowserFS portion of the guide should be correct.

I can ping you here when I've updated the guide. I'm also happy to answer any further questions you have until then.