harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Popov" <ivan.g.po...@gmail.com>
Subject Re: [jdktools][JDWP] proposal to improve JDWP with shared memory and update to java6
Date Fri, 11 Jan 2008 14:48:50 GMT
> I believe that the Eclipse JDT debugger team wrote their own JDWP client
> code, but not sure if it supports the shmem transport.  I can go over
> and ask.

Eclipse JDT Debugger uses its own JDI implementation (JDWP client
code), which includes JDI connectors only over TCP/IP socket transport
and don't support shmem transport. There is no support in Eclipse for
using any other JDI connectors, even if they are provided by
underlying JDK.

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'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.

> Anyone recall seeing a spec for it or is it non-standard?

Any transport layer used for JDWP connection should be supported on
both debugger and debuggee sides [1]. On JDWP agent's side it should
follow jdwpTransport spec [2]. On debugger's side (JDI front-end) it
should provide a set of JDI connectors over given JDWP transport that
follow JDI Pluggable Connectors and Transports API
(com.sun.jdi.connect.*, com.sun.jdi.connect.spi.* in JDI spec) [3].

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

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.


[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

View raw message