I see your point about performance, and of course the proposal is yours :) However I would put forward the following arguments in favour of using Java and JDI: - JDI is _the_ spec'ed public API for Java debugging, JDWP only describes the protocol. To write a jdb tool that uses JDWP directly sounds a lot like you will end up rewriting JDI in C code before actually writing the jdb tool, and that is not the remit for the project. Rewriting an API that already exists in Java (and is supported by another project - Eclipse) does not sound like a good idea. - JDI provides a solid spec to code to. You can take a JDI based agent to another Java runtime and it should work, so any additional function you add to the new jdb tool will immediately be available to use on all runtimes by launching your tool on that runtime. - I would argue that performance for a command line debugger is not a major issue. In a GUI environment, where multiple stack traces, variable displays and other data are being refreshed regularly, performance would be more important. However, in the simplified command line environment the need for super-fast processing of packets becomes a non-issue as there is so much less going on simultaneously. - A Java based tool is a lot more portable and easier to maintain. We also already have an intelligent launcher setup in Harmony which will automatically launch your executable Java class for a tool, so going down the Java route will fit neatly into the tools design we already have in the project.

I hope you can see my point about JDWP vs. JDI for this tool. Good luck writing the proposal - don't forget the deadline is tomorrow!

Regards,
Oliver

WenDong Zhang wrote:
Hi Oliver:

We did consider implementing this tool based on JDI, we have a
misunderstanding on between C/C++'s efficiency and Java's usability
for this project. We considered the implementation too extremely,
there is a long chain from JVMTI to JDB: JVMTI - JDWP - JDI - JDB.
JDI encapsulate JDWP and we don't need to care about the protocol
detail: command, package, data type and so on. Maybe we should use the
software architecture's principle: add a midware to our implements to
decouple the dependence and more transparent to users even it may
cause a few of efficient problems.

2009/4/1 Oliver Deakin <[email protected]>:
Hi, and welcome to Harmony!

hu jing wrote:
Hi all,

   I am interested in the "jdb command line debugger tool". I find Sun jdb

Great!
is not very friendly to developers. I want to add some useful function to
this tool. Such as, Auto-complete command line, smart format for the user
input. And we can also supply some interfaces to further development.
   Wen Dong([email protected]) and I want to participate in this tool
development. We are from the same laboratory of the Department of Computer
Science of Nanjing University. We worked together for two years and now we
are both interns in IBM CDL. I think we can work out the debugger tool
pretty.

I don't know what the rules are for co-working on a project - I believe each
project has to be an individual effort. You could ask on the GSoC discussion
mailing list (mailing lists and other useful info can be found here [1]).

   The popular architecture is JPDA(Java Platform Debugger Architecture).
JPDA contains three parts: JVMTI, JDWP and JDI. JVMTI(Java Virtual Machine
Tool Interface) supply a set of native interface supplied by JVM. The
development based on the JVMTI level is complex and hard to be extended
and
modified. JDWP supplies a standard protocol for the communication between
the debugger and debuggee. And it also provides the socket interface. JDI
is
debug interface. It is mostly implemented in Java. JVMTI and JDWP are
based
native code. We want to implement the java command line debugger tool in
C/C++ considering efficiency. We will use JDWP interface for development
efficiency and Portability.

Have you considered coding the tool in Java and using JDI to access all the
required functions? I think it will be more portable, easier to maintain,
and will fit more naturally with the other command line tools we have in
Harmony.

   The following is our main idea for this tool:

   1.format the user input.
   2.validate the command arguments.
   3.Create connection between debugger and JVM, and here we can use the
JDWP Transport Interface. Based on the JDWP, We create packages containing
the command information and send packages to JVM by using the transport
interface. JVM will process these packages and send the feedback to the
debugger. And we will process this information.
   4.print the message on the console.


Schedule:
      We can work 20 hours each week.
      April 4 ~ April 30: Be family with JDWP and JDWP Transport
Interface.
      May 1 ~ May 22: meet our mentors, read the documentation and get
some
suggestions from our mentors.
      May 23 ~ May 30: to determine the final framework and algorithm
details, divide the work with my partners.
      June 1 ~ June 30: coding.
      July 1 ~ July 5: integration, test and debug for mid-term
evaluations.
      July 6 ~ August 11: process the debug, documentation and
integration.
      August 12 ~ August 24: write test unit, debug and final release.

Looks like a good plan. You need to clear up the issue of working with a
partner - if that is a possibility, or you can decide on one of you to work
on the project alone, then please draft a submission in the GSoC tool [2] as
soon as possible. The deadline for submissions is Friday 3rd April.

Regards,
Oliver

[1] http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs
[2] http://socghop.appspot.com/

Jing Hu , WenDong Zhang.


--
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
PO6 3AU






--
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Reply via email to