Community
Participate
Working Groups
Build Identifier: 20100617-1415 I am using the new JavaScript debugger to debug a JS standalone app that makes strong use of Rhino's Java bridge functionality. But any JavaNativeObject that I encounter during a debugging session just appears to be a bare JS object with no properties. I would expect the debugger to list their fields and bean properties. Reproducible: Always
We did have this support originally. What we found is that there were some Java objects in common use that really couldn't be treated like beans because the get calls were not idemotent. For example: ServletResponse.getOutputStream and ServletResponse.getWriter will actually change the underlying output type. For now we disabled displaying fields on JavaObjects but we might re-enable this if we can find a way to interrogate without changing the state of the object.
True, that's an issue of course. But what if this was a switch just like the others that are passed to the RhinoDebugger constructor, and off by default? This would allow activation on a per app basis and delegate the responsibility to the user. Is there an easy way for me to activate this again and recompile the org.eclipse.wst.jsdt.debug.rhino.debugger.jar File? Or would changes on both sides be required?
You would only need to change the debugger and in fact if you want a hand and changing things take a look at: org.eclipse.wst.jsdt.debug.internal.rhino.debuggerStackFrame #createJavaObjectProperties This is a standalone jar so if you build it you could potentially use it right away.
Great! I checked out org.eclipse.jsdt from CVS and found the source code in question, but I am having a hard time figuring out what the right way is to produce this particular jar file. Could you give me a hint in the right direction? Thanks!
I just managed to figure it out. Checking out only the org.eclipse.wst.jsdt.debug.rhino.debugger plugin into its own project and then using the File -> Export feature seems to do the trick.
Ok, this was easy enough. Using #createProperties() for both NativeJavaObject and normal Scriptable objects did the trick for me. I propose that this could become a configuration switch, as in many cases none of the getters on java objects would modify their state. The only other option I can see is a using reflection on the java object to identify fields using their qualified name and a blacklist of a names not to include in the property list. Also, maybe it would make sense to sort these properties either according to their native order in the object, or to first list all values, then functions? At the moment, they appear to be alphabetically sorted. Is this happening in the UI side inside Eclipse?
(In reply to comment #6) > The only other option I can see is a using > reflection on the java object to identify fields using their qualified name and a blacklist of a names not to include in the property list. If at all possible I'd like to avoid having a configuration option as the usability invariably is not great. What I'm thinking of is to just show the real Java Class fields and methods because that is at least safe. We also show bean like properties but I want to avoid any calls to get values. For your use-case where we really might want to show the bean values we "might" either provide some indicator in the variable view to allow something like a right-click get value or else perhaps use a Java class name whitelist.
