* InternalDebugControl class many public static final constants with no documentation explaining what these are.
And the names are not self-explanatory either.

-Sundar

I’d prefer completely hide this class, but not sure how to do that.

-Robert

Hmm.. Non public class or non-exported class?

-Sundar

It is how internal debugging is turned on by the jshell tool. Which is my main way of debugging the API. I don’t want it public but the jshell tool is just a client of the API. Hence my question on how to hide it. Sundar suggests non-exported class.

-Robert

Would need to be a non-exported *package*. Exports work at the
package granularity.

-Brian

Would it be OK just to hide it from the javadoc (don’t remember how
to do that, but remember that there is a way)?

-Robert

Better than nothing, but let's try to find a right place for it first.

-Brian

If this is for the *tool* and not for the JShell API, shouldn't it go in the package with the tool? It wouldn't be so out of place there.

-Brian

It is for controlling debugging of the API. I debug the API from the tool.

It has to be in the API package because that is where all the debugging hooks are. Well, it could be in a hidden separate package with registration but still would need to be public.

For context: the undocumented command “/debug <debug-flags>” calls into it to turn on debug files for a given JShell instance.

-Robert

It should be demoted to package visibility before shipping, then.

-Brian

Hmmm, disappearing it last minute would be easy but seems problematic for last minute bugs and future releases.

Seems like I should bite the bullet and do the separate little JShell debugging package.

-Robert