{"id":16374984,"url":"https://github.com/moderocky/solar","last_synced_at":"2025-07-20T08:33:37.908Z","repository":{"id":103957392,"uuid":"449226502","full_name":"Moderocky/Solar","owner":"Moderocky","description":"A replacement candidate for Java's RMI. Solar allows interacting directly with Java objects in other JVMs and on remote machines.","archived":false,"fork":false,"pushed_at":"2022-01-22T11:34:54.000Z","size":61,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"master","last_synced_at":"2025-06-02T05:05:03.570Z","etag":null,"topics":["distributed-computing","distributed-systems","java"],"latest_commit_sha":null,"homepage":"","language":"Java","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/Moderocky.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2022-01-18T09:48:47.000Z","updated_at":"2022-01-19T11:23:27.000Z","dependencies_parsed_at":null,"dependency_job_id":"c73291d4-4ae1-4d02-8eea-17bb6fbf393a","html_url":"https://github.com/Moderocky/Solar","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/Moderocky/Solar","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Moderocky%2FSolar","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Moderocky%2FSolar/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Moderocky%2FSolar/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Moderocky%2FSolar/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/Moderocky","download_url":"https://codeload.github.com/Moderocky/Solar/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Moderocky%2FSolar/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":266092803,"owners_count":23875544,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["distributed-computing","distributed-systems","java"],"created_at":"2024-10-11T03:19:02.180Z","updated_at":"2025-07-20T08:33:37.881Z","avatar_url":"https://github.com/Moderocky.png","language":"Java","funding_links":[],"categories":[],"sub_categories":[],"readme":"Solar\n=====\n\n### Opus #16\n\nA replacement candidate for Java's Remote Method Interface.\nSolar is designed to allow [seamless distributed computing](https://github.com/Moderocky/Cobweb/blob/master/Identity-Relations-Distributed-Computing.pdf), where a program can call and interact with code on a completely separate machine without any meaningful indication that it is (in fact) distributed.\n\nSolar has several improvements on Java's RMI:\n1. Entire objects can be exported, rather than just interfaces.\n2. Transferred objects do not need to be explicitly serializable.\n3. Single socket-pipes are re-used for minimal resource toll.\n4. Remote servers do not need all the classes present.\n5. The entire system is easy to modify and extend.\n\n## Maven Information\n```xml\n\u003crepository\u003e\n    \u003cid\u003ekenzie\u003c/id\u003e\n    \u003cname\u003eKenzie's Repository\u003c/name\u003e\n    \u003curl\u003ehttps://repo.kenzie.mx/releases\u003c/url\u003e\n\u003c/repository\u003e\n``` \n\n```xml\n\u003cdependency\u003e\n    \u003cgroupId\u003emx.kenzie\u003c/groupId\u003e\n    \u003cartifactId\u003esolar\u003c/artifactId\u003e\n    \u003cversion\u003e1.0.0\u003c/version\u003e\n\u003c/dependency\u003e\n```\n\n## Examples\n\nStarting a local server.\n```java \nfinal Server local = Server.create(port); // creates an accessible server on this port\n```\n\nMaking an object available from the local server.\n```java \nfinal Code code = new Code(\"thing\"); // generates a 64-bit unique identifier code\nfinal MyCoolThing thing = new MyCoolThing(); // our object\nlocal.export(thing, code); // exports this object, it can now be retrieved with the code\n```\n\nConnecting to a remote (or local) server.\n```java \nfinal Server server = Server.connect(address, port); // connect to the remote server\n```\n\nRequesting an object from a remote server.\n```java \nfinal Handle\u003cMyCoolThing\u003e handle = server.request(code); // gets a \"handle\" that can control this object\nfinal MyCoolThing remote = handle.reference(); // gets the usable object reference\n```\n\n```java \nfinal MyCoolThing remote = server.\u003cMyCoolThing\u003erequest(code).reference(); // inline version\n```\n\nUsing the retrieved object.\n```java \nfinal MyCoolThing remote = server.\u003cMyCoolThing\u003erequest(code).reference();\nassert remote != null;\nassert remote.toString().equals(\"hello from the other side\"); // tostring\nassert remote.myNumber() == 4; // some method from the object\n```\n\n## Queries\n\nThe contents of a server can be 'queried' to find matching handles. While this would typically require downloading the entire contents of the server and searching it locally, Solar has support for searching on the remote machine using a supported query.\n\n```java \nfinal Query query = handle -\u003e handle.reference() instanceof MyThing thing \u0026\u0026 thing.isAlive();\nfinal Handle\u003c?\u003e[] handles = server.query(query);\n```\n\nQueries can be written in long form as concrete classes instead of lambdas. This may prevent class transmission errors if the remote machine is struggling to define the query due to an access privilege error.\n\n```java\nimport mx.kenzie.solar.integration.Handle;\nimport mx.kenzie.solar.integration.Query;\n\npublic class MyQuery implements Query {\n    \n    @Override\n    public boolean matches(Handle\u003c?\u003e handle) {\n        return handle.reference() instanceof Box;\n    }\n}\n```\n\nA query object can be passed to a remote machine. If the query class is available on the remote for reconstruction, it will be marshalled as normal.\nHowever, the query is likely to be an anonymous lambda function or method reference, which would not be present on the remote.\n\nTo solve this problem, Solar will transmit the class bytecode (if it is available) to be defined on the remote. It will then be available for future queries.\nThis remote class will be destroyed once the remote server closes.\n\n**N.B.** Bytecode transmission is impossible for anonymous or runtime-created classes without available binary source in their protection domain.\nTransmission may also be unavailable in some VM distributions with irregular class-loaders or no source (e.g. IntelliJ direct test/run environment.)\n\n### Safety Notice\n\nClearly, transmitting bytecode is open to malicious code-injection. Safety measures should be taken (such as using a security key for servers, keeping access IP-restricted, etc.)\nThis is good practice for any remotely-accessible server.\n\n## Reins\n\nReins are Solar's solution to the [distributed identity problem](https://github.com/Moderocky/Cobweb/blob/master/Identity-Relations-Distributed-Computing.pdf).\n\nOne server may hold the reins to an object at a time. Having an object's reins means that server is responsible for its field-values, garbage collection and distribution. In most cases, this should be the server that created the object.\n\nHowever, there may be occasions where an object ought to be 'moved' according to the server that is accessing it.\nAn example of this might be when an object is purely functional and needs to perform some action on the virtual machine it exists in (e.g. interacting with files or some local data.)\nIn this case, the object should use a 'fluid' handle. Another virtual machine may request the reins to the object, at which point access will throttle until the object is fully transferred to the new host.\n\nReins must be acquired by a local server, which will integrate that server into the object ownership network.\n\nReins acquisition is a _cascade_ action: the call will follow up the network to the object root, and reverse the direction of the ownership chain back down to the new owner.\n\n**N.B.** Acquiring the reins in a complex multi-orbit network will introduce a socket deadlock until the reins are resolved.\n\n## Stubs\n\nTo avoid the inevitable problem of references becoming invalid due to a handle moving, programs may keep an object 'stub' instead of the direct reference or caching the handle.\nThe stub is designed to be a safe means of access.\n\nThe stub is guaranteed to be constant, and is valid for as long as the handle itself is valid (i.e. the `stub()` method will return the same stub even once the volatile object is killed and garbage-collected.)\nThe stub is never the reference itself, even for constant handle varieties.\n\nAccess via the stub is necessarily slower (since calls are locked via synchronization) but this may be by a very minor factor, since it uses a forwarding mimic.\n\nThe stub does not hold a strong reference to the reference-object itself, so it can be safely held without interfering with garbage-collection or handle destruction.\n\n## Handles\n\nExporting or retrieving an object gives a 'handle'. These handles hold a volatile reference to the object.\nFor regular (local/remote) handles, this reference will be constant until destruction.\n\nLocal handles hold the original object. Remote handles hold a mimicked copy of the object that redirects method calls to the original version.\nFields will be empty on the remote copy.\n\nThe local handle always has the reins for an object.\n\nFluid handles are arbitrarily remote or local, and this is only known by checking whether the current VM has the object's reins.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmoderocky%2Fsolar","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fmoderocky%2Fsolar","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmoderocky%2Fsolar/lists"}