FAQ

Q: How is mokapot better than Web APIs?

A: By working within the programming language (JAVA) you can take advantage of its safety features, such as syntax and type checking. You can also send to another instance things that Web APIs cannot handle, such as objects and closures for call-back functionality. Finally, you don't need to learn complex frameworks and techniques. With mokapot multi-instance cloud computing is as easy as single-node programming!


Q: When are Web APIs better than mokapot?

A: The security model of mokapot is different of that of Web APIs. Mokapot creates a seamless integration (memory and control) between the nodes, whereas Web APIs insert a strong barrier. For this reason, Web APIs are better suited for serving functionality to untrusted external clients. Mokapot is best suited for intra-cloud communication between components that trust each other. Ideally you should use Web APIs externally, mokapot internally.


Q: How is mokapot different from RMI ("Remote Method Invocation")?

A: RMI is close to mokapot in form, they both enable communication between nodes while staying within the language. But RMI is riddled with limitations and inconsistencies. An RMI call does not have the same behaviour as a Java call. On the other hand, mokapot has exactly the same behaviour. To move from single node to many nodes via RMI still takes a lot of re-coding. With mokapot it is automatic.


Q: Does mokapot help with orchestration or management of instances?

A: No, this is an orthogonal concern. You can manage instances with whatever system you want (e.g. Kubernetes). The mokapot can be totally transparent to them. If the management system has a Java API it can be, of course, interfaced with mokapot.


Q: How can programming with mokapot be robust?

A: A mokapot-enabled Java application can fail in more ways than a single-node application, basically because the nodes themselves may fail for whatever reason. In these situations mokapot will issue Java Errors which can be handled and remedial action can be taken. A serious problem in case of failure is program state, which can be corrupted. There is no general automatic solution to this problem. It is up to the programmer to program defensively, using standard techniques, e.g. using "transactional state".


Q: Does programming with mokapot obscure performance issues?

A: As any high-level framework, mokapot may hide performance aspects at code level (e.g. local vs. remote calls, the amount of network traffic, etc.). This is a good thing, as it makes programming simpler! We compensate this via tooling, by equipping mokapot with powerful profiling and logging hooks.


Q: What are the main limitations of mokapot?

A: Mokapot is a framework, which means that it works at low-level with the JVM Bytecode, in order to save the programmer the hassle of re-coding and re-factoring. Using multiple frameworks in the same applications is generally tricky as they can interact in surprising ways, leading to problems. We do not recommend mixing mokapot with other framework, but if you have to you need to be careful! An upcoming tool (millr) will help programmers detect and fix such problems automatically.


Q: What are the main applications of mokapot?

A: Whenever you want to integrate Java apps along multiple devices it will make your job easier (eg. cloud computing, internet-of-things), especially if you have legacy Java code which you want to "just work" in the cloud.


Q: Does mokapot work on mobile?

A: Yes, on Android, which is Java-based. Mobile mokapot has mobile-specific features, such as seamlessly switching between network providers (mobile to WiFi and back) without crashing.

Q: Is mokapot a push-button solution for modernisation?

A: Not quite. Together with mokapot, which handles some difficult language corner cases however it comes close to it!