tag:blogger.com,1999:blog-47857383955961610432024-03-13T23:01:47.082+01:00Mati@GSOCThis blog is dedicated to my work on Google Summer of Code projects: the "toString() generation" project from 2008 and more recent "Tree views for Zest". Both projects are done for Eclipse.Mateusz Matelahttp://www.blogger.com/profile/07838615634557567581noreply@blogger.comBlogger11125tag:blogger.com,1999:blog-4785738395596161043.post-24223307588517420392015-06-13T01:26:00.001+02:002017-12-12T23:00:59.121+01:00Eclipse Mars - how to switch back to previous Java formatter?<b>Update: <a href="https://github.com/alostale/luna-java-formatter">the Luna formatter plugin now lives on GitHub</a>, thanks to Asier Lostalé!</b>
<br />
<br />
Java code formatter in Eclipse 4.5 has been <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=303519">completely rewritten</a>. There's a lot less of bugs, the behavior is more consistent, and line wrapping is a bit smarter. It also opens way to easier implementation of new improvements in the future.
<br />
While most users will probably be happy with the new formatter, for some the changes may be unwelcome. Probably the most controversial change is a <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=372801">more restrictive approach</a> to the "Never join already wrapped lines" option - a lot of line breaks that used to be tolerated by the old formatter, will be now removed if they don't fit the line wrapping settings. Also, some teams just don't want to force everyone to immediately switch to the newest Eclipse, so during the transition it would be problematic if part of the team used different formatter.
<br />
If you also find that problems related to changed formatter behavior outweigh the benefits of bug fixes and improvements, you'll be glad to hear that Eclipse Mars has a new extension point for Java formatter. So it's easy to take the code of the old formatter and wrap it in a plugin. I did just that for your convenience, the plugin can be downloaded <a href="https://wiki.eclipse.org/images/4/45/OldJavaFormatter.zip">here</a>. Although I tested it a bit, the plugin is provided "as is" and I take no responsibility for anything that happens because of it. Just unzip the provided jar into the "plugins" directory of your Eclipse installation, restart, and in the Preferences -> Code Style -> Formatter page select Formatter implementation: Old formatter. Happy formatting!
Mateusz Matelahttp://www.blogger.com/profile/07838615634557567581noreply@blogger.com69tag:blogger.com,1999:blog-4785738395596161043.post-66561719986022987792009-09-23T22:27:00.002+02:002009-09-23T23:16:21.291+02:00New plug-in: scrolling with middle buttonMy favorite way to scroll site contents in internet browsers is to press middle mouse button and slightly move mouse up or down. It's usually more convenient than rotating mouse wheel or grabbing scrollbar. This feature is supported by every popular browser but it's also being added to other applications (even the primitive Notepad in Windows has it!). I got used to it so much that I really miss it in Eclipse.<br /><br />So I've done a little investigation to check whether it would be possible to add such a feature to Eclipse workbench. It turns out it would be very hard to do, as there's no general API in SWT to programmatically invoke scrolling. Only limited number of custom widgets provide methods that can do it. Fortunately, StyledText which is used by all text editors in Eclipse is one of them. This allowed me to prepare a plug-in that adds MMB scrolling at least to text editors. It's not much, but better than nothing. If you're interested, please visit the <a href="http://code.google.com/p/eclipse-mmb-scroller/">project page</a> or go directly for <a href="http://eclipse-mmb-scroller.googlecode.com/files/eclipse-mmb-scroller_1.0.2.zip">download</a>.<br /><br />I'll be trying to hack other popular editors and viewers, so the list of scrollable elements may get longer in next versions. If you know something that may be useful for this task, please let me know :)Mateusz Matelahttp://www.blogger.com/profile/07838615634557567581noreply@blogger.com5tag:blogger.com,1999:blog-4785738395596161043.post-58347871396905168432008-08-21T16:28:00.002+02:002008-08-21T16:36:56.823+02:00ToString() Generator Plug-inYou don't have to wait for Eclipse 3.5 to conveniently generate toString() method for any class. Here's a <a href="http://wiki.eclipse.org/images/2/24/Org.gsoc.eclipse.tostringgenerator_1.0.0.zip">plug-in version</a>, tested with Eclipse 3.2, 3.3 and 3.4.<br />Enjoy!Mateusz Matelahttp://www.blogger.com/profile/07838615634557567581noreply@blogger.com3tag:blogger.com,1999:blog-4785738395596161043.post-78473651099601262172008-08-08T12:08:00.003+02:002008-08-08T12:47:31.948+02:00ToString() generator status updateSince my last post I've been working mainly on user documentation and jUnit tests. I managed to create an extension point for my generator. It lets you change not only the look of generated code, but also the way the templates are handled (so you can for example add your own tokens). I also tried to add toString() generation to code completion proposals, but there are some problems I can't solve right now. This and the fact that JDT guys are rather skeptic about this feature made me postpone the work on it.<br /><br />So the project is now finished and waiting to be reviewed by JDT team. I can't wait for the results. If everything goes fine, it will be added to Eclipse 3.5. Meanwhile, as I have nothing better to work on (and official end of GSoC is August 18th), I'll try to make the generator a separate plugin so that it can be used with earlier versions of Eclipse.Mateusz Matelahttp://www.blogger.com/profile/07838615634557567581noreply@blogger.com0tag:blogger.com,1999:blog-4785738395596161043.post-77323627273908650982008-07-17T13:17:00.004+02:002008-07-18T00:50:16.867+02:00all bout toStringGSoC midterm evaluation is now behind us so I think it's a good occasion to sum up my progress. I want to describe what is already working and what I'm going to add. I hope this post will be also a good start for creating user documentation.<br /><ol type="I"><br /><li><h2>Code styles</h2><br />Code style determines how the generated method works and what classes it uses. There are several code styles available to chose from the combo box in generator's dialog. <br /><ul><br /><li><h3>String concatenation</h3><br />This style uses simple sum expressions so it's very efficient and relatively easy to read and modify. Here's an example outcome in the simplest case:<br /><pre>return "FooClass [aFloat=" + aFloat + ", aString=" + aString + ", anInt=" + anInt <br /> + ", anObject=" + anObject + "]";</pre><br />With "Skip null values" option turned on, the code becomes a little harder to read:<br /><pre>return "FooClass [aFloat=" + aFloat + ", "<br /> + (aString != null ? "aString=" + aString + ", " : "") <br /> + "anInt=" + anInt + ", " <br /> + (anObject != null ? "anObject=" + anObject : "") + "]";</pre><br /></li><br /><li><h3>StringBuilder/StringBuffer</h3><br />This style uses StringBuilder if project is compatible with JDK1.5 or later and StringBuffer otherwise.<br /><pre>StringBuilder builder = new StringBuilder();<br />builder.append("FooClass [aFloat=");<br />builder.append(aFloat);<br />builder.append(", aString=");<br />builder.append(aString);<br />builder.append(", anInt=");<br />builder.append(anInt);<br />builder.append(", anObject=");<br />builder.append(anObject);<br />return builder.toString();</pre><br />The <b>"Skip null values"</b> option doesn't obfuscate the code as much as previously:<br /><pre>StringBuilder builder = new StringBuilder();<br />builder.append("FooClass [aFloat=");<br />builder.append(aFloat);<br />builder.append(", ");<br />if (aString != null) {<br /> builder.append("aString=");<br /> builder.append(aString);<br /> builder.append(", ");<br />}<br />builder.append("anInt=");<br />builder.append(anInt);<br />builder.append(", ");<br />if (anObject != null) {<br /> builder.append("anObject=");<br /> builder.append(anObject);<br />}<br />return builder.toString();</pre><br /></li><br /><li><h3>String.format();</h3><br />This style is very pleasant with relatively short list of elements, but with longer ones it becomes hard to see which fields are associated with which variables. Unfortunately, the <b>"Skip null values"</b> option is ignored by this style.<br /><pre>return String.format("FooClass [aFloat=%s, aString=%s, anInt=%s, anObject=%s]",<br /> aFloat, aString, anInt, anObject);</pre><br />For JDK1.4 and earlier, the code is slightly different:<br />UPDATE: As I learned today, there's no <code>String.format()</code> in JDK 1.4, so <code>MessageFormat.format()</code> will be used instead:<br /><pre>return MessageFormat.format("FooClass [aFloat={1}, aString={2}, anInt={3}, anObject={4}]", <br /> new Object[] { Float.valueOf(aFloat), aString, Integer.valueOf(anInt), anObject });</pre><br /></li><br /><li><h3>Apache Commons-Lang ToStringBuilder</h3><br />When this style is chosen, format template is ignored because ToStringBuilder takes care the output string's format itself. Maybe it's a little less flexible, but the power of this solution is that you can easily change the style of all toStrings within the project without changing any actual object's toString method.<br /><pre>ToStringBuilder builder = new ToStringBuilder(this);<br />builder.append("aFloat", aFloat);<br />builder.append("aString", aString);<br />builder.append("anInt", anInt);<br />builder.append("anObject", anObject);<br />return builder.toString();</pre><br />Skipping nulls works this way:<br /><pre>ToStringBuilder builder = new ToStringBuilder(this);<br />builder.append("aFloat", aFloat);<br />if (aString != null)<br /> builder.append("aString", aString);<br />builder.append("anInt", anInt);<br />if (anObject != null)<br /> builder.append("anObject", anObject);<br />return builder.toString();</pre><br /></li><br /><li><h3>Spring Framework's ToStringCreator</h3><br />This style behaves the same as Apache ToStringCreator except it uses different class to create output string.<br /></li><br /></ul><br /><li><h2>Format templates</h2><br />This is a simple mechanism that allows you to change format of generated method's output string: beginning, ending, separator, and so on. There are four tokens to use:<br /><table><br /><tr><td><b>${class.name}</b></td><td>inserts the class name as a String</td></tr><br /><tr><td><b>${member.name}</b></td><td>inserts a member's name</td></tr><br /><tr><td><b>${member.value}</b></td><td>inserts a member's value</td></tr><br /><tr><td><b>${otherMethods}</b></td><td>this token must stand between the separator and the ending string</td></tr></table><br />This is the template used for all examples in the previous part of this post:<br /><pre>${class.name} [${member.name}=${member.value}, ${otherMembers}]</pre><br />And of course, output string for this template looks like this:<br /><pre>FooClass[aFloat=1.0, aString=hello, anInt=10, anObject=null]</pre><br /></li><br />I plan to define more tokens:<ul><br /><li>inserting super.toString() and hashCode() (now they can be printed the same way as other methods which is not convenient)</li><br /><li><b>${class.getName}</b> to use <code>this.getClass.getName()</code> instead of plain string</li><br /><li>two different tokens for printing method names with or without parenthesis at the end</li><br /><li>I'm thinking about more type specific options, e. g. putting strings between quotation-marks, printing integers as hexadecimal, printing length of arrays and so on. But don't know how they should work...</li><br /></ul><br /></li><br /><li><h2>Arrays handling</h2><br />When <b>"Ignore arrays' default toString()"</b> option is switched on, generated toString() method lists items contained in arrays, for example<br /><pre>intArray = [1, 2, 3, 5, 8, 13]</pre> instead of <pre>intArray = [I@9304b1</pre><br />This is realized differently according to chosen JDK compatibility. For JDK1.5 and later <code>java.util.Arrays.toString()</code> is used. For earlier versions, which do not have this method, a helper <code>arrayToString()</code> method is generated:<br /><pre>private String arrayToString(Object array, int length) {<br /> StringBuffer stringBuffer = new StringBuffer();<br /> stringBuffer.append("[");<br /> for (int i = 0; i < length; i++) {<br /> if (i > 0)<br /> stringBuffer.append(", ");<br /> if (array instanceof Object[])<br /> stringBuffer.append(((Object[]) array)[i]);<br /> if (array instanceof float[])<br /> stringBuffer.append(((float[]) array)[i]);<br /> if (array instanceof int[])<br /> stringBuffer.append(((int[]) array)[i]);<br /> }<br /> stringBuffer.append("]");<br /> return stringBuffer.toString();<br />}</pre><br />It takes object as a parameter and then uses <code>instanceof</code> so that one method can work for all kinds of arrays. It checks only these array types that are actually passed to it in the main toString() method, so in case new types are added, <code>arrayToString</code> is regenerated every time toString generator is run.<br /></li><br /><li><h2>Limiting number of items</h2><br />This option changes behavior of generated toString in case of Collections, Maps and Arrays(if <b>"Ignore default arrays' toString()"</b> option is on). Again, generated code differs for each JDK version.<br /><br />In JDK1.6 collection or map is turned into an array (<code>collection.toArray()</code> or <code>map.entrySet().toArray()</code>), then <code>Arrays.copyOf()</code> is used to make it shorter and <code>Arrays.toString()</code> is called to print it out. Of course, usually it's also necessary to check for nulls. All in all, the code becomes fairly complicated, with something like this in the worst case:<br /><pre>builder.append(hashMap != null ? Arrays.toString(Arrays.copyOf(hashMap.entrySet().toArray(),<br /> Math.min(maxItem, hashMap.size()))) : null);</pre><br />At least there's no need to generate additional methods.<br /><br />Since <code>Arrays.copyOf</code> was introduced in JDK1.6, in earlier versions helper toString() methods must be used to limit number of elements. In case of arrays the method is similar to the one showed in the previous part, only with one more statement at the beginning: <code>length = Math.min(lenght, maxItem);</code>. For collections and maps there's another method:<br /><pre>private String toString(Collection<?> collection) {<br /> StringBuilder stringBuilder = new StringBuilder();<br /> final int maxItem = 10;<br /> stringBuilder.append("[");<br /> int i = 0;<br /> for (Iterator<?> iterator = collection.iterator();<br /> iterator.hasNext() && i < maxItem; i++) {<br /> if (i > 0)<br /> stringBuilder.append(", ");<br /> stringBuilder.append(iterator.next());<br /> }<br /> stringBuilder.append("]");<br /> return stringBuilder.toString();<br /><br />}</pre><br />This method is not overwritten every time the generator runs so that it can be changed by user.<br /><br />Another solution would be to convert a collection into an array and then use <code>arrayToString</code>, but this way is more efficient and looks better if there are no arrays.<br /></li><br /><li><h3>Plans for the future</h3><br />In addition to things I mentioned earlier, I'm going to create an extension point for new code styles and add toString generation to code assist. This time I won't be able to copy solutions from hashCode/equals generator though, so the work may not go as smooth as earlier. Still, I don't loose my optimism :)</li><br /></ol>Mateusz Matelahttp://www.blogger.com/profile/07838615634557567581noreply@blogger.com13tag:blogger.com,1999:blog-4785738395596161043.post-75921791719177743712008-07-07T17:04:00.002+02:002008-07-07T17:39:13.413+02:00generator ready to useThe toString() generator reached the state where it can be useful. For now there's only one coding style - string concatenation, but I plan add more of them. There's support for templates and all the options visible in the dialog have effect on generated method. I'd love to hear opinions from people interested in the subject: are the options useful? are the generated methods well implemented? should something be added? should the templates mechanism be enriched?<br /><br />Again, to see my work you can apply the latest patch from <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=26070">bug 26070</a> to the org.eclipse.jdt.ui plugin. I'm sorry if it's inconvenient but I use some internal Eclipse packages and creating a separate plugin would be too difficult for me. If you like, you can download a ready project, import it to Eclipse workspace and run as "Eclipse Application". Here's the <a href="http://www.speedyshare.com/674601783.html">project working under Eclipse 3.4</a> and here <a href="http://www.speedyshare.com/658908889.html">version for Eclipse 3.5.</a>Mateusz Matelahttp://www.blogger.com/profile/07838615634557567581noreply@blogger.com1tag:blogger.com,1999:blog-4785738395596161043.post-53146961197040297562008-06-21T14:08:00.006+02:002008-06-21T21:24:17.339+02:00toString() generator will be in a separate dialogLast week I did some work to make my code clean enough to post on Bugzilla. When I submitted it, Martin suggested that it's not a good idea to have <code>toString()</code> generator in the same dialog with <code>hashCode()</code>/<code>equals()</code>. I was surprised at first, as he was the first person to tell me so. But his arguments were strong: the dialog is too big and there's no good name for the action. His main argument was that hashCode/equals doesn't usually use the same fields as toString. I had doubts about it but I don't have enough experience to argue. <br />I've made a quick poll about it on the eclipse IRC channel - 100% of participants said that toString generation should not be combined with hashCode/equals (100% of 1 person - I guess IRC is not a good place for polls :P)<br />I tried to fit elements on the dialog to make it look better, but without satisfactory results (see <a href="http://www.imagebin.eu/pics/f0980d11f6fe32895676234a9f1846ce.png">here</a> and <a href="http://www.imagebin.eu/pics/a9e7d87c35345f265ad7bf235f6a6de8.png">here</a>). So I decided to make a separate action and I won't get back to the previous idea unless there's *a lot* of people asking for it. I submitted a <a href="https://bugs.eclipse.org/bugs/attachment.cgi?id=105578&action=edit">patch</a> with the new action today and I'm waiting for feedback. If you're too lazy to check the patch, here's a screenshot of prepared dialog:<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_CvApWQQvclQ/SFz1JSTtYRI/AAAAAAAAAAU/58V_73WY1Ek/s1600-h/toString()+GUI.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="http://1.bp.blogspot.com/_CvApWQQvclQ/SFz1JSTtYRI/AAAAAAAAAAU/58V_73WY1Ek/s200/toString()+GUI.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5214312008470323474" /></a><br />Plan for the next week: investigate possible ways of template handling. I know there's a rich template support in Eclipse but I'm afraid it may not be exactly what I need as these templates relate to the code directly. I saw a nice dialog with templates in Mylyn plugin (Preferences->Mylyn->Team) and I'm going to see how it's done. Do you have any suggestions of where else I should look?Mateusz Matelahttp://www.blogger.com/profile/07838615634557567581noreply@blogger.com4tag:blogger.com,1999:blog-4785738395596161043.post-29572916462479954312008-06-08T14:22:00.005+02:002008-06-08T21:53:51.928+02:00First steps...It's the end of the semester here and I must work hard on my grades therefore I can't spend much time on my GSOC project (this situation will last until the last week of june). I managed to do some work this weekend though and here are the results:<br /><br />1. I created a simple toString() generator to see if it will work. And it does :) For now it's only a string concatenationi with hardcoded format. I don't know how to put line breaks in generated code and I have no idea where to look for it. Any clues?<br /><br />2. I decided to start with something simple - redesign hashcode/equals generation dialog to include toString() features. Here's the effect:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_CvApWQQvclQ/SEwQUfdscJI/AAAAAAAAAAM/V3_JTbV_20g/s1600-h/Clipboard04.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="http://4.bp.blogspot.com/_CvApWQQvclQ/SEwQUfdscJI/AAAAAAAAAAM/V3_JTbV_20g/s320/Clipboard04.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5209556813190295698" /></a><br />"Up" and "Down" buttons already work - I copied this functionality from "generate constructor using fields" dialog. The rest of the controls don't have any effect yet..<br />I plan to add a list of class methods to the view (in a separate node of the tree). With all methods on the list, the option to use getters instead of fields accessors is no longer needed (unless we want this option for hashCode and equals, but that's another story).<br /><br />That's all for now, I know it's not much. But I think I can complete the project without many problems if I focus all of my attention on it next month.<br /><br />BTW, Mike, should I put my code somewhere for everybody to see? Right now I modify my local copy of org.eclipse.jdt.ui plugin - is that ok?Mateusz Matelahttp://www.blogger.com/profile/07838615634557567581noreply@blogger.com4tag:blogger.com,1999:blog-4785738395596161043.post-86979943294828717882008-05-23T14:27:00.004+02:002008-05-23T21:48:36.988+02:00toString() with templates? Hmm...<p>As my blog has just joined Planet Eclipse, I'd like to say 'hi' to all the Eclipse fans :) For the next few months you'll probably be hearing from me about automatic <a href="http://wiki.eclipse.org/index.php?title=ToString%28%29_generation">toString() generation</a> feature for Eclipse as this is my project for this year's <a href="http://code.google.com/soc/2008/eclipse/appinfo.html?csaid=78855874A3858904">Google Summer of Code</a>.</p><br /><br /><p>I'd like to start by sharing some dilemmas I have regarding the form of templates support in the generator. At first I wanted to use templates to set the format of the generated string, for example this template would create toString() returning a class name, followed by a comma separated list of values in one line:<br /><pre>${class_name}: ${field_value}, ${other_fields}</pre><br />If every field should be placed in a separate line and have its name printed, the template would look like this:<br /><pre>${class_name} (<br /> ${field_name} = ${field_value}<br /> ${other_fields}<br /> [Super: ${super_string}]<br />)</pre><br />The <code>${super_string}</code> element puts in the call to super.toString(). There could be other elements to call other common methods. The method generated with this template would look like this:<br /><pre>public String toString() {<br /> return "FooClass (\n"<br /> + " field1 = " + field1<br /> + " field2 = " + field2<br /> + " [Super: " + super.toString() + "]\n"<br /> + ")";</pre><br /></p><br /><br /><p>I thought this was fine until Mike Haller suggested that not only the format of generated string is important, but also the style of the implementation itself. Some might want to use string concatenation, others <code>StringBuilder</code> or <code>ToStringCreator</code> from the Spring Framework and so on. I'm still not completely convinced about this - string concatenation is IMO the easiest to read and probably the fastest implementation (java compiler turns '+' into <code>StringBuilder.append()</code>) - then why would someone need something else? But let's assume that multiple style support is necessary. One solution is to hardcode the most common implementations and let the user choose one in the generator's dialog box. But then there will always be unhappy users who need a style that was not implemented.</p><br /><br /><p>The other solution is to use templates to determine the toString() method body itself. This approach is used by <a href="http://eclipse-jutils.sourceforge.net/">JUtils ToString Generator</a>, but it's not very flexible. You cannot change the method behaviour for specific categories of fields, for example to skip null values (comparing primitives to null is an error). Considering this I realized that if there were some additional mechanisms making it more flexible, it would be more than just a toString() generator. It could easily replace almost all source generators currently available in Eclipse - a general purpose code generator useful always when you need to perform similar operations on multiple fields (or methods) of a class!</p><br /><br /><p>My idea to accomplish this is to use two level template-tree. Every node would have attributes determining when it should be used. To show what I mean, I will use an example of hashCode() method. Here, the top level template (marked to use only with fields) would look like this:<br /><pre>public int hashCode() {<br /> final int prime = 31;<br /> int result = 1;<br /> ${hashcode.sub1}<br /> ${hashcode.sub2}<br /> return result;<br />}</pre><br />The subtemplates should be called twice in order to determine if there should be any separator between them (here the separator is just "\n\t"). There will be several children:<br /><ul><br /><li><code>result = prime * result + ((${field_name} == null) ? 0 : ${field_name}.hashCode());</code> (Marked for use with objects)</li><br /><li><code>result = prime * result + ${field_name}; </code> (Marked for use with <code>int</code>s)</li><br /><li><code>result = prime * result + Float.floattoIntBits(${field_name}); </code> (Marked for use with <code>float</code>s)</li><br /><li><code>result = prime * result + (${field_name} ? 1231 : 1237);</code> (Marked for use with <code>boolean</code>s)</li><br /><li>And so on...</li><br /></ul><br />Can you see the potential of this mechanism? :) One more extension is template grouping, which allows to iterate over class fields more than once. Again, let me use an example - generate constructor using fields. Here's the top level template:<br /><pre>public ${class_name}(${arg.sub1}, ${arg.sub2}) {<br /> ${body.sub1}<br /> ${body.sub2}<br />}</pre><br />We have two groups here: the <code>arg</code> group for method arguments with this template:<br /><pre>${field_type} ${field_name}</pre><br />and the <code>body</code> group with this template:<br /><pre>this.${field_name} = ${field_name};</pre><br />This is just a general idea and definitely needs more design, but it looks very promising to me. As this idea is a bit different from what I presented in my GSOC application, I'm not sure if I should implement it. So I have a question to GSOC mentors who voted on my project: would you still vote for me if I presented the idea above? Another question is to people who know more about JDT and generation of the code from templates: is this going to work? I mean - maybe there are some major problems I'm not aware of... Of course, the question to everyone is how do you like the idea and how would you extend it? :)<br /></p><br /><br /><p>If the project turns out to be too hard for a beginning developer like me or mentors won't agree to these changes, I would just implement the modest toString() generator and go for the general generator later. Now I'd like to hear as many opinions as possible :) I'm not sure if comments to this post is a good place for such discussion, but let's start with it. If it should moved somewhere else, please let me know.</p>Mateusz Matelahttp://www.blogger.com/profile/07838615634557567581noreply@blogger.com9tag:blogger.com,1999:blog-4785738395596161043.post-13152996986798171802008-05-21T19:03:00.004+02:002008-05-22T19:51:55.259+02:00Preparing for codingThe start of GSOC coding phase is getting closer and closer, so I started examining and debuging the Eclipse source. I'm beginning to understand how all the code generators work, although not without problems. The most difficult for me is the dialogs part - I would say that a little refactoring should be done here. Anyway, it's just GUI so I think it won't be so hard to handle it. As for the code generation itself, the operations seemed rather clear to me. Also, I'm going to read this <a href="http://www.eclipse.org/articles/article.php?file=Article-JavaCodeManipulation_AST/index.html"> article about abstract syntax tree</a> to get more details.<br /><br />After reading Remy's great article <a href="http://blog.hantsuki.org/2008/03/07/how-to-contribute-to-eclipse-projects/"> How to contribute to Eclipse projects</a> I decided to give it a try and found this bug: <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=203132">203132</a>. It was pretty easy and referred to functionality I was just examining. But still I forgot to clean up some unused strings and had to send the patch three times. Well, at least I'll be more careful next time. Too bad it's too late to make changes in Eclipse 3.4. It would be much more fun if I didn't have to wait so long to see my code in HEAD CVS.Mateusz Matelahttp://www.blogger.com/profile/07838615634557567581noreply@blogger.com2tag:blogger.com,1999:blog-4785738395596161043.post-31853400960999095532008-05-13T16:53:00.004+02:002008-05-13T17:36:02.140+02:00Welcome!In this blog I will be reporting my progress on the <a href="http://wiki.eclipse.org/ToString%28%29_generation">"toString() generation"</a> project for Eclipse, which is part of this year <a href="http://code.google.com/soc/2008">Google Summer of Code</a>.<br /><br />Through this blog my mentors, <a href="http://www.lemmster.de/blog/">Markus Kuppe</a> and <a href="http://www.mhaller.de/">Mike Haller</a>, will know what I'm doing and I hope to get some feedback from the Eclipse community.Mateusz Matelahttp://www.blogger.com/profile/07838615634557567581noreply@blogger.com2