Converting Java applet/application to use JS/Node.js?

[John English]

I am a complete newbie here, so please forgive my total ignorance of Node.js.

I have a Java applet which also has a main() so it can also be run as an application. The user interacts with the applet on a web page, the applet fetches specific classes from the server on demand, and when everything has been sorted out the applet serializes the state of the internal data model and squirts it to the server, where the same code running as an application takes the serialized state and processes it. This is very convenient because the classes that the user interacts with are fetched dynamically, so new classes can be added and existing ones upgraded very easily, and there is a single code base to maintain for both the client-side and server-side processing -- init() and main() just provide different ways of handling the same internal data model.

Lately Oracle seem to have gone mad. Java applets now have to be digitally signed, and hardly anyone these days seems to bother with installing Java plugins or using applets. Sometimes applets work, sometimes they don't -- "write once, run anywhere" as long as there are no version conflicts. All in all, I'm fed up with the whole mess and am looking for alternate technologies so that I can build something that will just work, period.

I'm considering using something like JSGL for the user interaction and creating a data model based on JS objects, fetching prototypes dynamically from the server as needed. This leaves me with the serialization (I presume I'll be able to convert the objects to JSON or some such to squirt them to the server) and the server-side processing. I need to be able to run a JS engine that can load up the objects (using the same prototype code that was sent to the client end), do the server-side processing, and write the results to a file.

So my questions are:
(a) does this sound feasible,
(b) can Node.js do the trick for me,
(c) where can I learn what I need in order to do it, and
(d) are there any pitfalls I need to be aware of?

Many thanks for any help you can give me...

[Aria Stewart]

On Sunday, July 26, 2015 at 10:00:11 AM UTC-4, John English wrote:

I am a complete newbie here, so please forgive my total ignorance of Node.js.

No worries! Newbies are welcome! 

 

I have a Java applet which also has a main() so it can also be run as an application. The user interacts with the applet on a web page, the applet fetches specific classes from the server on demand, and when everything has been sorted out the applet serializes the state of the internal data model and squirts it to the server, where the same code running as an application takes the serialized state and processes it. This is very convenient because the classes that the user interacts with are fetched dynamically, so new classes can be added and existing ones upgraded very easily, and there is a single code base to maintain for both the client-side and server-side processing -- init() and main() just provide different ways of handling the same internal data model.

That same notion of using the same implementation for the server and client side is something you'll find in Node.js, too. There's some mismatch between the browser environment and node, but there's strategies for  some of it. The biggest difference you'll find is in module systems: node uses a variation of the commonjs style, with "require()" and "module.exports =". The browser has no native module system, so the solutions people have come up with vary a lot more. I'd look at something like browserify, webpack or require.js for that. (I prefer webpack and browserify myself, since they use the commonjs style modules).

New code can be hot-loaded, though most often, that's done at app load time and you'd just refresh the app -- but those are all solvable patterns in javascript, both hot loading and via reloading.

Lately Oracle seem to have gone mad. Java applets now have to be digitally signed, and hardly anyone these days seems to bother with installing Java plugins or using applets. Sometimes applets work, sometimes they don't -- "write once, run anywhere" as long as there are no version conflicts. All in all, I'm fed up with the whole mess and am looking for alternate technologies so that I can build something that will just work, period.

Sounds smart. It's increasingly considered a problem to be using applets from a security point of view, too, and Apple in particular has punted you to Oracle for Java entirely and it's just not pretty.

I'm considering using something like JSGL for the user interaction and creating a data model based on JS objects, fetching prototypes dynamically from the server as needed. This leaves me with the serialization (I presume I'll be able to convert the objects to JSON or some such to squirt them to the server) and the server-side processing. I need to be able to run a JS engine that can load up the objects (using the same prototype code that was sent to the client end), do the server-side processing, and write the results to a file.

 

So my questions are:
(a) does this sound feasible,

Absolutely.

(b) can Node.js do the trick for me,

Yes!
 

(c) where can I learn what I need in order to do it, and

Here, IRC, nodeslackers.io, stack overflow are all good resources.

Keyword searches on npmjs.com will help you explore the ecosystem; the registry is unbelievably large, and a great many problems have been solved a dozen different ways. You may well be able to avoid reinventing the wheel most of the time.
 

(d) are there any pitfalls I need to be aware of?

Beware of the aforementioned module system mismatches, and don't get caught up in too much class focused design if your app doesn't really need it.

Handle code and data separately -- code you'll want to send through the module system and loader, data you'll want to fetch with the XMLHttpRequest and wrapping libraries in, the browser, and handle it explicitly.

Many thanks for any help you can give me...

You are most welcome, and good luck!

Aria

[John English]

On Sunday, July 26, 2015 at 6:46:05 PM UTC+3, Aria Stewart wrote:

On Sunday, July 26, 2015 at 10:00:11 AM UTC-4, John English wrote:

I am a complete newbie here, so please forgive my total ignorance of Node.js.

No worries! Newbies are welcome!

Great... so I'll probably be back again later my more questions... :-)
 

 (d) are there any pitfalls I need to be aware of?

Beware of the aforementioned module system mismatches, and don't get caught up in too much class focused design if your app doesn't really need it.

Handle code and data separately -- code you'll want to send through the module system and loader, data you'll want to fetch with the XMLHttpRequest and wrapping libraries in, the browser, and handle it explicitly.

Well, I'm basically going to try and rewrite the Java code in JS rather than redesigning it all. However, I've had a play using Node.js and so far I can save and reload with the proper "class" (prototype) -- a bit messy as I need to set a "type" field in every constructor to do this, and bodging "transient" fields with naming conventions so I can exclude them from the JSON -- so I'm hopeful it won't be too stressful. The code/data separation is basically much like Java -- class loaders load class code, serialization handles the data.

Thanks for the tips on module loaders, that's probably the next step...

And many thanks for the other tips, and a very helpful reply!

[Matthew Walsh]

Lately Oracle seem to have gone mad. Java applets now have to be digitally signed, and hardly anyone these days seems to bother with installing Java plugins or using applets.

Lately? Applets have always been fraught with pain and difficulties. You have made the right call by trashing the applet thing, it NEVER worked well. 

Nodejs interacting with a javascript client (web) app is really easy and nice to do. Go for it! 

[Aria Stewart]

On Sunday, July 26, 2015 at 7:05:16 PM UTC-4, John English wrote

Well, I'm basically going to try and rewrite the Java code in JS rather than redesigning it all. However, I've had a play using Node.js and so far I can save and reload with the proper "class" (prototype) -- a bit messy as I need to set a "type" field in every constructor to do this, and bodging "transient" fields with naming conventions so I can exclude them from the JSON -- so I'm hopeful it won't be too stressful. The code/data separation is basically much like Java -- class loaders load class code, serialization handles the data.

Sounds super reasonable. That's a pretty normal way to encode class information into JSON. 

And many thanks for the other tips, and a very helpful reply!

Glad to help! And good luck!

Aria