Hi Matt, I m not sure what strategy would be best for class loading. I would be interested in your AggregateClassLoader. The end result of this work will be a

Message 1 of 2
, Aug 25, 2003

0 Attachment

Hi Matt,
I'm not sure what strategy would be best for class loading. I would be
interested in your AggregateClassLoader.

The end result of this work will be a commercial application. I would be
happy to share any work on getting the refs.g grammar completed to resolve
references. That should lead to one or more methods in CodeProject.java
like refMethod(). I see the needs of interested programmers diverging at
that point, anyway.

Jim: I would recommend that on your phase II, you
open up the class loading to pull from any specified
classloader or set of classloaders (I have an
implementation of an AggregateClassLoader for this
purpose if you want it). This way a client of your
code should be able to use a different JRE than the
runtime, or they can use the default if they like.
What license do you plan to use with your work?

>
>
>
> Hi Terence,
> The code is coherent - the grammars "Tool" and the
> code compiles. The
> only minor difficulty is the defs.g and refs.g could
> only "see" the
> JavaTreeParser when the -glib java.tree.g option was
> used.
>
> I did an extended run-through of the code. I made
> an Eclipse project to
> hold/compile/debug the code. I had to Tool refs.g
> and defs.g outside
> Eclipse. Expandedrefs.g and Expandeddefs.g helped.
> MethodCallExpression and objectOrClassExpression
> are the most
> interesting/involved of the rules. Are these rules
> complete/accurate? The
> resolution of overloaded methods aside, are there
> deficiencies in the logic?
> Is there a reason, other than lack of time, for not
> extending the actions to
> other areas of the grammar ( expression, etc...)?
> If anyone else would like
> to see my extended notes, let me know.
>
> My plan:
> I. Resolve field/variable references as to
> create a project.refField()
> method similar to project.refMethod(). This method
> does nothing other than
> print out the referencingMethod, referencedMethod
> and the AST of the method
> call. Should the project, AST or something else
> (symbol table?) hold this
> unused information? I will try to hold off
> "putting" the information
> somewhere. The grammars are true to "each phase as
> simple as possible".
> Ia. Get file (already there), line and column
> information to each node.
> II. Use reflection to load information about
> imports from jars on
> classpath.
> III. Extract/dump information at the end of the
> REFS phase for each
> Clase
> IV. Extract/dump information for whole project
> where the at the end of
> Main.java
> V. Figure out the memory and speed problems
> VI. Catch and logically proceed on exceptions.
>
> Jim
>
>
> Extended notes deleted
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>

> Hi Matt,
> I'm not sure what strategy would be best for class loading. I would be
> interested in your AggregateClassLoader.
>
> The end result of this work will be a commercial application. I would be
> happy to share any work on getting the refs.g grammar completed to resolve
> references. That should lead to one or more methods in CodeProject.java
> like refMethod(). I see the needs of interested programmers diverging at
> that point, anyway.

Makes sense. Let's keep the core as free and open given that I gave this (originally
commercial) head start out. It would be great to have a nice java cross-referencer as
BSD or public domain so I'll help all I can. Sorry about the vague state of the software
as I left it on the side 2 years ago. The grammars should be just about up to date wi
the antlr.org grammar.

Stupid viruses caused yahoogroups to stop sending me antlr-interest mail so I'm
behind. School starts tomorrow too, but I should have time to help.

Perhaps Jim you and I should speak by phone to get started. Just email me directly.

Best regards,
Terence

Your message has been successfully submitted and would be delivered to recipients shortly.