Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Apache Wiki <wikidiffs@apache.org>
To: Apache Wiki <wikidiffs@apache.org>
Date: Fri, 13 Aug 2010 15:33:02 -0000
Message-ID: <20100813153302.81965.21647@eosnew.apache.org>
Subject: 
 =?utf-8?q?=5BHarmony_Wiki=5D_Update_of_=22Harmony=5FJDB=5FCommand=5FLine?=
 =?utf-8?q?=5FTool=22_by_DanielGong?=

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Harmony Wiki" for c=
hange notification.

The "Harmony_JDB_Command_Line_Tool" page has been changed by DanielGong.
http://wiki.apache.org/harmony/Harmony_JDB_Command_Line_Tool?action=3Ddiff&=
rev1=3D3&rev2=3D4

--------------------------------------------------

  =

  =3D=3D=3D 2. Design =3D=3D=3D
  =

+ Since the JDB implementation is supposed to be compatible enough with RI =
(Sun JDK), I don't have to specify the commands and function it supports. H=
owever, as I will mention in the challenges part, a detailed specification =
of JDB will be very helpful. I'm planning to create and maintain such an op=
en document during the development of JDB.
+ =

+ For the code framework, the most important point I have to mention is I u=
se enum to implement commands, define match and run methods in the enum cla=
ss and  override them in the enum instance if necessary. I believe the desi=
gn makes the code structure clear and the only shortage is the long code.
+ =

+ For those developers who are not familiar with JDI, I'd like to provide a=
 metaphor to describe how to design debugger with JDI: it's not the debugge=
r that drives the program to run (debuggee) or stop; the program just run b=
y itself, if the debugger wants it to stop, set up a barrier (any event req=
uest that will cause the program to be blocked) to stop it; if you want it =
to continue, jump over the barrier (handle the corresponding event) and go =
on.
  =

  =

  =3D=3D=3D 3. Challenges =3D=3D=3D
@@ -24, +29 @@

  =

   *JDB supports not only variable value display but also Java expression v=
alue, which raise the problem of how to calculate a Java expression in JDB.=
 Regis (Regis Xu) suggested that we need to parse the expression string to =
find out which part should be calculated at debuggee side, and which can be=
 done at jdb side.
  =

+  *Matching, parsing and error handling of JDB commands might be easily im=
plemented with straightforward simple algorithm but difficult (at least for=
 me) to find a perfect way. In my implementation, I split the command with =
spaces and match them by the prefix. For commands with just the same prefix=
, distinguish them by the following arguments. This makes it easier to matc=
h commands and parse them, but fails to handle errors in a uniform way. An =
alternative way is regular expression matching, which will still need to pa=
rse the command. I'm considering whether it's a better way.
+ =

  =

  =3D=3D=3D 4. Achievement so far =3D=3D=3D
  =

- The project started as a project of Google Summer of Code 2010. By the ti=
me when gsoc 2010 ends, the project has a code base which have a framework =
or structure of how commands are parsed, matched and executed in jdb, but d=
o not have all commands implemented.
+ The project started as a project of Google Summer of Code 2010. By the ti=
me when gsoc 2010 ends, the project has a code base which have a framework =
or structure of how commands are parsed, matched and executed in jdb, but d=
o not have all commands implemented and there are still some commands do no=
t work well. Don't worry, I'll go on with it.
  =

  =

  =3D=3D=3D 5. Future work =3D=3D=3D
  =

- =

+  *First of all, implement all of the commands and fix the bugs.
+  *If time permits, create and maintain a document that specifies jdb.
+  *Add enhancement to the jdb implementation.
  =

  =3D=3D=3D 6. Contact info =3D=3D=3D
 =20