[RDT-Dev] RE: JRuby Branch

[Chris W. <cwi...@ro...>]

Markus,
	I checked in a copy of code that was incomplete. I'll try and
check in a working copy in the next week. The biggest issue was finding
out reconciliation and I made a big breakthrough in finding out how it
was finally done in JDT. (It was _not_ easy to find!)

There shouldn't be a dependency on a jruby project, I forgot to remove
that, I built the jar and included it in rdt.core as a lib.

As general info-sharing, I thought it'd be useful to let you know what I
finally discovered about the way the JDT works in terms of its internal
model and reconciling, etc.

There are two major concepts that I didn't immediately grasp, the first
is how the model structure is created, the second is how the reconciling
and work is done on the model.

The first issue took me a little bit to realize. We initially had all
parts of the internal model as RubyElements with some type fields to
distinguish what they were, and the object were fairly lightweight, no
operations could really be performed by calling methods (like open,
save, reconcile, etc.).

The JDT splits the pieces that form the bare hierarchy (handling
associations between elements like parent-children relationships), and
the "rich model" that can perform concrete operations on the model
(reconciling, saving, opening). The bare hierarchy is in Info objects.
So each section of the model has its own Info object(JavaModelInfo,
CompilationUnitInfo, SourceFieldInfo, etc) that has lower access levels
(I think they're package protected) and stitches the model together. The
"rich model" objects are the CompilationUnit, SourceMethod, SourceField,
etc. These are the objects that are safe to pass around to perform model
operations, and each has its own interface.

The CompilationUnit seems to drive the parsing internally. It asks for
its own contents and then a parser creates all the info objects. The
rich objects are sort of created on-demand.

It took me a little bit to realize how they did this and why. I may aim
for this, but the info objects are really just about being paranoid
about encapsulation more than any functional concern. We'll see if I can
pull it off.

The second issue is how JDT knows to work on the latest copies of code.

Each CompilationUnit holds a reference to its WorkingCopyOwner.

A WorkingCopyOwner of PRIMARY means that we are reading from the
underlying file. The JDT maintains a list of working copies per
CompilationUnit in the JavaModel (PerWorkingCopyInfo inner-class).

The JDT UI plugin sets up a WorkingCopyOwner with a DocumentAdapter.
What it does is wrap an IDocument to look like an IBuffer. So when the
createBuffer method is called, the IBuffer returned is actually the
DocumentAdapter. To link the compilation unit, buffer, and document the
DocumentAdapter asks the CompilationUnit passed into createBuffer for
its resource (getResource()) and if it is an IFile it then asks the
TextFileBufferManager for the buffer for the given file. From that it
can get a handle on the IDocument. If it isn't a file, it uses the
singleton DocumentAdapter.NULL which has only no-op methods.

(When the TextFileDocumentProvider connects to a file it connects to the
TextFileBufferManager. The DocumentAdapter asks for the corresponding
TextFileBufferManager for a given file, and subsequently the IDocument.)

So when operations are done where the Compilation Unit looks at its
buffer (getBuffer()), it will eventually get rerouted to receive the
DocumentAdapter and therefore the latest contents of the IDocument

I think a side-effect is that files which aren't opened can't be
modified as the DocumentAdapter.NULL will just perform no-ops for
everything.

Thanks,
Chris

> -----Original Message-----
> From: Markus Barchfeld [mailto:Mar...@gm...]
> Sent: Sunday, January 16, 2005 4:39 AM
> To: Chris Williams
> Subject: JRuby Branch
> 
> Hi!
> 
> I wanted to have a look at the jruby integration, but there are
> compilation
> errors: CommitWorkingCopyOperation calls unknown Methods in
IRubyScript.
> Furthermore there is a dependency to a project "jruby" in
> org.rubypeople.rdt.core.tests. There is a project org.jruby in CVS
(HEAD)
> but
> its probably left over from the first attempt of using jruby. I think
that
> we
> should update it to the current version of jruby (are you using
0.7.0?)
> 
> Please let me know when you have checked in the changes into CVS and
what
> issues
> are left over (e.g. reconciliation), maybe I can help.
> 
> Despite the compilation errors I could start a Runtime-Workspace
(error
> occured
> when I tried to save a file). I compared the new outline with an
outline
> of a
> file which shows a corrupted outline with the current version: and ,
> voila, the
> new outline is correct (and provides additional info about local
> variables)!
> Excellent!
> 
> But I couldn't navigate from the outline view to the editor, are there
any
> problems or just not-checked in code?
> 
> cheers
> Markus
> 
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.6.13 - Release Date: 1/16/2005
>