“The web” is, in fact, an example of a mobile code platform different from Jini. It doesn’t work better and in many cases I find it worse than Jini. It has the same problems set we have. The JSON or XML or whatever “data” you send must be in sync with the Javascript running in the browser. Browser caches create problems with old code and new data. You have to put versioning in your service calls to cleanly evolve your services so that they force the client to reload and get the new code so that it is in sync with the new data.
With Jini, you have to get a new service to get “different” data, and thus you will get a new proxy that can use the new data correctly. Different browsers are like different Java platforms, each has some interesting and often frustrating nuances of what the “platform” provides with correct implementation of Javascript accessible browser services. The idea of Ajax for RPC out of the application is exactly in line with using a multi-threaded Java application to use Jini services, but it doesn’t work if that service can’t force the browser to get new code in the browser that knows how to use the new data coming from the service after it was restarted. There is a wide range of “packages” of massive Javascript which try to “fix” problems with different ways that inexperienced developers have tried to create web applications. Large web platforms like Facebook have their own platform of massive Javascript that their application is based on. Everything is different in each of these platforms. It’s really all, completely broken from a “developer” perspective because where ever you go, you will likely experience a completely different platform all running as Javascript. I agree that we, as users tend to have a fairly good experience with all the mess, but realistically, there is still so much churn in “how” to do web apps correctly, that I am not convinced, at all, that there is success as a concept in the Javascript platform. It’s entirely too flexible, too primitive and precisely inefficient at directing development to create reusable, portable code between these platforms. Every “page”, “panel” or “form” has huge amounts of wiring into the “platform” that was used. You can not simply take a page from Facebook and reuse it on your own. Single page applications like that are just mammoth collections of tightly coupled code. The only reusable code items are things that are simple blocks of code which use local data items in my experience… Okay, rant completed. But still, the difference between the web and Jini is the concept of the Jini Proxy where the correct code for the service endpoint is always running in the client. That’s a dramatic simplifying detail compared to what you have to worry about on the web. On the web, the problem is knowing what the client is running compared to what data the service is providing. Endpoints using non-fixed ports makes the Proxy stop working when the service is restarted so that the client can be forced to rediscover the service and reconnect with a working service and get the proxy for that working service so that the client doesn’t have the wrong data for a new version of the service. The service can have a new readObject() for that class which can migrate the old data format to the new data format needed by the service. What other details of Jini vs the Web are problem areas to you? What makes the “web” better than Jini as a mobile code platform? The “browser” is a platform. The notions of serviceUI were developed to create a “browser” like platform as a starting point for services to export a complete client experience as a web page is today. Are you using ServiceUI to take advantage of that, or do your clients have to create their own page or task to talk to your services? Gregg > On Feb 4, 2017, at 3:14 AM, Niclas Hedhman <nic...@hedhman.org> wrote: > > The latter... > > It works rather well for JavaScript in web browsers. I think that is the > most interesting "mobile code" platform to review as a starting point. > > On Sat, Feb 4, 2017 at 2:54 PM, "Michał Kłeczek (XPro Sp. z o. o.)" < > michal.klec...@xpro.biz> wrote: > >> Are you opposing the whole idea of sending data and code (or instructions >> how to download it) bundled together? (the spec) >> Or just the way how it is done in Java today. (the impl) >> >> If it is the first - we are in an absolute disagreement. >> If the second - I agree wholeheartedly. >> >> Thanks, >> Michal >> >> Niclas Hedhman wrote: >> >>> FYI in case you didn't know; Jackson ObjectMapper takes a POJO structure >>> and creates a (for instance) JSON document, or the other way around. It is >>> not meant for "any object to binary and back". >>> My point was, Java Serialization (and by extension JERI) has a scope that >>> is possibly wrongly defined in the first place. More constraints back then >>> might have been a good thing... >>> >>> >>> >> > > > -- > Niclas Hedhman, Software Developer > http://polygene.apache.org <http://zest.apache.org> - New Energy for Java
