Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
AW: [jdt-ui-dev] Refactoring: Any plans for a Lint like tool (...a tool to identify bad code smells...)?

> -----Ursprüngliche Nachricht-----
> Von: jdt-ui-dev-admin@xxxxxxxxxxx
> [mailto:jdt-ui-dev-admin@xxxxxxxxxxx]Im Auftrag von Scott Stanchfield
> Gesendet: Mittwoch, 4. Dezember 2002 15:20
> An: jdt-ui-dev@xxxxxxxxxxx
> Betreff: RE: [jdt-ui-dev] Refactoring: Any plans for a Lint like tool
> (...a tool to identify bad code smells...)?
>
>
> There's nothing wrong with using ANTLR for a tool like this ;)

Well, I didn't meant generally that is a wrong idea by using ANTLR or JavaCC
etc. It depends IMO on several points and what you intend to support:

- If it is hard to determine how an IDEs refactoring API works at all, or
such an API isn't documented, then using ANTLR/JavaCC might be the better
way to reach the aim.

- If you have to be portable between different IDEs or you want to support
different IDEs with an own build refactoring tool etc. you sure better use
ANTLR/JavaCC here, since every IDE uses different underlayed parser
architecture concepts here.

But if you just want to enhance some specific primary IDEs refactorings
here, why shouldn't you reuse it's main build in capabilities here? I mean,
where Eclipse has already build in support for incremental code parsing, AST
caching and searching etc. why should one rebuild all this say via ANTLR, if
he just want's to do all this mainly for Eclipse and none of the other IDEs
around.

BTW, in the past I've used ANTLR a lot for such purposes, mainly for an own
JBuilder integrated refactoring tool and some other code
restructuring/manipulation tools. However, in the mean time Borland has most
of this build in themselves into their IDE and thus my past old tools have
got somehow obsolet now.


> (I used to work for Terence Parr, its creator, and I'm looking at
> porting my
> ANTLR debugger, ParseView, to Eclipse at some point ;)

I know that ParseView (well, possibly an older version of it). I've once
used it for debugging an ANTLR crossreference tool I had developed. But this
is now some time ago. - Last time I looked at ANTLR, there wasn't any
suitable ParseView version available for it, so you must have upgraded this
one in the mean time.

> Sure, someone could write a tool that uses the Java AST support
> in Eclipse,
> but then that tool would only be useful inside Eclipse.

Yes, exactly, see my above points!

> Some fo the tools
> like this I've seen (javacheck, for example, and the auditing tools in
> Instantiations' CodePro Studio) target other environments, and
> decide to use
> other tools like ANTLR.

AFAIK, Instantiations CodePro uses ANTLR for the refactoring part, at least
they did so in the past, when they offered IBM VAJ and JBuilder supporting
versions of their tools. I don't know what they actually use internally, but
I believe it will still be ANTLR based, since they invested some time to
develop this.

> Of course, one could make the argument that Eclipse reinvents several
> wheels. Even so, where's the inherent harm?

Yes, this always depends on, from which side you look at it. As a coin has
two sides, this also applies to this theme.


-Valentino



Back to the top