JSDT/Confcalls/Minutes JSDT Debugger

Logistics

See JSDT/Confcalls

Attendees

Presenter: Dennis Participants: Dennis, Chuck, Max, Gorkem, Victor, Alexey, Adalberto Ilya, Orlando, Patrik, Mathieu

Notes

This Confcall is about Debugger : how it was contributed, how it works + info on current development status (at Neon M6)

Chrome dev tools was developed by Google and was released under Eclipse EPL

https://github.com/ChromeDevTools/cdt-java

Google changed license to EPL and this made the Eclipse CQ much faster, because the license was changed by source owner and released into original repository.

After CQ was done, the code was refactored to org.eclipse.wst.jsdt.chromium namespace and released to the JSDT git repository.

It actually works with most of the latest browsers:

• All browsers based on Chromium can debug JS in the same way as Chromium does (* i.e. Chrome, Opera)
• Safari is debuggable trough bridge developed by Google, 
• IE is potentially debuggable via "IE Diagnostics Adapter"
• Firefox (as IE) is potentially debuggable via adapter, plus some implementations are already available on github.com

Supports Nodejs up to v.5.6.0 - see https://github.com/v8/v8/wiki

Chromium was forked from Webkit. so it supports WIP (webkit inspection protocol).

You can search developer.chrome > chrome debugger-protocol to see specs

The latest and greatest release, as ofi March 2016, s v 1.1 (Chrome 31)

Demo

Setup and Run chromium:

1. Clone from eclipse git repository
2. build via "mvn clean install --Pbuild-individual-bundles"
3. install into latest eclipse using local update site from site/target/repository inside local git repo

Builds on it JSDT

create a local p2 repo declared wtp-parent/pom.xml - easy to use

- install Javascript Development Tools Chromium V8 remote debugger tests from that p2 repo

(you can start with Eclipse for Committers -> simple to start)

(*NB: javascript debugger bundle is in IDE workspace )

start node.js in debug mode

node -debug-brk app.js

eaxample: node -debug-brk my-helloworls-app.js

You will see the debugger listening to port XXX

Then it starts executing and it stops the executions at the specified line (the 1st)

(*)

launch config standalone V8 ...

... port  5858

And then the debugger (via WIP ) support exploring the JS object model in the application

it is not supporting all the use cases out of the box -> there are tricky use cases, 

for long running apps can use the -debug key (opposite of -debug-brk)

for this you'll need chromium:

chromium --remote-debugging-port=9222 -user-data-dir=/<user-home>/somepath

this opens the browser with two tabs, on localhost:8080/app (in our case a simple angular app)

and running the app, we can debug it on eclipse.

In the current implementation, debugging sessions are seen in Eclipse as virtual file system, anc this causes problems (Update: solved via Bug 484597 )

the debugger allows basic interactions that the normal Eclipse debugger has like explore var, hover and see hints, etc..

in the demo application we have a button linked to a breakpoint, and it actually works, stopping to the breakpoint

Development Environment

Several Options

1. JEE IDE as main env + JSDT git repo
2. Committer IDE + JBosstools as TP (*)
3. JSDT Target platform instead of JBoss one
4. Oomph installer ( very quick ) 

(*JBoss tools .target as target platform -- it has all the dependencies needed from JSDT)

Option 4 it is a great candidate, as it can save a lot of time. Plus this is simpler --> more people involved

Action: bugzilla issue  https://bugs.eclipse.org/bugs/show_bug.cgi?id=488343

Bundles, are easy to understand looking at the slides , as example: 

".V8" manage tabs; ".debug" is for branding, ".debug.core" is the core; 

".jsdtbridge" is a simple bridge between chromejs and JSDT (couple of classes)

etc...

Chromium Remote Debugger features: easy to understand, and self explained

For the High level arch. see the image on the slides

There are currently 3 implementations to work with remote debugger: V8, WIP 1.0 and WIP 1.1 

Communication is based on messages, formatted as json

Notes on JSON Parser

The ChromeDevTools JSON parser is a Dynamic parser based on Java Proxy and Reflection. It generates a static parser, which is faster to process, but it is generated only at build time (design decision) The specification of the (old) message-based protocol is specified here: https://github.com/v8/v8/wiki/Debugging-Protocol

Challenges / Actions

• Support new V8 releases
• support <script> tag in html 
• integration tests with real browsers
• statically generated parsers have problems in handling scripts loaded dynamically (e.g. mocha)
• replace manual WIP Protocol selection with auto
• Currently, the iOS debug is not convenient. We want it more convenient having some out-of-the-box support for safari with ios-webkit-debug-proxy
• Compare the performance of static and dynamic JSON parser impl and switch to fastest.
• Hot deploy for changed js files https://bugs.eclipse.org/bugs/show_bug.cgi?id=488344

There are a lot of items to complete before Neon release. All the possible help is really appreciated !

A bit of discussion

CB: it can be a challenge using a VFS, instead of the standard source (?)

DG: it was used (probably) to make simpler the communication between Eclipse and Chromium

CB: so editing in the debugger seems it is not going to happen :(

IB: seems V8 debugger is more important than WIP 

CB/AK: seems you're not going to launch debug from Eclipse 

What if having a launch config for each Node application ? ( or for any Runtime environment that Eclipse understands for Nodejs) 

GE: This Java runtime config. JSDT has that concept, but there is nothing for Node js (part 1)

Then launch conf that will use those runtime configs "that Eclipse understands"

--> how to define those runtime configs.

We need the option to use the JSDT Editor to set or breakpoints. 

Question: is the VFS that breaks our breakpoint synch ?

DG: probably yes (I have reason that let me think so)

we don't have much time, prioritize some work, and focus as the deadline is 26 of March (M6 for WTP ???) 

TEAM, [ACTION AGREED] -> Focus on Nodejs

According to: https://wiki.eclipse.org/Neon/Simultaneous_Release_Plan The deadlines are: M6 (API Freeze) M7 (Feature Freeze)

VR: usually all features should be completed by M6 [API Freeze] - In our case:

• it should be for M6 : around March 25 (for WTP) <-- but JSDT Deadline precedes WTP, and it is march 17 for JSDT
• it might be possible to have exceptions, and deliver by M7 (this will move the deadine to May)

IB: https://bugs.eclipse.org/bugs/show_bug.cgi?id=484597

GE: https://bugs.eclipse.org/bugs/show_bug.cgi?id=359436

CB: When we use the VFS we're kind of tricking the "real breakpoint". With VFS open we can not execute particular actions, like "content assist".

In the short time we have before M7, we'll need to understand and fix the Virtual File System. (* this could be a cool reason to ask an exception and deliver by M7)

CB: quick reference to https://mattermost-test.eclipse.org/eclipse/channels/webtools