It seems like a lot of the features in jde need to scan java sources for
regexps. Wouldn't it maybe be a good idea to try to build up a repository
that goes along with the source, which new features could be built upon?
Along with the advantages this would bring it would certainly imply a lot of
work and disadvantages of various kinds. I haven't given this much thought,
but maybe somebody else already has?
--
knut
> -----Original Message-----
> From: Richard den Adel [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, March 19, 2001 8:04 AM
> To: Kevin A. Burton
> Cc: [EMAIL PROTECTED]
> Subject: Re: [thinking out loud] adding refactoring support to the
> JDE.
>
> I am using JRefactory right now, it is open source. JRefactory is
> written in Java and currently supports integration with JBuilder and
> some other IDE's.
>
> I am not a lisp wizard, but it might be possible to integrate JRefactory
> with JDE using the beanshell or something simular. JRefactory currently
> supports refactorings based on a UML model generated by JRefactory the
> first time for a package.
>
> You can take a look at it at this page :
> http://jrefactory.sourceforge.net/chrisdown.html
>
> JRefactory depends on `pretty printer', which can modify your source
> code according to a code standard.
>
> Richard.
>
> Kevin A. Burton wrote:
>
> > OK.
> >
> > I think some of you have heard of refactoring. It has really taken off
> recently
> > as another technique for improving the quality of existing code.
> >
> > While I think that is well and good, the use of refactoring tools can
> save
> > developers TONS of time. I would really like to see some type of tool
> support
> > for this in the JDE even if we have to write it ourselves.
> >
> > A good example of how much time it takes is a standard Java refactor of
> "rename
> > package". Just look at how much work this is:
> >
> > - create the new directory
> > - update the package statement.
> > - remove the old directory from cvs and add the new directory
> > - go over all files and change their import statement.
> > - now go over all your additional projects that used this package and
> update
> > - *their* import statements.
> >
> > Last night I had to change 5 packages and this took 40 minutes. A
> refactoring
> > tool could have done this in 3. :( It is not like this is rocket
> science but I
> > would rather spend time working on algorithms than renaming files and
> making
> > sure everything compiles. I would estimate that I spend 60% of my
> development
> > time on refactoring efforts.
> >
> > I have given a good deal of thought to this over the last few days.
> There are
> > no decent Open Source/Free Software refactoring tools available. Even
> the
> > proprietary ones aren't that great. This is good news as it means we
> have a
> > good opportunity to create a solid tool.
> >
> > I think there are also some issues here though:
> >
> > - what language do we write it in?
> >
> > - writing it in elisp has some advantages because it would work
> natively and
> > have support for the JDE. There are also some drawbacks:
> >
> > - other Java developers on outside IDEs (netbeans) won't be able
> to use
> > it. At the very least even if these aren't emacs people they
> are still
> > smart and should have some feedback and could contribute to
> > development.
> >
> > - We will have deal with the non-threaded nature of Emacs. Emacs
> will be
> > locked on IO when dealing with files. It would be nice if I
> could kick
> > off a refactor and then go about reading my e-mail again.
> >
> > - writing it in Java would be good but:
> >
> > - we would have to use a regexp package for some of the files. The
> good
> > thing is that a lot of this is already in gnu-regexp.
> >
> > - some logic would have to be dedicated to parsing information from
> .java
> > files. Where a method starts, what its params are, etc. Semantic
> already
> > give this to use.
> >
> > I think I have convined myself that it should be in java with a lisp
> interface
> > into the JDE.
> >
> > Anyway. Is there anyone out there interested in working on this with
> me?
> > Hopefully someone who has the refactoring book too :). I think we could
> at
> > least work on the architecture in our spare time and then start
> scratching our
> > individual refactoring tool itch. I want to work on "rename package"
> first.
> >
> > Kevin
> >
