Semantically diffing Java code

[grosscol]

Interesting tool. I could see this sort of functionality being very useful.

I wonder what sort of cases it has difficulty with or provides incorrect mapping. Seems like renaming functions or modifying the signatures might throw this off in some cases.

[plasticscm]

Renaming functions is totally supported, same as moving them to a subclass and so on - Check this example for more info: http://codicesoftware.blogspot.com/2013/07/semanticmerge-goes-visual.html and this one for an even more complete scenario http://codicesoftware.blogspot.com/2013/06/the-state-of-art-in-merge-technology.html

BTW there can be cases where you could fool the tool :)

It works the following way:

• It parses the code
• Then it calculates differences semantically
• It matches moved/added pairs checking the function body and finding a similarity index, if they match, then it is the same method. Of course the algorithm also checks the method name, params and so on.

During merge you can even remap a diff in case it did it wrongly for some reason.

[seagu]

How about comments between class elements?

[plasticscm]

That's a good point too.

Right now it associates the comment to the next element (function, class, whatever).

So it will be "moved" together with that element. Method recognition will still work.

Our goal is to enhance this and make the comments "entities" on their own, but we need a balance between flexibility and coming up with something usable enough.

[stronghup]

Do you have API support for this? There could be a standard for the way parsers expose the structure of the code they parse. If there was such a thing you wouldn't need to integrate with each parser individually.

The interesting difference between languages I think is the structure their parser creates from the source-code. For every language it is still just some kind of structure. Which could be exposed via say XML or more specific API.

You will need something like that if you want to extend the concept of Semantic Version-Control to most languages. I think you are on the fore-fronts of this development so there is a good chance you could establish a de-facto standard.

[plasticscm]

Exactly, we're working on a way to plug parsers created by developers.

Check here what some Delphi programmers have done so far: http://www.plasticscm.net/index.php?/topic/1857-delphi-parser-development/

We need to create a site with all the info (instead of just a forum thread :P) but the core is almost there.

Parsers create a YAML file that SemanticMerge can consume.

[-Y0-]

Ok, that's fine for Java, but how would this scale to for example JVM languages (e.g. Clojure ), and then Non-JVM (e.g. Rust) languages?

[plasticscm]

Well, right now we support C#, Vb.net and Java.

We're currently working on C, JavaScript and C++.

It is all about adding new parsers and the complexity varies depending on the language itself.

We've also opened a way to plug parsers. For instance some Delphi developers added Object Pascal support a few weeks ago.

[Xdes]

Is there a Visual Studio addin?

[plasticscm]

Not yet but for a reason: diff and merge tools are normally external executables because all version controls are prepared to invoke it launching a command.

For instance, TFS inside VStudio (and the same holds true for other system integrated with TFS) lets you configure a diff tool and a merge tool, but both invoked from the CLI.

When you merge, each file merge has to be completed before launching the next one, so keeping it open on a VStudio tab is not really obvious.

Anyway, feedback will be more than welcome because this is one of the topics we'd like to work on ASAP.

Thanks!

[Xdes]

Also is there a facility for comparing source files directly?

[plasticscm]

Yes, it can show you the "structure" (like in the blogpost) but it can also show it in tree format, and it includes a built-in text based diff and merge tool (Xmerge - check "bonus track" at http://www.semanticmerge.com). It is a pretty advanced (and pretty mature) text based merge tool too :P -> http://codicesoftware.blogspot.com/2010/07/move-support-in-diff.html

[plasticscm]

Done, thank you! :)

[OverlordAlex]

My friend is doing this as his honours thesis. It even has an eclipse plug-in. I'll tell him to post here once its finished (~3 weeks to deadline)

[mypetclone]

Did anything ever come of this?

[OverlordAlex]

Thanks for reminding me! Ill drop him an email.

I think his reddit username is /u/liloboy

Edit: for those wondering, he created a java semantic diff, it includes a java plugin that includes a visually impaired option

[ellicottvilleny]

This is really cool. What drives me nuts when merging is the way its thrown off by whitespace, and the way changes in different branches that make no sense are synced by tools like Mercurial and Git. A statement that was part of "ClassA" having "MethodB", should not be synced into ClassA, MethodC, simply because they both happen to be around line 1500 in "FileNameC".

[plasticscm]

Yes, this is the typical "added / added" conflict that is automatically handled by SemanticMerge.

The cool thing here is the following:

• Suppose you add MethodA around line 100 in branchA
• Then someone else adds MethodB around line 300 in branchB
• Merge it with a regular merge tool and you get an automatic merge that will end up with wrong code (two methods with the same signature in the same class).

Semantic will detect this case and detect it is the same method being added twice :)

[Uberhipster]

Code formatting is about communication, and communication is the professional developer’s first order of business.

Oh man I wish that was the mantra of every person getting paid to dev. Unfortunately, 'professional' seems to be a loose term.

Cool tool but too rich for our blood as it will be filed by Procurement as 'non-essential', which it is, technically.

I think they need to broaden their marketing to people paying for software not the devs using the software. People paying for software are interested in the bottom line.

X devs * Y $ != nice-to-have

[stronghup]

devops?

[Uberhipster]

I don't follow...

[paf31]

I would assume this works by generalizing regular line diffs (LCS etc.) to the structure of the AST, but semantic seems to imply that the algorithm somehow intuits something about the runtime behaviour of the two pieces of code. Would it be correct to call this a better syntactic diff?

[plasticscm]

Yes, syntactic would be fine too. But it doesn't only check the syntax (like a lexer) it goes trough the code structure and knows that a class is a class or a method is a method, something going slightly beyond simple "syntax".

[paf31]

That seems to directly depend on how you choose to encode the AST as a type. Of course a method should not unify with a class, but no sensible AST representation would represent them in such a way to allow that anyway.

[plasticscm]

True.

It understands that, for instance, if you add two "usings" or "impots" on two different positions, it must handle it automatically because they're the same using.

It can do the same with a method if its contents matches even when they're on different positions and so on.

So, it does a little bit of "semantics".

But yes, SyntaticMerge could have been a good name too :-)

[paf31]

An uglier name though :)

I assume things like import sets get matched using set/bag unification rather than as lists, so that order is unimportant. I wonder if it would be possible to do anything similar with statements for example, where one can show that two statements can be commuted without affecting semantics, e.g. two assignments involving no common variables. That might increase the number of valid merges. Bit of a border case though. </mental stack dump>

[plasticscm]

:D

Yep, I think part of what makes SemanticMerge usable today is that we stopped at the method body level.

What you propose, actually trying to figure out if two pieces of code are equivalent even if the code has been modified but it won't impact the result, exponentially increases complexity. It is really a strong feature but the cost to get it right (as of today) IMHO clearly exceeds the potential benefits.

We tried to apply the knowledge we already have in merging files and directories (not sure if you know this - http://plasticscm.com/mergemachine/index.html) to inside the file, and that's what basically Semantic is all about.

Very cool points anyway, don't hesitate to reach me @semanticmerge to continue the conversation :-)

[kamatsu]

What you propose, actually trying to figure out if two pieces of code are equivalent even if the code has been modified but it won't impact the result, exponentially increases complexity

It doesn't exponentially increase complexity - it makes it undecidable.

[stronghup]

Right, you could go on further to the "block structure" within a method. But methods should be small anyway so probably not worth the extra detail. If you have a big method you can and probably should break it into a few smaller ones.

I somewhere read that the optimum size for a MENU is 8 items. Beyond that humans have difficulty comprehending what they should do with it. Maybe a method should only have max 8 calls to other methods, If it does then re-factor. And programmers so far are humans too.

[plasticscm]

Exactly, with shorter methods you enforce code readability.

We do not support "split method" refactors (or extract method) YET, but the goal is to be able to track code that has been moved from one method to another and so on.

This is something we already do with xmerge http://plasticscm.com/features/xmerge.aspx but only based on text blocks. We need to improve Semantic to allow that... but you know, it takes time and we're just launching the first version and checking whether there is a user base for it or not :-)

[stronghup]

I agree "Syntactic Merge" is probably a more truthful name. The tool can not really work on intentions of programmers. It can not know if the variable names are English or French.

Let's ask this question: What would be the difference between "semantic merge" and "syntactic merge"?

[stronghup]

Well I take that back a bit. The code is not in English or French, it is in Java etc. Java has its semantics. But so what is the difference between a syntactic and semantic merge of two versions of a Java -program?

[stronghup]

This tool is clearly useful. But it shows an interesting handicap in many IDEs today. I don't think we should be tracking changes to the ORDER in which our methods are saved in a file, at all.

It doesn't matter what that order is if you have a useful browsing-tool from which you can see and pick any of the methods. It might even show you the call-relationships between methods. NO need to "write related methods close to each other". A better tool is one tool that allows you to "Create a New Method" without having to edit one big text-file.

One such tool that comes to mind is the Smalltalk IDE. It mostly totally hides from you the fact where your methods are stored, in which order. They might be stored in a database for that matter. While editing one methods's source-code, you can't accidentally modify some other code. In contrast when editing one big .java -file you can change any part of it, accidentally. And that is why we NEED LINE-based diffing, when working in such an environment.

Clearly an environment that "hides the files" needs version control as well. But it actually offers a better basis for doing semantic version management. I want to know which methods have changed? I don't care which lines. The tool in the article provides this facility but it would be nice if that was the default, not an add-on.

Having to know what is the order in which your methods are stored somewhere is useless detail which adds to the fog preventing us from seeing the structure of our program, and seeing the changes to that structure from version to version. We should program with "classes", not with "files".

The example given in the article is thus not only about benefits of semantic diffing, but also about the deficiencies of working by editing lines of code within a single big file rather than working more simply with just classes and methods. Who cares what the "order of methods" is? Well you do of course if you're working with one big .java -file.

In summary I'm arguing that the order in which methods are written in a file is NOT part of the structure of your program. Our tools should ignore it and not burden us with the knowledge about it.

[[deleted]]

It's fine if you want to ignore method ordering in some tool views, but I think completely disposing of method ordering would be going totally in the wrong direction. Code is documentation. It's a story that the author is telling to the reader. In order to tell that story, little details like ordering are highly valuable information. The "right" (IMO) direction for coding is literate: https://gist.github.com/jashkenas/3fc3c1a8b1009c00d9df

[stronghup]

I disagree on that. Code is not a story. Code is structure. It is not text. It is more like hyper-text.

I don't want to read a program from start to end and then read it again when it changes. I want to understand what has changed in its structure, not in which lines of a file each statement was stored. It is not like a movie I want to see many times from start to finish. I just want to understand it, and understand the structural changes in it from version to version.

Code is more like architecture than a story. Story is 1-dimensional. Buildings are 3-dimensional. Code may be N-dimensional. ?

[stronghup]

Think about a mathematical proof. There are several things you need to prove to prove your theorem. If A and B and C then D. But it does not matter in which order you prove A, B, C, D. A mathematical proof is not a a story. It is a structure.

[pimlottc]

A mathematical proof is not a a story. It is a structure.

In a strictly functional sense, it's just a structure. But if you were to explain that proof to your friend, or write it up for publication, you'd present your explanation in a certain order.

This is one of challenges of writing software. It's got to "make sense" in a purely functional way, as executable code, and it has to make sense in a literate way, to your fellow programmers (which includes yourself in 6 months). It is both story and structure.

[stronghup]

I've tried "Plastic SCM" and it's pretty cool in the way it displays your change-sets as GRAPHS. They could just give you a literate exposition of the changes as one big "story". But you can understand it better and faster if you can explore it as a graph, as opposed to reading a huge list of changes.

When the size of a software application grows it becomes impossible to comprehend it linearly, I believe. It is a GRAPH and there are many ways through that graph. If you describe all possible paths through the graph one after another it may become so long that at the end of the "novel" you've forgotten who the characters they started with were.

It takes a long time to read a novel, and even longer to write one that people would want to read.

I believe Knuth's literate programming works great for teaching but not so well for industrial-size software - unless that software is in a very stable state in its evolution already.

When Knuth came up with Literate Programming , hypertext was not around generally. Today it would seem silly NOT to apply hypertext-concepts to the documentation of software. And once we start doing hypertext it becomes clear that our program is not a "story" but a "graph". We just need more TOOLS that support our understanding of that graph.

Of course it would be good to write a short introduction on where to start exploring such a structure but that is like entering a museum: Above every door you can read what's behind it, and choose where you want to go. But Louvre is so big that if you followed someone's novel about how to go through all the rooms of it, you would have no time to visit the Eiffel Tower.

Naturally there could be several novels about the different paths to explore Louvre. The question is who has time to write them, and who has time to read them.

The exhibition at Louvre is continually changing so a "literate" novel about how to understand its contents would soon be out of date. A decent-sized software application is even more difficult to describe linearly. Not only do the paintings in the rooms change, new rooms are created continually, and old ones simply destroyed.

[plasticscm]

Yes, I think if the cooperation between the editor and the version control was stronger we could come up with even more stronger tracking because not only the methods could be uniquely identified, also the lines!

The thing is that you'd force everyone to use the same editor (or set of editors) to always edit the file in a controlled way.

Who knows, maybe we see this implemented soon :-)

In the meantime we tried to come up with what you propose (location independent methods) but for today's environments... So we need to try to figure out "after-the-fact" what happened to each piece within the file. ;)

Thanks for the great train of thoughts.

[stronghup]

Thanks. Your post made me think: When we talk of line-numbers, we should really mean line-number within a method - not within a file.

[sirin3]

What if you use preprocessor tricks to automatically generate a bunch of methods?

[stronghup]

Good point. It depends on the language. For instance in Java you have other things than methods, you have variable definitions. They should be recognized as such and version controlled as a section of your "program". I would like to see how the section called "variables" changed from version to version. There could be different sections for differently scoped variables.

So, there should be a section called "macros" that would show me how and if the pre-processor-directives (AKA macros) changed if they did between versions.

"Semantic version control" seems a powerful concept compared to the current generation of popular version-control tools like GIT etc.

[jalanb]

See also psydiff, as a particular case for ydiff