* Cross language serialization for Java and Python
* Use strict types when Python serializing
* Handle recursive objects in Python; Pin msgpack >= 0.6.0, < 1.0.0
* Disable gc for optimizing msgpack loads
* Fix merge bug
* Java call Python use returnType; Fix ClassLoaderTest
* Fix RayMethodsTest
* Fix checkstyle
* Fix lint
* prepare_args raises exception if try to transfer a non-deserializable object to another language
* Fix CrossLanguageInvocationTest.java, Python msgpack treat float as double
* Minor fixes
* Fix compile error on linux
* Fix lint in java/BUILD.bazel
* Fix test_failure
* Fix lint
* Class<?> to Class<T>; Refine metadata bytes.
* Rename FST to Fst; sort java dependencies
* Change Class<?>[] to Optional<Class<?>>; sort requirements in setup.py
* Improve CrossLanguageInvocationTest
* Refactor MessagePackSerializer.java
* Refactor MessagePackSerializer.java; Refine CrossLanguageInvocationTest.java
* Remove unnecessary dependencies for Java; Add getReturnType() for RayFunction in Java
* Fix bug
* Remove custom cross language type support
* Replace Serializer.Meta with MutableBoolean
* Remove @SuppressWarnings support from checkstyle.xml; Add null test in CrossLanguageInvocationTest.java
* Refine MessagePackSerializer.pack
* Ray.get support RayObject as input
* Improve comments and error info
* Remove classLoader argument from serializer
* Separate msgpack from pickle5 in Python
* Pair<byte[], MutableBoolean> to Pair<byte[], Boolean>
* Remove public static <T> T get(RayObject<T> object), use RayObject.get() instead
* Refine test
* small fixes
Co-authored-by: 刘宝 <po.lb@antfin.com>
Co-authored-by: Hao Chen <chenh1024@gmail.com>
## What do these changes do?
Previously, Java worker configuration is complicated, because it requires setting environment variables as well as command-line arguments.
This PR aims to simplify Java worker's configuration.
1) Configuration management is now migrated to [lightbend config](https://github.com/lightbend/config), thus doesn't require setting environment variables.
2) Many unused config items are removed.
3) Provide a simple `example.conf` file, so users can get started quickly.
4) All possible options and their default values are declared and documented in `ray.default.conf` file.
This PR also simplifies and refines the following code:
1) The process of `Ray.init()`.
2) `RunManager`.
3) `WorkerContext`.
### How to use this configuration?
1. Copy `example.conf` into your classpath and rename it to `ray.conf`.
2. Modify/add your configuration items. The all items are declared in `ray.default.conf`.
3. You can also set the items in java system prosperities.
Note: configuration is read in this priority:
System properties > `ray.conf` > `ray.default.conf`
## Related issue number
N/A
Update the version in maven from 0.1 to 0.1-SNAPSHOT, because SNAPSHOT is the conventional version name in dev process. Non-snapshot versions are only used for release.
This PR adds a `function_desc` field into task spec. a function descriptor is a list of strings that can uniquely describe a function.
- For a Python function, it should be: [module_name, class_name, function_name]
- For a Java function, it should be: [class_name, method_name, type_descriptor]
There're a couple of purposes to add this field:
In this PR:
- Java worker needs to know function's class name to load it. Previously, since task spec didn't have such a field to hold this info, we did a hack by appending the class name to the argument list. With this change, we fixed that hack and significantly simplified function management in Java.
Will be done in subsequent PRs:
- Support cross-language invocation (#2576): currently Python worker manages functions by saving them in GCS and pass function id in task spec. However, if we want to call a Python function from Java, we cannot save it in GCS and get the function id. But instead, we can pass the function descriptor (module name, class name, function name) in task spec and use it to load the function.
- Support deployment: one major problem of Python worker's current function management mechanism is #2327. In prod env, we should have a mechanism to deploy code and dependencies to the cluster. And when code is already deployed, we don't need to save functions to GCS any more and can use `function_desc` to manage functions.
Kai Yang