Change the AST nodes or create new ones to modify source code like refactoring.

[matozoid]

This was Júlio's plan with the project.

[ftomassetti]

Well, I think we could do that by dumping back the source code. It is already possible but original formatting is lost (we do not store whitespaces) while comments are not lost but they are re-arranged. I think we spenti energy on comments attribution also for this reason, to support refactoring.

Maybe we should think about additional methods that could help with refactoring and provide some examples in the documentation.

What do you think?

[cciollaro]

Hi, I think preserving whitespace would be a great feature to have. Júlio stated back on the google page that the DumpVisitor needs to be updated to respect token positions. As I can see, ASTNodes already store row and column information.

[ftomassetti]

Yes but if you do refactoring how that affects the whitespaces? I think it becomes quite tricky...

[cciollaro]

That's a good point. If you change a node's length then you'll likely have to adjust the position of every node after it by that amount. e.g. if you add a line to a method, you need to update the position of every node after that node by adding 1 to the line positions.

I think another possibility is to give whitespace its own token.

Do either of those sound feasible?

[ftomassetti]

yes but if you add one line it should have the indentation of the line above or below (what if they are different?).

Now, suppose you refactor this code:

'''
int c = foo(bla bla bla,
a+b);
'''

You extract the second parameter of foo with something else, while moving the second parameter outside, like that:

'''
int c = foo(bla bla bla, 10);
int d = a+b;
'''

What about the space to put in fron of 10? And the space to put in front of a+b?
I would not know how to manage the whitespace in this case.

[ftomassetti]

To be clear: I think it would be VERY nice to have refactoring preserving indentation, I just think that in practice it is not as easy as it seems.

We can give it a try however.

[SmiddyPence]

I think it will have to be template based. So if you commit to having a class refactored, you are committing to the white-space conforming a determined standard - (and probably applied to the rest of the class as well not just the refactored section).

[prior]

I'm trying to use javaparser to auto generate pull requests, so I'm trying to keep my diff's as tight as possible and not obliterate different peoples' projects' java styles -- unfortunately, as is-- I can't use.

To this discussion - shouldn't it be possible to just worry about the formatting of the things you're adjusting while leaving everything else alone? And for those things you're adjusting, you can do some basic guessing on formatting intentions from the initial load of the compilation unit, i.e. determining tab/space-indent and code width limit (those two are probably the most important and would likely get you 99% of the way there, though you could probably glean other formatting preference subtelties as well).

Wish I had time to help out, but offering my personal usecase here in case it helps... thx for keeping this project alive!

[ftomassetti]

This issue is over 1 year old, let's celebrate :D

Personally I am interested in this topic and I would love to work in that direction, I am just not sure if refactoring should be part of Javaparser or should be part of a derived project. What do you think?
In which scenarios it could be useful?
How important do we think is it?
Who is interested?

[matozoid]

I just checked when my first commit was: Oct 30, 2011 8-O

Wasn't somebody using javaparser exactly for this purpose?

[ptitjes]

@matozoid I was.

During 2012-2013, I developed a tool for my work to do what I call "massive refactorings".
That is pattern-based (patterns with both syntactic and semantic filtering) selection and rewriting of nodes. We used it for a lot of tasks because we had a gigantic source code base. Each I had identified a refactoring that could be made multiple times, I programmed a script to apply it. We also used it to generate code. We just started to redevelop something similar with @ftomassetti.

As for whitespace preserving, at that time, I had a custom DumpVisitor that used heuristics based on the positions but this was really dirty and not working correctly every time. I have some better ideas to preserve white-spaces now and I started to develop a proof of concept there: https://github.com/ptitjes/javaparser/tree/lex-preserving

[SmiddyPence]

I think we have discussed this at length now and it is generally agreed that this would be part of a separate library with similar language tools.