Add java.util.Objects.dump to facilitate quick debugging

[-]

My main concerns are about security, that many object details, while
useful to viewers, should not be accessible by any code under any
circumstances. Having any code able to print all field content of any
object sounds extremely dangerous.

In my opinion, we can use a MethodHandles.Lookup as a permission
control; the dump may print fields that the lookup context (obtainable
by caller with MethodHandles.lookup()) may access, including ones
accessible through reflection (e.g. open packages).

On Thu, Jun 9, 2022 at 1:07 AM Yi Yang <qingfeng.yy at alibaba-inc.com> wrote:
>
> Is it helpful to add a new Objects.dump method for quick debugging? Not in all cases
> we can open IDEA and happily use jdb to debug our code, sometimes we may just want
> to write a simple script, or work without IDE, for these cases, we can use Objects. dump
> to output field details of the object and feed back to the developer, so that they can quickly
> modify the code and continue to develop. Another useful scenario is working within jshell,
> Objects.dump can visualize object details, which is especially useful for REPL environments.
>
> It looks like var_dump() in PHP[1] :
> ```
> Person p = new Person(...)
> Objects.dump(p)
> Person = {
>   name = "..."
>   age = 24
>   height = 1.75f
>   attr = {
>      ...
>   }
> }
> ```
> In addition, we can also add Config parameters to allow users to control output content and
> format they expect, such as
> ```
> config.pretty = true
> config.maxDepth = 5
> config.dumpParent = true
> config.fieldFilter (Field f) -> ...
> Objects.dump(obj, config)
> ```
> This is just a very rough idea, it's too early to discuss implementation details at this point,
> I'm looking forward to hearing more feedback about the idea of adding Objects.dump itself.
>
> Thanks.
>
> [1] https://www.php.net/manual/en/function.var-dump.php