> > Netbeans debugger and Sun's jdb demo use JDI connectors provided by > > underlying JDK, and thus may occasionally use shmem transport running > > with RI (they use some internal algorithm for choosing appropriate > > transport). > > I wonder if they will 'fall back' to using dt_socket if dt_shmem is > unavailable.
I doubt so. They probably rely on the standard set of connectors and transports and apply some heuristics for choosing most appropriate one. I experimented a bit with NetBeans debugger and Sun's JDB demo. JDB running with -attach or -listen option uses dt_shmem transport on Windows, and thus cannot connect to application started on Harmony. On Linux only dt_socket trrnsport is available and it is used by default. However, it's is always possible to use option -connect and specify any available connector and transport, but in a much more sophisticated syntax. NetBeans 5.5.1 looks using socket connector by default while launching application locally on both Windows and Linux platforms, and thus works well with Harmony. In attaching to a remote application it allows user to choose any available connector and transport, so both dt_socket and dt_shmem are supported. However, I'm not sure if NetBeans is able to recognize and use any other pluggable connectors, apart of standard ones, if they are provided by JDK or available as a pluggable module. > > I'm not sure if commercial debuggers, e.g., integrated > > into Idea and JBuilder environments, use JDI connectors from > > underlaying JDK and allow choosing particular connector. Most likely > > they behave the same way. > > Sorry, do you mean there is a JDI client implementation in Sun's JDK for > applications to use? Yes, JDI implementation based on JDWP protocol is included in Sun's JDK (located in JDK/lib/tools.jar), as well as in other commercial JDKs. Starndard connectors and transports are also included into tools.jar, though since 1.5 they're made pluggable. JDK also provides jdb tool as an example of a Java debugger based on JDI and JDWP. Running "JDK/bin/jdb -listconnectors" prints list of connectors and transports supported by this JDK. > > The problem is that implementation of the same JDWP transport in > > different JDK should be compatible. Otherwise it may break > > interoperability between debugger and debuggee if they are started on > > different JDKs (e.g., debugger started on RI tries to connect to > > debuggee running on Harmony). Implementation of socket transport is > > based on well known sockets API and thus is de-facto compatible > > between different JDKs. For shmem transport provided by RI > > implementation is not evident and is not documented anywhere, so it's > > hard to implement it in a compatible manner even following these > > specifications. > > Yes, that's what I'm trying to figure out here. If it is not part of a > spec then I guess it is not part of Java compliance, even though we may > want to do it for compatibility with the RI. Yes, number and internal implementation of JDI conectors and transport services are not a part of JPDA specifications, it depends on JDK wendor. I think it's assumed that JDI connectors and transport are pluggable, and thus can be used transparently on any JDK or JRE participated in debugging session. However, in practice, JDI connectors and transports are not provided as a pluggable module and are included into each JDK or JRE, and thus should be compatible between different JDK's. > > If someone likes to make independent implementation of shmem JDWP > > transport, e.g., based on pipes, he probably should give it different > > name - dt_pipes or so, in order to distinguish it from RI's dt_shmem > > implementation and avoid compatibility issues. But I doubt that any > > popular Java debugger will be able to use such a non-standard > > transport, at least without special tricks. > > Yes, but I think in this case we probably should be trying to so the > dt_shmem transport first. This will require investigation of internal behavior of dt_shmem transport. [1] just mentions that shared memory transport "uses a shared memory region", but does not provide details. BTW, I missed link to a good description of development and deploying transport service [4]. > > [1] http://java.sun.com/j2se/1.5.0/docs/guide/jpda/conninv.html > > [2] http://java.sun.com/j2se/1.5.0/docs/guide/jpda/jdwpTransport.html > > [3] http://java.sun.com/j2se/1.5.0/docs/guide/jpda/jdi/index.html [4] http://java.sun.com/j2se/1.5.0/docs/guide/jpda/jpda_spis.html Thanks. Ivan
