Community
Participate
Working Groups
Build id: 200409240800 Compare 2 java files (that are quite similar) with each other. Would be really nice to have a "Java Structure Compare" view in this situation.
I tested it and it works if both files have the same name (e.g sit in different packages).
Ah. Of course - as you suspected - I am trying to do this with 2 files that have a different name. I wanted to quickly see how much benefit could be gained by extracting a superclass for 2 quite similar classes.
It is always possible to compare two differently named containers with each other and get structure compare on its children. So if you have two CUs, they probably contain two classes with different names. Comparing the files will result in structure compare showing one added and one removed class. Probably not what you expect. But if you select the two classes inside the files, structure compare should be available on the classes' members.
Nope - sorry. Doesn't work. I want to compare the 2 classes: - OS2BMPFileFormat - WinBMPFileFormat in package org.eclipse.swt.internal.image, for an idea of how much can be saved by extracting a common superclass. I did the refactoring anyhow, and at each "iteration", I know I can make a small change here, a small change there, and achieve even more savings. However, I would like to use "Compare With -> Each Other" as a tool after each step to make sure I got everything, and to point out new methods that could be restructured and maybe moved up to the new superclass. The current implementation of "Compare With -> Each Other" was basically useless to me as a tool for this refactoring. If it had worked as expected, it would have been a useful tool.
Aha, the name of the action isn't "Compare with Each other" but "Compare with other element" (because you have selected the types "OS2BMPFileFormat" and "WinBMPFileFormat" and not their CUs). And yes, in this case there is no structure compare. Will be fixed for next iBuild.
What is the fix? To add structured compare to "Each Other" or to "Other Element..."? Also, what is the exact difference between "Each Other" and "Other Element..."? The results are semantically identical in this case - I basically end up with a non-structured compare in both cases. Different windows/views show the results, but basically, the results are the same. What is the "..." for in the "Other Element..." case? It did not bring up a dialog or anything, asking me for more info. Should we consider merging these into only one action, so that there is less possibility of confusion for users?
> Also, what is the exact difference between "Each Other" and "Other Element..."? The former works on resources (files), the latter on Java elements. >The results are semantically identical in this case - I basically > end up with a non-structured compare in both cases. No. The former shows structure compare in a non modal editor (and it always compares the CUs even if a Java element within the CU is selected), the latter shows a dialog because it shows only a section of the underlying resources and we do not support editing in this case.. >Different windows/views show the results, but basically, the results are the same. What is the "..." >for in the "Other Element..." case? It did not bring up a dialog or anything, >asking me for more info. "Compare with other element" brings up a modal dialog, hence the "..." > Should we consider merging these into only one > action, so that there is less possibility of confusion for users? Yes indeed, we considered this already years ago. But the problem is that Eclipse doesn't allow this because its plugin architecture follows the "add, not replace" principle. A higher level cannot replace functionality of a lower level. The "Compare with each other" is provided by platform.compare, "Compare with element" by jdt.ui. jdt.ui has no way to disable the "Compare with each other" action. In addition the ResourceAdapter architecture automatically makes the "Compare with Each Other" action available even on Java elements below CUs (where we already have the "Compare with element" actions). And if we would disable the ResourceAdapter, we would have no Compare action at all on CUs, because they are neither resources nor Java elements.
Created attachment 15766 [details] Compare with Each Other Result of selecting the *types* - not CUs - OS2BMPFileFormat and WinBMPFileFormat and performing a "Compare With Each Other"
Created attachment 15767 [details] Compare With other Element Result of selecting the *types* - not CUs - OS2BMPFileFormat and WinBMPFileFormat and performing a "Compare With Other Element"
Actually, I don't call the results in comment 8 a "structured compare". There are no methods listed. It's not very useful that way. The extra pane (view/whatever) that has the title "Structured Compare" only has a + and - with a picture of the class icons. This does not provide any additional information that was not already obvious. What I want to see is the methods that are different. In these 2 classes, there are methods that are different, and methods that are identical, and some methods that are almost-identical. If I had a real structured compare, then it would help me to refactor these 2 classes to extract a superclass. As for the eclipse "add, not replace", is that really true? Wow. That seems overly restrictive. Is there a reason? Is replace "too hard" to enable? Seems to me that, sure, it might involve a bit more work to get the framework right, but surely eclipse could allow plugins to provide "extension points" and "refinement points"?
Sorry, but comment #8 shows a structured compare. It is not what you expect and it provides no additional information to you because it was performed on *CUs* and not on the *classes*. The CU contains types that have different names, so they are not matched against each other and hence appear as a addition and a deletion (this is exactly the behavior you expect on the method level). Yes, I could automatically try to match the types inside the CUs even if they don't have matching names. This would work in this case if there is only one type per CU, but it would fail if there is more than one type contained in the CU. In order to get "useful structure compare" you have to do a "Compare with other element" on the *types*. This is shown in comment #9. I've already admitted that here the structure compare pane is missing (this is the bug of this PR), and I've already said that I'll try to fix this for the next iBuild. It will exactly do what you describe. Yes there is a reason for the "add, not replace" principle. You find an excellent description on page 24 of Erich&Kent's book "Contributing to Eclipse", there it is called the "Sharing Rule".
Sorry, Andre. I didn't understand what the fix was that you mentioned. I get it now. Thanks!
Um, I know it doesn't really matter, but the compare in comment 8 *was* done on classes (not CUs). Maybe it would be a feature request to ask for a class- level structured compare (showing methods) in this case? (i.e. when 2 classes with different names are selected, and user selects compare with each other)?
>Um, I know it doesn't really matter, but the compare in comment 8 *was* done >on classes (not CUs). Yes, that's a consequence of Eclipse's "object contribution mechanism" and "resource adapters": "Compare with Each other" is contributed on IResources. CUs (and all nested JavaElements) are not IResources, but they can "adapt" to IResources. So "Compare with Each other" is available on all JavaElements, but does not work as expected because it always gets the same IResource for all JavaElements, and performs the structure compare on the IResource (that is the full CU). That's the reason why JavaCompare contributes a different "Compare with other element" on JavaElements only: it only sees the selected elements (and does not "adapt" to the underlying resource). But I'm in violent agreement with your feature request!
I looked up the Sharing Rule in "Contributing", and I was disappointed, because it doesn't say *why* we only allow adding. It just says "this is the way it is". I wonder how hard it would be to implement (and describe) "refinement points" in eclipse. <g> Anyhow, could we handle "Compare With->Each Other" the same way that "Move" and "Rename" appear to have been implemented? In the Navigator, they do one thing, and in the Package Explorer, they do another. (Or maybe the difference is Resource Perspective vs. Java Perspective or something). Anyhow, it would be nice to eliminate the confusing "Compare With->Other Element..." somehow. I think "Compare With->Each Other" is the more intuitive wording.
Allowing "replace" contributions opens the door to replace fundamental behavior and potentially break the system with a single contribution. Allowing only "add" ensures that the platform must deal with *multiple" (alternative) contributions and a way to choose among them. Please let Erich know that he didn't explain the "Sharing rule" :-) "Move" and "Rename" were promoted to "global actions" which are retargetable. Their existence is hardcoded in platform.ui. I don't think that "Compare" deserves the same privilege... But I'll try.
Actually, I think we could make a good case for promoting Compare. There are so many ways of comparing things, and plugins operate on the same types of resources in different ways. Perhaps plugin A wants to compare 2 bitmaps graphically, and plugin B wants to compare the bits that have changed. (And plugin C wants both <g>). The simple case of a .java file is a very obvious one: if you look at it one way, it's just another text file, but if you look at it from a java perspective, it's a container with multiple, hierarchical parts. There are examples of this everywhere. How about an .rtf file - is it just text, is it rich text, or does it represent a Word document? Different plugins would want to compare 2 of them in very different ways. And how many different ways can you look at an .html or .xml file? Zillions. I can even imagine a plugin that might want to let the user visually compare the same .html file with 2 different .dtd's applied. Shall we open a bug report to look into this, or did you want to discuss it with someone first?
Main confusion here is that clients expect "Compare With Each Other" to do comparison on the selection and not on the parent/CU. "Compare With Other Element" seems not too intuitive - I would expect a dialog allowing me to select the other element.
Filed bug 272291 for the naming problem.
Hello, is there anything planned here? Comparing sources or part of source is a very helpful refactoring tool. I also lack the normal Compare view feature (i.e. editing and moving differences from one side to the other) in the Compare Elements popup. I would suggest to promote the "Compare Java Elements" popup to a real Compare Editor with all its nice features: * Structure compare * White space ignore (toggeable) * Editing * Merging / moving changes Should this get a separate issue?
(In reply to comment #20) > Hello, is there anything planned here? No. I'm tentatively targeting it for 4.4. > I also lack the normal Compare view feature (i.e. editing and moving > differences from one side to the other) in the Compare Elements popup. > > I would suggest to promote the "Compare Java Elements" popup to a real > Compare Editor with all its nice features: > * Structure compare > * White space ignore (toggeable) > * Editing > * Merging / moving changes > > Should this get a separate issue? No. This would be available if a structured compare editor would be used.
(In reply to comment #21) > (In reply to comment #20) > > Hello, is there anything planned here? > > No. I'm tentatively targeting it for 4.4. That's a pity. E.g. compare with element from local history seems to use the structured compare editor. To me this does not look like a big difference. Is it really a big deal? Thanks, Jörg
Anybody working on this now?
(In reply to Jörg Thönnes from comment #23) > Anybody working on this now? No.
