j2s-development Mailing List for Java2Script
Brought to you by:
zhourenjian
Menu
▾
▴
j2s-development — Discussion about developing Java2Script
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(32) |
Jun
(55) |
Jul
(24) |
Aug
(12) |
Sep
(6) |
Oct
(25) |
Nov
(3) |
Dec
(16) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2009 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: john f. l. <jf...@ro...> - 2013-10-14 05:08:50
|
Hello ... I'm more of a potential user than developer. I used to use the jmol java applet, but java applets seem to have been outlawed, so I'm trying to use jsmol ... which the development site says was created with java2script. I don't need to know anything about java2script to use jsmol ... I don't think. But I'm curious. There's at least one other applet that I know of that would be good to convert to javascript, in my opinion, so I thought I'd see if I could do it. I'm no java programmer. I went to the eclipse site and downloaded eclipse 4.3 ... which seems to be the wrong version for j2s, so now I'm downloading 3.6.2, which I hope will work with Java2Script 2.0.0 v20100601 (Eclipse 3.6.*) <http://sourceforge.net/projects/j2s/files/j2s/j2s-2.0.0-20100601/j2s-2.0.0-20100601-eclipse-3.6.zip/download> The dates seem a little old on the j2s side ... but if jmol => jsmol conversion worked I don't suppose that matters. Am I doing this right so far ? Any advice for a novice like myself ? Thanks in advance, and thanks for providing your software ! -- john francis lee 246/3 Moo 22 Thanon Kaew Wai Mueang Chiangrai 57000 Thailand Hi there, NSA 'analysts', in-house and/or contracted. Just reminding you that if you are reading this you are committing a crime, that you are felons mocking the 4th Amendment of our US Constitution ... "The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no warrants shall issue, but upon probable cause, supported by oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized." ... and that someday, really soon I hope, you're going to have to pay for your crimes. You're breaking international laws as well, so if you're thinking of the 'I was only following orders!' 'defense' ... Please see Nuremberg Principle IV ... "The fact that a person acted pursuant to order of his Government or of a superior does not relieve him from responsibility under international law, provided a moral choice was in fact possible to him". ... and start exercising your moral choice. Look upon Thomas Andrews Drake and Edward Snowden as your exemplars and Patron Saints. |
|
From: Ernesto <Con...@vi...> - 2009-01-06 21:25:47
|
For j2s...@li...: Promote your Marketing: - Provide email list as your needs. We can provide the list tailored to your requirements. - Custom built email list and send your email message to the list. * We also provide a server to send emails. We believe we could help your business. Sales Contact Sa...@Ta... T.K Marketing Support This email only for j2s...@li.... Thanks for your time. |
|
From: Zhou R. <zho...@gm...> - 2007-11-17 03:40:46
|
boolean b = false;
/**
* @j2sNative b = true;
*/ {}
if (b) {
A();
} else {
B();
}
Auto refactoring will fail when refactoring codes inside @j2s* annotations.
We always recommend Java codes instead of JavaScript, unless it is a
JavaScript-must task.
About Java2Script HTML/CSS toolkit using XHTMLRender, I would like to know
something more. I am not quite sure about compatibility between XHTMLRender
and modern browsers. Could you please tell us more about your experience of
integrating XHTMLRender inside Java application?
I had some project experiment on using Java2Script with native HTML/CSS. No
Java debug environment. Everything was tested inside browsers. But it was
still acceptable as I were using debug mode, which Java2Script's "Hotspot"
classloader is enabled inside.
For your plugin, if there is no copyright problem and you would like to
share it with us, you can send us a copy. There should be some ideas that
Java2Script can learn from.
On Nov 17, 2007 3:47 AM, < sg...@so...> wrote:
>
> Hi all. Well, this is my first post to this forum. I'm starting to
> play
> with java2script and I think it is a very promising piece of software.
> (excuse me for my bad english)
>
> SWT port to js is great but (imho) is not oriented to the web (big,
> don't take advatage of css styles, ...). So I decided to start
> developing a small toolkit, with a simple visual paradigm that
> supports
> css styles, basic events and layouting and use a 100% java, free xhtml
> renderer ( https://xhtmlrenderer.dev.java.net/ ) so applications can be
> tested in java and the translated to js.
>
> The thing is that i'm using @j2s* java annotations for expressing
> native
> javascript code. My problem is that from a javascript native code I
> want
> to call a java method, and this will create problems when auto
> refactoring the code with eclipse. So my question is if there is a
> java
> annotation for execute a code block A in javascript environment and B
> in
> a java environment. Something that translate the following code
>
> P1
> if(false)
> /** @j2sSOMETHING */
> {
> A
> }
> else {
> B
> }
> P2
>
> to the next javascript code:
>
> P1
> A
> P2
>
> (in java the block A will be never executed).
>
> Well, if there isn't something like that, it would be nice because it
> is
> nice to test web applications first in a jvm, but to use the ide
> refactoring tools too!!)
>
> I hope you can understand my point. Congratulations again for this
> project and for make it opensource.
>
> p/d
> I had investigating about making a java to javascript translator using
> eclipse ' jdt, but, although jdt's ast parser is makes very easy to
> analize a java compile unit, it is hard to create the equivalent
> javascript code. So, when I saw java2script and check that the
> translator works well, i surrender... and now i move on using java2js.
> If you want, only for curiosity, i could send my eclipse plugin with
> this unfinnished translator (i use java annotations for javascript
> native code too!!)
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups
> "Java2Script" group.
> To post to this group, send email to jav...@go...
> To unsubscribe from this group, send email to
> jav...@go...
> For more options, visit this group at
> http://groups.google.com/group/java2script?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>
--
Regards,
Zhou Renjian
|
|
From: Sebastian G. <sg...@mo...> - 2007-11-16 18:55:40
|
Hi all. Well, this is my first post to this forum. I'm starting to play with java2script and I think it is a very promising piece of software. (excuse me for my bad english) SWT port to js is great but (imho) is not oriented to the web (big, don't take advatage of css styles, ...). So I decided to start developing a small toolkit, with a simple visual paradigm that supports css styles, basic events and layouting and use a 100% java, free xhtml renderer (https://xhtmlrenderer.dev.java.net/ ) so applications can be tested in java and the translated to js. The thing is that i'm using @j2s* java annotations for expressing native javascript code. My problem is that from a javascript native code I want to call a java method, and this will create problems when auto refactoring the code with eclipse. So my question is if there is a java annotation for execute a code block A in javascript environment and B in a java environment. Something that translate the following code P1 if(false) /** @j2sSOMETHING */ { A } else { B } P2 to the next javascript code: P1 A P2 (in java the block A will be never executed). Well, if there isn't something like that, it would be nice because it is nice to test web applications first in a jvm, but to use the ide refactoring tools too!!) I hope you can understand my point. Congratulations again for this project and for make it opensource. p/d I had investigating about making a java to javascript translator using eclipse ' jdt, but, although jdt's ast parser is makes very easy to analize a java compile unit, it is hard to create the equivalent javascript code. So, when I saw java2script and check that the translator works well, i surrender... and now i move on using java2js. If you want, only for curiosity, i could send my eclipse plugin with this unfinnished translator (i use java annotations for javascript native code too!!) |
|
From: Fionnghuala M. <ca...@ma...> - 2007-02-16 16:51:33
|
Hi, Save over 50% on your medication http://www.ledrx .com Remove space in the above link any fun at all. However, he nodded politely like the other champions. Very well... if you havent got any questions, well go back up to the castle, shall we, its a bit chilly... |
|
From: Callistus S. <fle...@ta...> - 2007-02-09 13:11:20
|
Hi, Cheap high quality pharmacy directly from the manufacturer, It's time to save your money. http://www.tedr*x.com REMOVE "*" to make the link working. I... however.. He lifted the wand and examined it minutely, turning it over and over before his eyes. |
|
From: Michae B. <gr...@ea...> - 2006-12-21 20:27:58
|
AMB_BlEN $ 2, 90 VAL_LlUM $ 1, 25 VlA_AGRA $ 3, 30 ClA_ALlS $ 3, 75 XAN_NAX $ 1, 50 =20 http://www.rtionkandesungertionplon.com =20 =20 =20 upward with the rest of the crowd, which slowly filtered away through doors into the stands to their left and right. Mr. Weasleys party kept climbing, and at last they reached the top of the staircase and found |
|
From: Ilya W. <cov...@ca...> - 2006-12-08 20:05:43
|
VtAGRA from $ 3. 30 and other goods! http://www.adesuijintungenfungandesuijin.com =20 you will go and sit at the appropriate table. Ackerley, Stewart!=20 A boy walked forward, visibly trembling from head to foot, picked up the |
|
From: Zhou R. <jo...@sj...> - 2006-12-07 11:48:51
|
Hi Ian, When about two days ago, I viewed these videos, and feel appreciated. Some of early Java2Script tutorials are out of date, and these video tutorials are surely new refresh delicious food for Java2Script new visitors. I have already linked these video tutorials in http://j2s.sourceforge.net/document.html I am appreciated that Steven and you guys spent times to record videos about Java2Script. By the way, Soheil, one of our developers, will try to verify and fix the bugs (thanks again for the bugs) shown in the video. Regeards Zhou Renjian Ian Ozsvald wrote: > Hi there. I'm one of the founders of the educational video site, > http://ShowMeDo.com. One of our authors, Steven Devijver, has recorded a > 3-part set on using java2script: > http://showmedo.com/videos/series?name=javaDevijverJ2SSeries > > I'm wondering if you'd like to link to this set? Steven's videos show the > demo on your homepage, using j2s inside Eclipse and then building a full > GUI using SWT which also loads in a browser. These three videos last 44 > minutes in total, they make for a very nice introduction to the power of > j2s. > > I hope that we can send some eager visitors your way after they have seen > these videos, and that the extra interest will offer you further > encouragement as you grow your project. > > I'll give you a quick bit of background: Kyran and I founded ShowMeDo a > year back and we've been growing the site in evenings and weekends since > then. Now we have 99 videos in the site, mostly for programming, and > we're funding ourselves as of January so that we can further grow the > site. We're keen to help people share their hard-won knowledge. Our > videos are hosted for free and we are always interested in talking to new > authors. > > Regards, > Ian Ozsvald. (one of the two founders of ShowMeDo.com) > > ---- > http://ShowMeDo.com > http://blog.ShowMeDo.com > http://forums.ShowMeDo.com > Ia...@Sh... > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > j2s-development mailing list > j2s...@li... > https://lists.sourceforge.net/lists/listinfo/j2s-development > > > |
|
From: Ian O. <ia...@sh...> - 2006-12-06 18:22:41
|
Hi there. I'm one of the founders of the educational video site, http://ShowMeDo.com. One of our authors, Steven Devijver, has recorded a 3-part set on using java2script: http://showmedo.com/videos/series?name=javaDevijverJ2SSeries I'm wondering if you'd like to link to this set? Steven's videos show the demo on your homepage, using j2s inside Eclipse and then building a full GUI using SWT which also loads in a browser. These three videos last 44 minutes in total, they make for a very nice introduction to the power of j2s. I hope that we can send some eager visitors your way after they have seen these videos, and that the extra interest will offer you further encouragement as you grow your project. I'll give you a quick bit of background: Kyran and I founded ShowMeDo a year back and we've been growing the site in evenings and weekends since then. Now we have 99 videos in the site, mostly for programming, and we're funding ourselves as of January so that we can further grow the site. We're keen to help people share their hard-won knowledge. Our videos are hosted for free and we are always interested in talking to new authors. Regards, Ian Ozsvald. (one of the two founders of ShowMeDo.com) ---- http://ShowMeDo.com http://blog.ShowMeDo.com http://forums.ShowMeDo.com Ia...@Sh... |
|
From: Roseanne L. <sti...@ca...> - 2006-12-06 12:35:26
|
Hi, V / a g r a $ 3, 33 V a l / u m $ 1, 21 C / a l / s $ 3, 75 =20 http://www.similartionjerungan.com =20 =20 the buildings stream by, then the outskirts of the city appeared. We |
|
From: Steven D. <ste...@gm...> - 2006-12-04 08:20:17
|
I think that's ok as long as somone who's new to the j2s code can understand that he or she can safely ignore this code. Steven On 12/4/06, Soheil Hassas Yeganeh <soh...@gm...> wrote: > Hi All, > > I think we need those SWT codes, but we should discuss how to keep > them in the HEAD. Zhou said it should remain in the way they do now. > Steven said we should keep it in another branch. > > But I suggest to keep them with a convention. I mean that if we keep > those comments with a meta data (annotation). For example for those > win32 commented codes ( that I think they will really help us > developing SWT ) we should write : > /*WIN32 NATIVE* > * ..... > */ > > /*GTK NATIVE* > ... > */ > > I think marking the codes this way will bring us more productivity > than just diffing the SVN branches. > > Regards, > Soheil > On 12/3/06, Zhou Renjian <jo...@sj...> wrote: > > Hi Steven, > > > > Thanks for you detailed suggestions. > > > > Here is a quick reply: > > > > I think Java2Script SWT's commented codes should stay in sources for > > some more time. I still need them: I need to look at the sources knowing > > the differences of Java2Script SWT and native SWT without comparisons. > > By the way, SVN connection is still considered slow. And using SVN may > > also require diff3. > > > > ASTScriptVisitor is being refactored these days. If you are interested > > in ASTScriptVisitor and would like to help all whole compiler things, > > you can keep update with SVN and give feedbacks about those "Chinese" > > codes. BTW: I am a Chinese, and I can read and write Chinese. So > > feedbacks from English or other languages will be important to me. :) > > Maybe ASTScriptVisitor is not being refactored in your way of > > understanding Java2Script compiler. But at least it will be being > > refactored to a level that is more understandable and extensible. > > > > - code that inspects the Java AST objects > > - code that generates JavaScript. > > > > Good suggestions. I think I am in the direction. > > > > Regards > > > > Steven Devijver wrote: > > > Hey guys, > > > > > > It's good to hear you want to clean up the project. I've used j2s and > > > I think it's a very cool tool with a big potential for the future. You > > > guys have done a lot of great work and it would be a shame to see it > > > go to waste. > > > > > > About the win32 code that's commented out: I understand you want to > > > keep these comments around for reference. However, they cannot stay in > > > the HEAD if this code is not going to be actually used. > > > > > > The reason for this is that this commented out code is going to > > > confuse developers that look at the j2s source code like it confused > > > me. There are several options to keep this code around without have to > > > keep it where it is now. > > > > > > The first option is - like I suggested - to create a tag in SVN before > > > you start the cleanup. This way you can easily do a compare in Eclipse > > > between the HEAD and the tag to have a look at the old comments. > > > > > > Another, more flexible approach is to create a branch before the > > > cleanup that you can reference to whenever you want to inspect the > > > code - including the comments - before the cleanup. > > > > > > Whatever you do, you need to somehow mark the current code before the > > > cleanup to compare in case of bugs or mysterious behavior. > > > > > > Regarding what abstractions to use: the way to find them that works > > > best for me is to print out a class like ASTScriptVisitor and mark > > > with color markers the code in this class that does a specific thing. > > > In the case of ASTScriptVisitor you will find at least two types of > > > code: > > > > > > - code that inspects the Java AST objects > > > - code that generates JavaScript. > > > > > > You can mark these distinct patches of code each in its own code, for > > > example yellow for code that works with AST objects and orange for > > > code that generates JavaScript. > > > > > > Once all your code is colored you'll have a much better overview over > > > the different kinds of behavior. Now, the goal is to have not more > > > than one kind of behavior in each class. So inspect AST objects AND > > > generating JavaScript is one kind of behavior too many in > > > ASTScriptVisitor. > > > > > > The goal is to select one behavior that can stay in ASTScriptVisitor - > > > I think inspecting the AST objects is the most sensible choice - and > > > moving the other kinds of behavior each into their own classes. > > > > > > For example, generating Javascript code is a great candidate to move > > > to a separate class because it's such a specific behavior. It will > > > give you a much better view on each kind of behavior and that's the > > > virtue of object-oriented development. You should take advantage of > > > that. > > > > > > Regarding design patterns, you shouldn't worry about that too much. > > > Once you start thinking about abstractions and refactoring you'll > > > automatically end up with Factories and Visitors and Delegates and > > > Adapters. They are pretty natural for object-oriented development. > > > > > > Hope this helps. Now, the task you're about to embark on is not an > > > easy one and it's perfectly normal to not get it right the first time > > > around. So my advice is to check in regularly, even if you know that > > > what you've done is not correct. You can always roll back to a > > > previous version. Just keep your ideas so that you can inspect them at > > > later times. > > > > > > A specific approach that didn't work in one place may be the ideal > > > solution in another. So let SVN become your collective memory, from my > > > experience it will make the job a lot easier. > > > > > > Also, you will need to talk a lot before you start making changes. > > > You're much smarter with 2 or 3 than by yourself. And even if you > > > can't get an agreement on how to continue, you can always decide to > > > give a certain approach that you think might work a try and evaluate > > > it afterwards. There will be a lot of unknowns and the only way to > > > advance is to try and verify the result. > > > > > > Keep the courage, you're guys are doing great. > > > > > > Steven > > > > > > On 12/3/06, Zhou Renjian <jo...@sj...> wrote: > > > > > >> One thing should be mentioned before cleaning up SWT codes: > > >> DO keep all those commented original codes (from Win32 SWT sources. You > > >> may need to compare sources with Win32 SWT sources to known which lines > > >> are Win32 SWT's). As we discussed before, those commented original > > >> sources will help us knowing which API is already implemented and which > > >> is not yet, and they also help us keeping update with SWT 3.2, 3.3. > > >> > > >> All other commented codes can be removed. And new added or modified > > >> methods and fields (including modifying from "default" to "protected" or > > >> "public") should be commented. > > >> > > >> In my opinions, there are no standards to audit cleaning-up. If the > > >> sources with some comments and documents can be well understood by other > > >> developers in one or several days, it would be OK. In order to achieve > > >> such a goal, maybe refactoring codes according to some well-known design > > >> patterns will help a lot. > > >> > > >> Regards > > >> > > >> Soheil Hassas Yeganeh wrote: > > >> > > >>> Hi All, > > >>> > > >>> I think we should do clean up for all of our projects. As Zhou is > > >>> starting to clean up j2s core , I will start cleaning up the SWT & > > >>> Java Core projects. > > >>> But I think there remains a problem. How should we audit the clean up > > >>> itself ? Is it any pattern or practice that would help us cleaning the > > >>> projects ? What is a good clean up ? > > >>> > > >>> Regards, > > >>> Soheil > > >>> > > >>> On 12/2/06, Zhou Renjian <jo...@sj...> wrote: > > >>> > > >>> > > >>>> Hi Steven, > > >>>> > > >>>> Thanks a lot for pointing out the nasty things! Thanks your advices. > > >>>> > > >>>> It was my bad coding habit that made ASTScriptVisitor a mess. And this > > >>>> habit also affected other classes. And I will spend coming days to clean > > >>>> up those codes and add documents about ASTScriptVisitor and inner > > >>>> JavaScript simulator mechanics. > > >>>> > > >>>> If there are other problems about the existed codes (Sure, there are > > >>>> lots of nasty codes), please feel easy to post comments to point them > > >>>> out. And I will try my best to clean things up. > > >>>> > > >>>> Thanks. > > >>>> > > >>>> Regards, > > >>>> Zhou Renjian > > >>>> > > >>>> Steven Devijver wrote: > > >>>> > > >>>> > > >>>>> All, > > >>>>> > > >>>>> I was planning to write my own ASTVisitor extension for j2s. The best > > >>>>> way to get started for me seemed to look at the existing visitor > > >>>>> classes. Thanks to the tutorial here > > >>>>> http://j2s.sourceforge.net/articles/tutorial-extended-compiler.html it > > >>>>> was easy to find the right class to look at: ASTScriptVisitor. > > >>>>> > > >>>>> Sadly I soon found out this class is in decay. It's a whooping 3430 > > >>>>> lines long (that's about 3000 lines in excess) and my guess is that > > >>>>> about one in every 5 lines of code is commented out. As if this is not > > >>>>> bad enough it gets worse. > > >>>>> > > >>>>> There are many very very deeply nested code blocks that make this > > >>>>> class literally Chinese to anyone who wants to get to understand it. > > >>>>> In fact, although I have quite some experience in performing code > > >>>>> reviews I've never seen any class as poorly written as > > >>>>> ASTScriptVisitor. And mind you, this is the first and only class I > > >>>>> looked at in the entire j2s code base. > > >>>>> > > >>>>> Now, you may think I'm ranting. Consider this. I've selected one > > >>>>> deeply nested code block out of many. This is its level of nesting. > > >>>>> This code block that starts on line 2234 in ASTScriptVisitor is nested > > >>>>> in: > > >>>>> > > >>>>> an else block in a while loop in an if block in an if block in an if > > >>>>> block in an else block in an if block in an else block in a while loop > > >>>>> in an if block in an if block in an if block in an else block in an > > >>>>> else block in an if block in a method body. > > >>>>> > > >>>>> That's 16 (!!!) levels of nesting without encapsulation!!! And again, > > >>>>> this is one example in a huge class in a big project. > > >>>>> > > >>>>> My recommendations are simple: > > >>>>> > > >>>>> - check in everything and create a tag in SVN today. > > >>>>> - stop adding new features today so that the project is frozen. Don't > > >>>>> add any new feature before the cleanup is complete. > > >>>>> - in every class of the project, remove all code that is commented > > >>>>> out. The only comments that are allowed are real comments in english, > > >>>>> no code. Start with the classes that have the most lines and continues > > >>>>> until you have checked every class in the codebase. > > >>>>> - test all features of your project and make sure your code works as > > >>>>> expected. Document exactly how you've tested every part of your code > > >>>>> base. Create an issue for every bug you come across that's likely > > >>>>> related to code that has been commented out. > > >>>>> - at this point, stop making any modifications to your code base. > > >>>>> - get together with all developers - either online to in real life - > > >>>>> and start discussing the state of the code base. Start with the > > >>>>> classes that have the most lines (the number of lines need to be > > >>>>> recounted after all commented out code has been removed). Discuss why > > >>>>> each class is as long as it is. Try to find out why these classes are > > >>>>> so long. Try to come up with abstractions and encapsulations. Create > > >>>>> some prototypes and verify if they are up to the job. If not improve > > >>>>> them or come up with alternatives. If you found something interesting > > >>>>> try it out on your code and see if it can improve the expressiveness > > >>>>> of your code. > > >>>>> - once you've selected a couple of code abstractions DOCUMENT THEM!!! > > >>>>> - now attack your code base and implement the abstractions you''ve > > >>>>> selected. Document each abstraction you implement like: ThisClass, > > >>>>> line x to y, ThisAbstraction, This and That class created. > > >>>>> - Re-test your codebase using the test descriptions you've written > > >>>>> down before. Create an issue for every bug your discover that wasn't > > >>>>> reported before. > > >>>>> - fix the issues that were discovered after adding the abstractions. > > >>>>> - now fix the issues that were discovered after the first test run. > > >>>>> > > >>>>> It will require some time but not more that one or two months. Anyway, > > >>>>> if you don't do exactly as I've described your project is lost beyond > > >>>>> repair and you'd better stop working on it today. > > >>>>> > > >>>>> Hope this helps. If you have any questions please feel free to contact me. > > >>>>> > > >>>>> Steven Devijver > > >>>>> > > >>>>> ------------------------------------------------------------------------- > > >>>>> Take Surveys. Earn Cash. Influence the Future of IT > > >>>>> Join SourceForge.net's Techsay panel and you'll get the chance to share your > > >>>>> opinions on IT & business topics through brief surveys - and earn cash > > >>>>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > >>>>> _______________________________________________ > > >>>>> j2s-development mailing list > > >>>>> j2s...@li... > > >>>>> https://lists.sourceforge.net/lists/listinfo/j2s-development > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>> ------------------------------------------------------------------------- > > >>>> Take Surveys. Earn Cash. Influence the Future of IT > > >>>> Join SourceForge.net's Techsay panel and you'll get the chance to share your > > >>>> opinions on IT & business topics through brief surveys - and earn cash > > >>>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > >>>> _______________________________________________ > > >>>> j2s-development mailing list > > >>>> j2s...@li... > > >>>> https://lists.sourceforge.net/lists/listinfo/j2s-development > > >>>> > > >>>> > > >>>> > > >>> ------------------------------------------------------------------------- > > >>> Take Surveys. Earn Cash. Influence the Future of IT > > >>> Join SourceForge.net's Techsay panel and you'll get the chance to share your > > >>> opinions on IT & business topics through brief surveys - and earn cash > > >>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > >>> _______________________________________________ > > >>> j2s-development mailing list > > >>> j2s...@li... > > >>> https://lists.sourceforge.net/lists/listinfo/j2s-development > > >>> > > >>> > > >>> > > >>> > > >> -- > > >> > > >> Regards, > > >> Zhou Renjian > > >> > > >> http://j2s.sourceforge.net/ > > >> Java2Script: Bridge of RCP to RIA > > >> Reusing Java codes and tools into JavaScript > > >> > > >> ------------------------------------------------------------------------- > > >> Take Surveys. Earn Cash. Influence the Future of IT > > >> Join SourceForge.net's Techsay panel and you'll get the chance to share your > > >> opinions on IT & business topics through brief surveys - and earn cash > > >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > >> _______________________________________________ > > >> j2s-development mailing list > > >> j2s...@li... > > >> https://lists.sourceforge.net/lists/listinfo/j2s-development > > >> > > >> > > >> > > > > > > ------------------------------------------------------------------------- > > > Take Surveys. Earn Cash. Influence the Future of IT > > > Join SourceForge.net's Techsay panel and you'll get the chance to share your > > > opinions on IT & business topics through brief surveys - and earn cash > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > > _______________________________________________ > > > j2s-development mailing list > > > j2s...@li... > > > https://lists.sourceforge.net/lists/listinfo/j2s-development > > > > > > > > > > > > > -- > > > > Regards, > > Zhou Renjian > > > > http://j2s.sourceforge.net/ > > Java2Script: Bridge of RCP to RIA > > Reusing Java codes and tools into JavaScript > > > > ------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share your > > opinions on IT & business topics through brief surveys - and earn cash > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > > j2s-development mailing list > > j2s...@li... > > https://lists.sourceforge.net/lists/listinfo/j2s-development > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > j2s-development mailing list > j2s...@li... > https://lists.sourceforge.net/lists/listinfo/j2s-development > > |
|
From: Soheil H. Y. <soh...@gm...> - 2006-12-04 07:11:04
|
Hi All, I think we need those SWT codes, but we should discuss how to keep them in the HEAD. Zhou said it should remain in the way they do now. Steven said we should keep it in another branch. But I suggest to keep them with a convention. I mean that if we keep those comments with a meta data (annotation). For example for those win32 commented codes ( that I think they will really help us developing SWT ) we should write : /*WIN32 NATIVE* * ..... */ /*GTK NATIVE* ... */ I think marking the codes this way will bring us more productivity than just diffing the SVN branches. Regards, Soheil On 12/3/06, Zhou Renjian <jo...@sj...> wrote: > Hi Steven, > > Thanks for you detailed suggestions. > > Here is a quick reply: > > I think Java2Script SWT's commented codes should stay in sources for > some more time. I still need them: I need to look at the sources knowing > the differences of Java2Script SWT and native SWT without comparisons. > By the way, SVN connection is still considered slow. And using SVN may > also require diff3. > > ASTScriptVisitor is being refactored these days. If you are interested > in ASTScriptVisitor and would like to help all whole compiler things, > you can keep update with SVN and give feedbacks about those "Chinese" > codes. BTW: I am a Chinese, and I can read and write Chinese. So > feedbacks from English or other languages will be important to me. :) > Maybe ASTScriptVisitor is not being refactored in your way of > understanding Java2Script compiler. But at least it will be being > refactored to a level that is more understandable and extensible. > > - code that inspects the Java AST objects > - code that generates JavaScript. > > Good suggestions. I think I am in the direction. > > Regards > > Steven Devijver wrote: > > Hey guys, > > > > It's good to hear you want to clean up the project. I've used j2s and > > I think it's a very cool tool with a big potential for the future. You > > guys have done a lot of great work and it would be a shame to see it > > go to waste. > > > > About the win32 code that's commented out: I understand you want to > > keep these comments around for reference. However, they cannot stay in > > the HEAD if this code is not going to be actually used. > > > > The reason for this is that this commented out code is going to > > confuse developers that look at the j2s source code like it confused > > me. There are several options to keep this code around without have to > > keep it where it is now. > > > > The first option is - like I suggested - to create a tag in SVN before > > you start the cleanup. This way you can easily do a compare in Eclipse > > between the HEAD and the tag to have a look at the old comments. > > > > Another, more flexible approach is to create a branch before the > > cleanup that you can reference to whenever you want to inspect the > > code - including the comments - before the cleanup. > > > > Whatever you do, you need to somehow mark the current code before the > > cleanup to compare in case of bugs or mysterious behavior. > > > > Regarding what abstractions to use: the way to find them that works > > best for me is to print out a class like ASTScriptVisitor and mark > > with color markers the code in this class that does a specific thing. > > In the case of ASTScriptVisitor you will find at least two types of > > code: > > > > - code that inspects the Java AST objects > > - code that generates JavaScript. > > > > You can mark these distinct patches of code each in its own code, for > > example yellow for code that works with AST objects and orange for > > code that generates JavaScript. > > > > Once all your code is colored you'll have a much better overview over > > the different kinds of behavior. Now, the goal is to have not more > > than one kind of behavior in each class. So inspect AST objects AND > > generating JavaScript is one kind of behavior too many in > > ASTScriptVisitor. > > > > The goal is to select one behavior that can stay in ASTScriptVisitor - > > I think inspecting the AST objects is the most sensible choice - and > > moving the other kinds of behavior each into their own classes. > > > > For example, generating Javascript code is a great candidate to move > > to a separate class because it's such a specific behavior. It will > > give you a much better view on each kind of behavior and that's the > > virtue of object-oriented development. You should take advantage of > > that. > > > > Regarding design patterns, you shouldn't worry about that too much. > > Once you start thinking about abstractions and refactoring you'll > > automatically end up with Factories and Visitors and Delegates and > > Adapters. They are pretty natural for object-oriented development. > > > > Hope this helps. Now, the task you're about to embark on is not an > > easy one and it's perfectly normal to not get it right the first time > > around. So my advice is to check in regularly, even if you know that > > what you've done is not correct. You can always roll back to a > > previous version. Just keep your ideas so that you can inspect them at > > later times. > > > > A specific approach that didn't work in one place may be the ideal > > solution in another. So let SVN become your collective memory, from my > > experience it will make the job a lot easier. > > > > Also, you will need to talk a lot before you start making changes. > > You're much smarter with 2 or 3 than by yourself. And even if you > > can't get an agreement on how to continue, you can always decide to > > give a certain approach that you think might work a try and evaluate > > it afterwards. There will be a lot of unknowns and the only way to > > advance is to try and verify the result. > > > > Keep the courage, you're guys are doing great. > > > > Steven > > > > On 12/3/06, Zhou Renjian <jo...@sj...> wrote: > > > >> One thing should be mentioned before cleaning up SWT codes: > >> DO keep all those commented original codes (from Win32 SWT sources. You > >> may need to compare sources with Win32 SWT sources to known which lines > >> are Win32 SWT's). As we discussed before, those commented original > >> sources will help us knowing which API is already implemented and which > >> is not yet, and they also help us keeping update with SWT 3.2, 3.3. > >> > >> All other commented codes can be removed. And new added or modified > >> methods and fields (including modifying from "default" to "protected" or > >> "public") should be commented. > >> > >> In my opinions, there are no standards to audit cleaning-up. If the > >> sources with some comments and documents can be well understood by other > >> developers in one or several days, it would be OK. In order to achieve > >> such a goal, maybe refactoring codes according to some well-known design > >> patterns will help a lot. > >> > >> Regards > >> > >> Soheil Hassas Yeganeh wrote: > >> > >>> Hi All, > >>> > >>> I think we should do clean up for all of our projects. As Zhou is > >>> starting to clean up j2s core , I will start cleaning up the SWT & > >>> Java Core projects. > >>> But I think there remains a problem. How should we audit the clean up > >>> itself ? Is it any pattern or practice that would help us cleaning the > >>> projects ? What is a good clean up ? > >>> > >>> Regards, > >>> Soheil > >>> > >>> On 12/2/06, Zhou Renjian <jo...@sj...> wrote: > >>> > >>> > >>>> Hi Steven, > >>>> > >>>> Thanks a lot for pointing out the nasty things! Thanks your advices. > >>>> > >>>> It was my bad coding habit that made ASTScriptVisitor a mess. And this > >>>> habit also affected other classes. And I will spend coming days to clean > >>>> up those codes and add documents about ASTScriptVisitor and inner > >>>> JavaScript simulator mechanics. > >>>> > >>>> If there are other problems about the existed codes (Sure, there are > >>>> lots of nasty codes), please feel easy to post comments to point them > >>>> out. And I will try my best to clean things up. > >>>> > >>>> Thanks. > >>>> > >>>> Regards, > >>>> Zhou Renjian > >>>> > >>>> Steven Devijver wrote: > >>>> > >>>> > >>>>> All, > >>>>> > >>>>> I was planning to write my own ASTVisitor extension for j2s. The best > >>>>> way to get started for me seemed to look at the existing visitor > >>>>> classes. Thanks to the tutorial here > >>>>> http://j2s.sourceforge.net/articles/tutorial-extended-compiler.html it > >>>>> was easy to find the right class to look at: ASTScriptVisitor. > >>>>> > >>>>> Sadly I soon found out this class is in decay. It's a whooping 3430 > >>>>> lines long (that's about 3000 lines in excess) and my guess is that > >>>>> about one in every 5 lines of code is commented out. As if this is not > >>>>> bad enough it gets worse. > >>>>> > >>>>> There are many very very deeply nested code blocks that make this > >>>>> class literally Chinese to anyone who wants to get to understand it. > >>>>> In fact, although I have quite some experience in performing code > >>>>> reviews I've never seen any class as poorly written as > >>>>> ASTScriptVisitor. And mind you, this is the first and only class I > >>>>> looked at in the entire j2s code base. > >>>>> > >>>>> Now, you may think I'm ranting. Consider this. I've selected one > >>>>> deeply nested code block out of many. This is its level of nesting. > >>>>> This code block that starts on line 2234 in ASTScriptVisitor is nested > >>>>> in: > >>>>> > >>>>> an else block in a while loop in an if block in an if block in an if > >>>>> block in an else block in an if block in an else block in a while loop > >>>>> in an if block in an if block in an if block in an else block in an > >>>>> else block in an if block in a method body. > >>>>> > >>>>> That's 16 (!!!) levels of nesting without encapsulation!!! And again, > >>>>> this is one example in a huge class in a big project. > >>>>> > >>>>> My recommendations are simple: > >>>>> > >>>>> - check in everything and create a tag in SVN today. > >>>>> - stop adding new features today so that the project is frozen. Don't > >>>>> add any new feature before the cleanup is complete. > >>>>> - in every class of the project, remove all code that is commented > >>>>> out. The only comments that are allowed are real comments in english, > >>>>> no code. Start with the classes that have the most lines and continues > >>>>> until you have checked every class in the codebase. > >>>>> - test all features of your project and make sure your code works as > >>>>> expected. Document exactly how you've tested every part of your code > >>>>> base. Create an issue for every bug you come across that's likely > >>>>> related to code that has been commented out. > >>>>> - at this point, stop making any modifications to your code base. > >>>>> - get together with all developers - either online to in real life - > >>>>> and start discussing the state of the code base. Start with the > >>>>> classes that have the most lines (the number of lines need to be > >>>>> recounted after all commented out code has been removed). Discuss why > >>>>> each class is as long as it is. Try to find out why these classes are > >>>>> so long. Try to come up with abstractions and encapsulations. Create > >>>>> some prototypes and verify if they are up to the job. If not improve > >>>>> them or come up with alternatives. If you found something interesting > >>>>> try it out on your code and see if it can improve the expressiveness > >>>>> of your code. > >>>>> - once you've selected a couple of code abstractions DOCUMENT THEM!!! > >>>>> - now attack your code base and implement the abstractions you''ve > >>>>> selected. Document each abstraction you implement like: ThisClass, > >>>>> line x to y, ThisAbstraction, This and That class created. > >>>>> - Re-test your codebase using the test descriptions you've written > >>>>> down before. Create an issue for every bug your discover that wasn't > >>>>> reported before. > >>>>> - fix the issues that were discovered after adding the abstractions. > >>>>> - now fix the issues that were discovered after the first test run. > >>>>> > >>>>> It will require some time but not more that one or two months. Anyway, > >>>>> if you don't do exactly as I've described your project is lost beyond > >>>>> repair and you'd better stop working on it today. > >>>>> > >>>>> Hope this helps. If you have any questions please feel free to contact me. > >>>>> > >>>>> Steven Devijver > >>>>> > >>>>> ------------------------------------------------------------------------- > >>>>> Take Surveys. Earn Cash. Influence the Future of IT > >>>>> Join SourceForge.net's Techsay panel and you'll get the chance to share your > >>>>> opinions on IT & business topics through brief surveys - and earn cash > >>>>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > >>>>> _______________________________________________ > >>>>> j2s-development mailing list > >>>>> j2s...@li... > >>>>> https://lists.sourceforge.net/lists/listinfo/j2s-development > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>> ------------------------------------------------------------------------- > >>>> Take Surveys. Earn Cash. Influence the Future of IT > >>>> Join SourceForge.net's Techsay panel and you'll get the chance to share your > >>>> opinions on IT & business topics through brief surveys - and earn cash > >>>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > >>>> _______________________________________________ > >>>> j2s-development mailing list > >>>> j2s...@li... > >>>> https://lists.sourceforge.net/lists/listinfo/j2s-development > >>>> > >>>> > >>>> > >>> ------------------------------------------------------------------------- > >>> Take Surveys. Earn Cash. Influence the Future of IT > >>> Join SourceForge.net's Techsay panel and you'll get the chance to share your > >>> opinions on IT & business topics through brief surveys - and earn cash > >>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > >>> _______________________________________________ > >>> j2s-development mailing list > >>> j2s...@li... > >>> https://lists.sourceforge.net/lists/listinfo/j2s-development > >>> > >>> > >>> > >>> > >> -- > >> > >> Regards, > >> Zhou Renjian > >> > >> http://j2s.sourceforge.net/ > >> Java2Script: Bridge of RCP to RIA > >> Reusing Java codes and tools into JavaScript > >> > >> ------------------------------------------------------------------------- > >> Take Surveys. Earn Cash. Influence the Future of IT > >> Join SourceForge.net's Techsay panel and you'll get the chance to share your > >> opinions on IT & business topics through brief surveys - and earn cash > >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > >> _______________________________________________ > >> j2s-development mailing list > >> j2s...@li... > >> https://lists.sourceforge.net/lists/listinfo/j2s-development > >> > >> > >> > > > > ------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share your > > opinions on IT & business topics through brief surveys - and earn cash > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > > j2s-development mailing list > > j2s...@li... > > https://lists.sourceforge.net/lists/listinfo/j2s-development > > > > > > > > -- > > Regards, > Zhou Renjian > > http://j2s.sourceforge.net/ > Java2Script: Bridge of RCP to RIA > Reusing Java codes and tools into JavaScript > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > j2s-development mailing list > j2s...@li... > https://lists.sourceforge.net/lists/listinfo/j2s-development > |
|
From: Shelley P. <an...@do...> - 2006-12-04 02:38:08
|
Hi, CHEEAP FHARMACY http://www.werunjintunhdefunhasxun.com =20 of great talent and our lead singer. Lets give her a big hand. |
|
From: Zhou R. <jo...@sj...> - 2006-12-03 18:57:42
|
Hi Steven, Thanks for you detailed suggestions. Here is a quick reply: I think Java2Script SWT's commented codes should stay in sources for some more time. I still need them: I need to look at the sources knowing the differences of Java2Script SWT and native SWT without comparisons. By the way, SVN connection is still considered slow. And using SVN may also require diff3. ASTScriptVisitor is being refactored these days. If you are interested in ASTScriptVisitor and would like to help all whole compiler things, you can keep update with SVN and give feedbacks about those "Chinese" codes. BTW: I am a Chinese, and I can read and write Chinese. So feedbacks from English or other languages will be important to me. :) Maybe ASTScriptVisitor is not being refactored in your way of understanding Java2Script compiler. But at least it will be being refactored to a level that is more understandable and extensible. - code that inspects the Java AST objects - code that generates JavaScript. Good suggestions. I think I am in the direction. Regards Steven Devijver wrote: > Hey guys, > > It's good to hear you want to clean up the project. I've used j2s and > I think it's a very cool tool with a big potential for the future. You > guys have done a lot of great work and it would be a shame to see it > go to waste. > > About the win32 code that's commented out: I understand you want to > keep these comments around for reference. However, they cannot stay in > the HEAD if this code is not going to be actually used. > > The reason for this is that this commented out code is going to > confuse developers that look at the j2s source code like it confused > me. There are several options to keep this code around without have to > keep it where it is now. > > The first option is - like I suggested - to create a tag in SVN before > you start the cleanup. This way you can easily do a compare in Eclipse > between the HEAD and the tag to have a look at the old comments. > > Another, more flexible approach is to create a branch before the > cleanup that you can reference to whenever you want to inspect the > code - including the comments - before the cleanup. > > Whatever you do, you need to somehow mark the current code before the > cleanup to compare in case of bugs or mysterious behavior. > > Regarding what abstractions to use: the way to find them that works > best for me is to print out a class like ASTScriptVisitor and mark > with color markers the code in this class that does a specific thing. > In the case of ASTScriptVisitor you will find at least two types of > code: > > - code that inspects the Java AST objects > - code that generates JavaScript. > > You can mark these distinct patches of code each in its own code, for > example yellow for code that works with AST objects and orange for > code that generates JavaScript. > > Once all your code is colored you'll have a much better overview over > the different kinds of behavior. Now, the goal is to have not more > than one kind of behavior in each class. So inspect AST objects AND > generating JavaScript is one kind of behavior too many in > ASTScriptVisitor. > > The goal is to select one behavior that can stay in ASTScriptVisitor - > I think inspecting the AST objects is the most sensible choice - and > moving the other kinds of behavior each into their own classes. > > For example, generating Javascript code is a great candidate to move > to a separate class because it's such a specific behavior. It will > give you a much better view on each kind of behavior and that's the > virtue of object-oriented development. You should take advantage of > that. > > Regarding design patterns, you shouldn't worry about that too much. > Once you start thinking about abstractions and refactoring you'll > automatically end up with Factories and Visitors and Delegates and > Adapters. They are pretty natural for object-oriented development. > > Hope this helps. Now, the task you're about to embark on is not an > easy one and it's perfectly normal to not get it right the first time > around. So my advice is to check in regularly, even if you know that > what you've done is not correct. You can always roll back to a > previous version. Just keep your ideas so that you can inspect them at > later times. > > A specific approach that didn't work in one place may be the ideal > solution in another. So let SVN become your collective memory, from my > experience it will make the job a lot easier. > > Also, you will need to talk a lot before you start making changes. > You're much smarter with 2 or 3 than by yourself. And even if you > can't get an agreement on how to continue, you can always decide to > give a certain approach that you think might work a try and evaluate > it afterwards. There will be a lot of unknowns and the only way to > advance is to try and verify the result. > > Keep the courage, you're guys are doing great. > > Steven > > On 12/3/06, Zhou Renjian <jo...@sj...> wrote: > >> One thing should be mentioned before cleaning up SWT codes: >> DO keep all those commented original codes (from Win32 SWT sources. You >> may need to compare sources with Win32 SWT sources to known which lines >> are Win32 SWT's). As we discussed before, those commented original >> sources will help us knowing which API is already implemented and which >> is not yet, and they also help us keeping update with SWT 3.2, 3.3. >> >> All other commented codes can be removed. And new added or modified >> methods and fields (including modifying from "default" to "protected" or >> "public") should be commented. >> >> In my opinions, there are no standards to audit cleaning-up. If the >> sources with some comments and documents can be well understood by other >> developers in one or several days, it would be OK. In order to achieve >> such a goal, maybe refactoring codes according to some well-known design >> patterns will help a lot. >> >> Regards >> >> Soheil Hassas Yeganeh wrote: >> >>> Hi All, >>> >>> I think we should do clean up for all of our projects. As Zhou is >>> starting to clean up j2s core , I will start cleaning up the SWT & >>> Java Core projects. >>> But I think there remains a problem. How should we audit the clean up >>> itself ? Is it any pattern or practice that would help us cleaning the >>> projects ? What is a good clean up ? >>> >>> Regards, >>> Soheil >>> >>> On 12/2/06, Zhou Renjian <jo...@sj...> wrote: >>> >>> >>>> Hi Steven, >>>> >>>> Thanks a lot for pointing out the nasty things! Thanks your advices. >>>> >>>> It was my bad coding habit that made ASTScriptVisitor a mess. And this >>>> habit also affected other classes. And I will spend coming days to clean >>>> up those codes and add documents about ASTScriptVisitor and inner >>>> JavaScript simulator mechanics. >>>> >>>> If there are other problems about the existed codes (Sure, there are >>>> lots of nasty codes), please feel easy to post comments to point them >>>> out. And I will try my best to clean things up. >>>> >>>> Thanks. >>>> >>>> Regards, >>>> Zhou Renjian >>>> >>>> Steven Devijver wrote: >>>> >>>> >>>>> All, >>>>> >>>>> I was planning to write my own ASTVisitor extension for j2s. The best >>>>> way to get started for me seemed to look at the existing visitor >>>>> classes. Thanks to the tutorial here >>>>> http://j2s.sourceforge.net/articles/tutorial-extended-compiler.html it >>>>> was easy to find the right class to look at: ASTScriptVisitor. >>>>> >>>>> Sadly I soon found out this class is in decay. It's a whooping 3430 >>>>> lines long (that's about 3000 lines in excess) and my guess is that >>>>> about one in every 5 lines of code is commented out. As if this is not >>>>> bad enough it gets worse. >>>>> >>>>> There are many very very deeply nested code blocks that make this >>>>> class literally Chinese to anyone who wants to get to understand it. >>>>> In fact, although I have quite some experience in performing code >>>>> reviews I've never seen any class as poorly written as >>>>> ASTScriptVisitor. And mind you, this is the first and only class I >>>>> looked at in the entire j2s code base. >>>>> >>>>> Now, you may think I'm ranting. Consider this. I've selected one >>>>> deeply nested code block out of many. This is its level of nesting. >>>>> This code block that starts on line 2234 in ASTScriptVisitor is nested >>>>> in: >>>>> >>>>> an else block in a while loop in an if block in an if block in an if >>>>> block in an else block in an if block in an else block in a while loop >>>>> in an if block in an if block in an if block in an else block in an >>>>> else block in an if block in a method body. >>>>> >>>>> That's 16 (!!!) levels of nesting without encapsulation!!! And again, >>>>> this is one example in a huge class in a big project. >>>>> >>>>> My recommendations are simple: >>>>> >>>>> - check in everything and create a tag in SVN today. >>>>> - stop adding new features today so that the project is frozen. Don't >>>>> add any new feature before the cleanup is complete. >>>>> - in every class of the project, remove all code that is commented >>>>> out. The only comments that are allowed are real comments in english, >>>>> no code. Start with the classes that have the most lines and continues >>>>> until you have checked every class in the codebase. >>>>> - test all features of your project and make sure your code works as >>>>> expected. Document exactly how you've tested every part of your code >>>>> base. Create an issue for every bug you come across that's likely >>>>> related to code that has been commented out. >>>>> - at this point, stop making any modifications to your code base. >>>>> - get together with all developers - either online to in real life - >>>>> and start discussing the state of the code base. Start with the >>>>> classes that have the most lines (the number of lines need to be >>>>> recounted after all commented out code has been removed). Discuss why >>>>> each class is as long as it is. Try to find out why these classes are >>>>> so long. Try to come up with abstractions and encapsulations. Create >>>>> some prototypes and verify if they are up to the job. If not improve >>>>> them or come up with alternatives. If you found something interesting >>>>> try it out on your code and see if it can improve the expressiveness >>>>> of your code. >>>>> - once you've selected a couple of code abstractions DOCUMENT THEM!!! >>>>> - now attack your code base and implement the abstractions you''ve >>>>> selected. Document each abstraction you implement like: ThisClass, >>>>> line x to y, ThisAbstraction, This and That class created. >>>>> - Re-test your codebase using the test descriptions you've written >>>>> down before. Create an issue for every bug your discover that wasn't >>>>> reported before. >>>>> - fix the issues that were discovered after adding the abstractions. >>>>> - now fix the issues that were discovered after the first test run. >>>>> >>>>> It will require some time but not more that one or two months. Anyway, >>>>> if you don't do exactly as I've described your project is lost beyond >>>>> repair and you'd better stop working on it today. >>>>> >>>>> Hope this helps. If you have any questions please feel free to contact me. >>>>> >>>>> Steven Devijver >>>>> >>>>> ------------------------------------------------------------------------- >>>>> Take Surveys. Earn Cash. Influence the Future of IT >>>>> Join SourceForge.net's Techsay panel and you'll get the chance to share your >>>>> opinions on IT & business topics through brief surveys - and earn cash >>>>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >>>>> _______________________________________________ >>>>> j2s-development mailing list >>>>> j2s...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/j2s-development >>>>> >>>>> >>>>> >>>>> >>>>> >>>> ------------------------------------------------------------------------- >>>> Take Surveys. Earn Cash. Influence the Future of IT >>>> Join SourceForge.net's Techsay panel and you'll get the chance to share your >>>> opinions on IT & business topics through brief surveys - and earn cash >>>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >>>> _______________________________________________ >>>> j2s-development mailing list >>>> j2s...@li... >>>> https://lists.sourceforge.net/lists/listinfo/j2s-development >>>> >>>> >>>> >>> ------------------------------------------------------------------------- >>> Take Surveys. Earn Cash. Influence the Future of IT >>> Join SourceForge.net's Techsay panel and you'll get the chance to share your >>> opinions on IT & business topics through brief surveys - and earn cash >>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >>> _______________________________________________ >>> j2s-development mailing list >>> j2s...@li... >>> https://lists.sourceforge.net/lists/listinfo/j2s-development >>> >>> >>> >>> >> -- >> >> Regards, >> Zhou Renjian >> >> http://j2s.sourceforge.net/ >> Java2Script: Bridge of RCP to RIA >> Reusing Java codes and tools into JavaScript >> >> ------------------------------------------------------------------------- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to share your >> opinions on IT & business topics through brief surveys - and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________ >> j2s-development mailing list >> j2s...@li... >> https://lists.sourceforge.net/lists/listinfo/j2s-development >> >> >> > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > j2s-development mailing list > j2s...@li... > https://lists.sourceforge.net/lists/listinfo/j2s-development > > > -- Regards, Zhou Renjian http://j2s.sourceforge.net/ Java2Script: Bridge of RCP to RIA Reusing Java codes and tools into JavaScript |
|
From: Steven D. <ste...@gm...> - 2006-12-03 15:31:19
|
Hey guys, It's good to hear you want to clean up the project. I've used j2s and I think it's a very cool tool with a big potential for the future. You guys have done a lot of great work and it would be a shame to see it go to waste. About the win32 code that's commented out: I understand you want to keep these comments around for reference. However, they cannot stay in the HEAD if this code is not going to be actually used. The reason for this is that this commented out code is going to confuse developers that look at the j2s source code like it confused me. There are several options to keep this code around without have to keep it where it is now. The first option is - like I suggested - to create a tag in SVN before you start the cleanup. This way you can easily do a compare in Eclipse between the HEAD and the tag to have a look at the old comments. Another, more flexible approach is to create a branch before the cleanup that you can reference to whenever you want to inspect the code - including the comments - before the cleanup. Whatever you do, you need to somehow mark the current code before the cleanup to compare in case of bugs or mysterious behavior. Regarding what abstractions to use: the way to find them that works best for me is to print out a class like ASTScriptVisitor and mark with color markers the code in this class that does a specific thing. In the case of ASTScriptVisitor you will find at least two types of code: - code that inspects the Java AST objects - code that generates JavaScript. You can mark these distinct patches of code each in its own code, for example yellow for code that works with AST objects and orange for code that generates JavaScript. Once all your code is colored you'll have a much better overview over the different kinds of behavior. Now, the goal is to have not more than one kind of behavior in each class. So inspect AST objects AND generating JavaScript is one kind of behavior too many in ASTScriptVisitor. The goal is to select one behavior that can stay in ASTScriptVisitor - I think inspecting the AST objects is the most sensible choice - and moving the other kinds of behavior each into their own classes. For example, generating Javascript code is a great candidate to move to a separate class because it's such a specific behavior. It will give you a much better view on each kind of behavior and that's the virtue of object-oriented development. You should take advantage of that. Regarding design patterns, you shouldn't worry about that too much. Once you start thinking about abstractions and refactoring you'll automatically end up with Factories and Visitors and Delegates and Adapters. They are pretty natural for object-oriented development. Hope this helps. Now, the task you're about to embark on is not an easy one and it's perfectly normal to not get it right the first time around. So my advice is to check in regularly, even if you know that what you've done is not correct. You can always roll back to a previous version. Just keep your ideas so that you can inspect them at later times. A specific approach that didn't work in one place may be the ideal solution in another. So let SVN become your collective memory, from my experience it will make the job a lot easier. Also, you will need to talk a lot before you start making changes. You're much smarter with 2 or 3 than by yourself. And even if you can't get an agreement on how to continue, you can always decide to give a certain approach that you think might work a try and evaluate it afterwards. There will be a lot of unknowns and the only way to advance is to try and verify the result. Keep the courage, you're guys are doing great. Steven On 12/3/06, Zhou Renjian <jo...@sj...> wrote: > One thing should be mentioned before cleaning up SWT codes: > DO keep all those commented original codes (from Win32 SWT sources. You > may need to compare sources with Win32 SWT sources to known which lines > are Win32 SWT's). As we discussed before, those commented original > sources will help us knowing which API is already implemented and which > is not yet, and they also help us keeping update with SWT 3.2, 3.3. > > All other commented codes can be removed. And new added or modified > methods and fields (including modifying from "default" to "protected" or > "public") should be commented. > > In my opinions, there are no standards to audit cleaning-up. If the > sources with some comments and documents can be well understood by other > developers in one or several days, it would be OK. In order to achieve > such a goal, maybe refactoring codes according to some well-known design > patterns will help a lot. > > Regards > > Soheil Hassas Yeganeh wrote: > > Hi All, > > > > I think we should do clean up for all of our projects. As Zhou is > > starting to clean up j2s core , I will start cleaning up the SWT & > > Java Core projects. > > But I think there remains a problem. How should we audit the clean up > > itself ? Is it any pattern or practice that would help us cleaning the > > projects ? What is a good clean up ? > > > > Regards, > > Soheil > > > > On 12/2/06, Zhou Renjian <jo...@sj...> wrote: > > > >> Hi Steven, > >> > >> Thanks a lot for pointing out the nasty things! Thanks your advices. > >> > >> It was my bad coding habit that made ASTScriptVisitor a mess. And this > >> habit also affected other classes. And I will spend coming days to clean > >> up those codes and add documents about ASTScriptVisitor and inner > >> JavaScript simulator mechanics. > >> > >> If there are other problems about the existed codes (Sure, there are > >> lots of nasty codes), please feel easy to post comments to point them > >> out. And I will try my best to clean things up. > >> > >> Thanks. > >> > >> Regards, > >> Zhou Renjian > >> > >> Steven Devijver wrote: > >> > >>> All, > >>> > >>> I was planning to write my own ASTVisitor extension for j2s. The best > >>> way to get started for me seemed to look at the existing visitor > >>> classes. Thanks to the tutorial here > >>> http://j2s.sourceforge.net/articles/tutorial-extended-compiler.html it > >>> was easy to find the right class to look at: ASTScriptVisitor. > >>> > >>> Sadly I soon found out this class is in decay. It's a whooping 3430 > >>> lines long (that's about 3000 lines in excess) and my guess is that > >>> about one in every 5 lines of code is commented out. As if this is not > >>> bad enough it gets worse. > >>> > >>> There are many very very deeply nested code blocks that make this > >>> class literally Chinese to anyone who wants to get to understand it. > >>> In fact, although I have quite some experience in performing code > >>> reviews I've never seen any class as poorly written as > >>> ASTScriptVisitor. And mind you, this is the first and only class I > >>> looked at in the entire j2s code base. > >>> > >>> Now, you may think I'm ranting. Consider this. I've selected one > >>> deeply nested code block out of many. This is its level of nesting. > >>> This code block that starts on line 2234 in ASTScriptVisitor is nested > >>> in: > >>> > >>> an else block in a while loop in an if block in an if block in an if > >>> block in an else block in an if block in an else block in a while loop > >>> in an if block in an if block in an if block in an else block in an > >>> else block in an if block in a method body. > >>> > >>> That's 16 (!!!) levels of nesting without encapsulation!!! And again, > >>> this is one example in a huge class in a big project. > >>> > >>> My recommendations are simple: > >>> > >>> - check in everything and create a tag in SVN today. > >>> - stop adding new features today so that the project is frozen. Don't > >>> add any new feature before the cleanup is complete. > >>> - in every class of the project, remove all code that is commented > >>> out. The only comments that are allowed are real comments in english, > >>> no code. Start with the classes that have the most lines and continues > >>> until you have checked every class in the codebase. > >>> - test all features of your project and make sure your code works as > >>> expected. Document exactly how you've tested every part of your code > >>> base. Create an issue for every bug you come across that's likely > >>> related to code that has been commented out. > >>> - at this point, stop making any modifications to your code base. > >>> - get together with all developers - either online to in real life - > >>> and start discussing the state of the code base. Start with the > >>> classes that have the most lines (the number of lines need to be > >>> recounted after all commented out code has been removed). Discuss why > >>> each class is as long as it is. Try to find out why these classes are > >>> so long. Try to come up with abstractions and encapsulations. Create > >>> some prototypes and verify if they are up to the job. If not improve > >>> them or come up with alternatives. If you found something interesting > >>> try it out on your code and see if it can improve the expressiveness > >>> of your code. > >>> - once you've selected a couple of code abstractions DOCUMENT THEM!!! > >>> - now attack your code base and implement the abstractions you''ve > >>> selected. Document each abstraction you implement like: ThisClass, > >>> line x to y, ThisAbstraction, This and That class created. > >>> - Re-test your codebase using the test descriptions you've written > >>> down before. Create an issue for every bug your discover that wasn't > >>> reported before. > >>> - fix the issues that were discovered after adding the abstractions. > >>> - now fix the issues that were discovered after the first test run. > >>> > >>> It will require some time but not more that one or two months. Anyway, > >>> if you don't do exactly as I've described your project is lost beyond > >>> repair and you'd better stop working on it today. > >>> > >>> Hope this helps. If you have any questions please feel free to contact me. > >>> > >>> Steven Devijver > >>> > >>> ------------------------------------------------------------------------- > >>> Take Surveys. Earn Cash. Influence the Future of IT > >>> Join SourceForge.net's Techsay panel and you'll get the chance to share your > >>> opinions on IT & business topics through brief surveys - and earn cash > >>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > >>> _______________________________________________ > >>> j2s-development mailing list > >>> j2s...@li... > >>> https://lists.sourceforge.net/lists/listinfo/j2s-development > >>> > >>> > >>> > >>> > >> ------------------------------------------------------------------------- > >> Take Surveys. Earn Cash. Influence the Future of IT > >> Join SourceForge.net's Techsay panel and you'll get the chance to share your > >> opinions on IT & business topics through brief surveys - and earn cash > >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > >> _______________________________________________ > >> j2s-development mailing list > >> j2s...@li... > >> https://lists.sourceforge.net/lists/listinfo/j2s-development > >> > >> > > > > ------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share your > > opinions on IT & business topics through brief surveys - and earn cash > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > > j2s-development mailing list > > j2s...@li... > > https://lists.sourceforge.net/lists/listinfo/j2s-development > > > > > > > > -- > > Regards, > Zhou Renjian > > http://j2s.sourceforge.net/ > Java2Script: Bridge of RCP to RIA > Reusing Java codes and tools into JavaScript > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > j2s-development mailing list > j2s...@li... > https://lists.sourceforge.net/lists/listinfo/j2s-development > > |
|
From: Zhou R. <jo...@sj...> - 2006-12-03 08:47:18
|
One thing should be mentioned before cleaning up SWT codes: DO keep all those commented original codes (from Win32 SWT sources. You may need to compare sources with Win32 SWT sources to known which lines are Win32 SWT's). As we discussed before, those commented original sources will help us knowing which API is already implemented and which is not yet, and they also help us keeping update with SWT 3.2, 3.3. All other commented codes can be removed. And new added or modified methods and fields (including modifying from "default" to "protected" or "public") should be commented. In my opinions, there are no standards to audit cleaning-up. If the sources with some comments and documents can be well understood by other developers in one or several days, it would be OK. In order to achieve such a goal, maybe refactoring codes according to some well-known design patterns will help a lot. Regards Soheil Hassas Yeganeh wrote: > Hi All, > > I think we should do clean up for all of our projects. As Zhou is > starting to clean up j2s core , I will start cleaning up the SWT & > Java Core projects. > But I think there remains a problem. How should we audit the clean up > itself ? Is it any pattern or practice that would help us cleaning the > projects ? What is a good clean up ? > > Regards, > Soheil > > On 12/2/06, Zhou Renjian <jo...@sj...> wrote: > >> Hi Steven, >> >> Thanks a lot for pointing out the nasty things! Thanks your advices. >> >> It was my bad coding habit that made ASTScriptVisitor a mess. And this >> habit also affected other classes. And I will spend coming days to clean >> up those codes and add documents about ASTScriptVisitor and inner >> JavaScript simulator mechanics. >> >> If there are other problems about the existed codes (Sure, there are >> lots of nasty codes), please feel easy to post comments to point them >> out. And I will try my best to clean things up. >> >> Thanks. >> >> Regards, >> Zhou Renjian >> >> Steven Devijver wrote: >> >>> All, >>> >>> I was planning to write my own ASTVisitor extension for j2s. The best >>> way to get started for me seemed to look at the existing visitor >>> classes. Thanks to the tutorial here >>> http://j2s.sourceforge.net/articles/tutorial-extended-compiler.html it >>> was easy to find the right class to look at: ASTScriptVisitor. >>> >>> Sadly I soon found out this class is in decay. It's a whooping 3430 >>> lines long (that's about 3000 lines in excess) and my guess is that >>> about one in every 5 lines of code is commented out. As if this is not >>> bad enough it gets worse. >>> >>> There are many very very deeply nested code blocks that make this >>> class literally Chinese to anyone who wants to get to understand it. >>> In fact, although I have quite some experience in performing code >>> reviews I've never seen any class as poorly written as >>> ASTScriptVisitor. And mind you, this is the first and only class I >>> looked at in the entire j2s code base. >>> >>> Now, you may think I'm ranting. Consider this. I've selected one >>> deeply nested code block out of many. This is its level of nesting. >>> This code block that starts on line 2234 in ASTScriptVisitor is nested >>> in: >>> >>> an else block in a while loop in an if block in an if block in an if >>> block in an else block in an if block in an else block in a while loop >>> in an if block in an if block in an if block in an else block in an >>> else block in an if block in a method body. >>> >>> That's 16 (!!!) levels of nesting without encapsulation!!! And again, >>> this is one example in a huge class in a big project. >>> >>> My recommendations are simple: >>> >>> - check in everything and create a tag in SVN today. >>> - stop adding new features today so that the project is frozen. Don't >>> add any new feature before the cleanup is complete. >>> - in every class of the project, remove all code that is commented >>> out. The only comments that are allowed are real comments in english, >>> no code. Start with the classes that have the most lines and continues >>> until you have checked every class in the codebase. >>> - test all features of your project and make sure your code works as >>> expected. Document exactly how you've tested every part of your code >>> base. Create an issue for every bug you come across that's likely >>> related to code that has been commented out. >>> - at this point, stop making any modifications to your code base. >>> - get together with all developers - either online to in real life - >>> and start discussing the state of the code base. Start with the >>> classes that have the most lines (the number of lines need to be >>> recounted after all commented out code has been removed). Discuss why >>> each class is as long as it is. Try to find out why these classes are >>> so long. Try to come up with abstractions and encapsulations. Create >>> some prototypes and verify if they are up to the job. If not improve >>> them or come up with alternatives. If you found something interesting >>> try it out on your code and see if it can improve the expressiveness >>> of your code. >>> - once you've selected a couple of code abstractions DOCUMENT THEM!!! >>> - now attack your code base and implement the abstractions you''ve >>> selected. Document each abstraction you implement like: ThisClass, >>> line x to y, ThisAbstraction, This and That class created. >>> - Re-test your codebase using the test descriptions you've written >>> down before. Create an issue for every bug your discover that wasn't >>> reported before. >>> - fix the issues that were discovered after adding the abstractions. >>> - now fix the issues that were discovered after the first test run. >>> >>> It will require some time but not more that one or two months. Anyway, >>> if you don't do exactly as I've described your project is lost beyond >>> repair and you'd better stop working on it today. >>> >>> Hope this helps. If you have any questions please feel free to contact me. >>> >>> Steven Devijver >>> >>> ------------------------------------------------------------------------- >>> Take Surveys. Earn Cash. Influence the Future of IT >>> Join SourceForge.net's Techsay panel and you'll get the chance to share your >>> opinions on IT & business topics through brief surveys - and earn cash >>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >>> _______________________________________________ >>> j2s-development mailing list >>> j2s...@li... >>> https://lists.sourceforge.net/lists/listinfo/j2s-development >>> >>> >>> >>> >> ------------------------------------------------------------------------- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to share your >> opinions on IT & business topics through brief surveys - and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________ >> j2s-development mailing list >> j2s...@li... >> https://lists.sourceforge.net/lists/listinfo/j2s-development >> >> > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > j2s-development mailing list > j2s...@li... > https://lists.sourceforge.net/lists/listinfo/j2s-development > > > -- Regards, Zhou Renjian http://j2s.sourceforge.net/ Java2Script: Bridge of RCP to RIA Reusing Java codes and tools into JavaScript |
|
From: Soheil H. Y. <soh...@gm...> - 2006-12-03 06:30:46
|
Hi All, I think we should do clean up for all of our projects. As Zhou is starting to clean up j2s core , I will start cleaning up the SWT & Java Core projects. But I think there remains a problem. How should we audit the clean up itself ? Is it any pattern or practice that would help us cleaning the projects ? What is a good clean up ? Regards, Soheil On 12/2/06, Zhou Renjian <jo...@sj...> wrote: > Hi Steven, > > Thanks a lot for pointing out the nasty things! Thanks your advices. > > It was my bad coding habit that made ASTScriptVisitor a mess. And this > habit also affected other classes. And I will spend coming days to clean > up those codes and add documents about ASTScriptVisitor and inner > JavaScript simulator mechanics. > > If there are other problems about the existed codes (Sure, there are > lots of nasty codes), please feel easy to post comments to point them > out. And I will try my best to clean things up. > > Thanks. > > Regards, > Zhou Renjian > > Steven Devijver wrote: > > All, > > > > I was planning to write my own ASTVisitor extension for j2s. The best > > way to get started for me seemed to look at the existing visitor > > classes. Thanks to the tutorial here > > http://j2s.sourceforge.net/articles/tutorial-extended-compiler.html it > > was easy to find the right class to look at: ASTScriptVisitor. > > > > Sadly I soon found out this class is in decay. It's a whooping 3430 > > lines long (that's about 3000 lines in excess) and my guess is that > > about one in every 5 lines of code is commented out. As if this is not > > bad enough it gets worse. > > > > There are many very very deeply nested code blocks that make this > > class literally Chinese to anyone who wants to get to understand it. > > In fact, although I have quite some experience in performing code > > reviews I've never seen any class as poorly written as > > ASTScriptVisitor. And mind you, this is the first and only class I > > looked at in the entire j2s code base. > > > > Now, you may think I'm ranting. Consider this. I've selected one > > deeply nested code block out of many. This is its level of nesting. > > This code block that starts on line 2234 in ASTScriptVisitor is nested > > in: > > > > an else block in a while loop in an if block in an if block in an if > > block in an else block in an if block in an else block in a while loop > > in an if block in an if block in an if block in an else block in an > > else block in an if block in a method body. > > > > That's 16 (!!!) levels of nesting without encapsulation!!! And again, > > this is one example in a huge class in a big project. > > > > My recommendations are simple: > > > > - check in everything and create a tag in SVN today. > > - stop adding new features today so that the project is frozen. Don't > > add any new feature before the cleanup is complete. > > - in every class of the project, remove all code that is commented > > out. The only comments that are allowed are real comments in english, > > no code. Start with the classes that have the most lines and continues > > until you have checked every class in the codebase. > > - test all features of your project and make sure your code works as > > expected. Document exactly how you've tested every part of your code > > base. Create an issue for every bug you come across that's likely > > related to code that has been commented out. > > - at this point, stop making any modifications to your code base. > > - get together with all developers - either online to in real life - > > and start discussing the state of the code base. Start with the > > classes that have the most lines (the number of lines need to be > > recounted after all commented out code has been removed). Discuss why > > each class is as long as it is. Try to find out why these classes are > > so long. Try to come up with abstractions and encapsulations. Create > > some prototypes and verify if they are up to the job. If not improve > > them or come up with alternatives. If you found something interesting > > try it out on your code and see if it can improve the expressiveness > > of your code. > > - once you've selected a couple of code abstractions DOCUMENT THEM!!! > > - now attack your code base and implement the abstractions you''ve > > selected. Document each abstraction you implement like: ThisClass, > > line x to y, ThisAbstraction, This and That class created. > > - Re-test your codebase using the test descriptions you've written > > down before. Create an issue for every bug your discover that wasn't > > reported before. > > - fix the issues that were discovered after adding the abstractions. > > - now fix the issues that were discovered after the first test run. > > > > It will require some time but not more that one or two months. Anyway, > > if you don't do exactly as I've described your project is lost beyond > > repair and you'd better stop working on it today. > > > > Hope this helps. If you have any questions please feel free to contact me. > > > > Steven Devijver > > > > ------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share your > > opinions on IT & business topics through brief surveys - and earn cash > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > > j2s-development mailing list > > j2s...@li... > > https://lists.sourceforge.net/lists/listinfo/j2s-development > > > > > > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > j2s-development mailing list > j2s...@li... > https://lists.sourceforge.net/lists/listinfo/j2s-development > |
|
From: Zhou R. <jo...@sj...> - 2006-12-02 17:26:36
|
Hi Steven, Thanks a lot for pointing out the nasty things! Thanks your advices. It was my bad coding habit that made ASTScriptVisitor a mess. And this habit also affected other classes. And I will spend coming days to clean up those codes and add documents about ASTScriptVisitor and inner JavaScript simulator mechanics. If there are other problems about the existed codes (Sure, there are lots of nasty codes), please feel easy to post comments to point them out. And I will try my best to clean things up. Thanks. Regards, Zhou Renjian Steven Devijver wrote: > All, > > I was planning to write my own ASTVisitor extension for j2s. The best > way to get started for me seemed to look at the existing visitor > classes. Thanks to the tutorial here > http://j2s.sourceforge.net/articles/tutorial-extended-compiler.html it > was easy to find the right class to look at: ASTScriptVisitor. > > Sadly I soon found out this class is in decay. It's a whooping 3430 > lines long (that's about 3000 lines in excess) and my guess is that > about one in every 5 lines of code is commented out. As if this is not > bad enough it gets worse. > > There are many very very deeply nested code blocks that make this > class literally Chinese to anyone who wants to get to understand it. > In fact, although I have quite some experience in performing code > reviews I've never seen any class as poorly written as > ASTScriptVisitor. And mind you, this is the first and only class I > looked at in the entire j2s code base. > > Now, you may think I'm ranting. Consider this. I've selected one > deeply nested code block out of many. This is its level of nesting. > This code block that starts on line 2234 in ASTScriptVisitor is nested > in: > > an else block in a while loop in an if block in an if block in an if > block in an else block in an if block in an else block in a while loop > in an if block in an if block in an if block in an else block in an > else block in an if block in a method body. > > That's 16 (!!!) levels of nesting without encapsulation!!! And again, > this is one example in a huge class in a big project. > > My recommendations are simple: > > - check in everything and create a tag in SVN today. > - stop adding new features today so that the project is frozen. Don't > add any new feature before the cleanup is complete. > - in every class of the project, remove all code that is commented > out. The only comments that are allowed are real comments in english, > no code. Start with the classes that have the most lines and continues > until you have checked every class in the codebase. > - test all features of your project and make sure your code works as > expected. Document exactly how you've tested every part of your code > base. Create an issue for every bug you come across that's likely > related to code that has been commented out. > - at this point, stop making any modifications to your code base. > - get together with all developers - either online to in real life - > and start discussing the state of the code base. Start with the > classes that have the most lines (the number of lines need to be > recounted after all commented out code has been removed). Discuss why > each class is as long as it is. Try to find out why these classes are > so long. Try to come up with abstractions and encapsulations. Create > some prototypes and verify if they are up to the job. If not improve > them or come up with alternatives. If you found something interesting > try it out on your code and see if it can improve the expressiveness > of your code. > - once you've selected a couple of code abstractions DOCUMENT THEM!!! > - now attack your code base and implement the abstractions you''ve > selected. Document each abstraction you implement like: ThisClass, > line x to y, ThisAbstraction, This and That class created. > - Re-test your codebase using the test descriptions you've written > down before. Create an issue for every bug your discover that wasn't > reported before. > - fix the issues that were discovered after adding the abstractions. > - now fix the issues that were discovered after the first test run. > > It will require some time but not more that one or two months. Anyway, > if you don't do exactly as I've described your project is lost beyond > repair and you'd better stop working on it today. > > Hope this helps. If you have any questions please feel free to contact me. > > Steven Devijver > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > j2s-development mailing list > j2s...@li... > https://lists.sourceforge.net/lists/listinfo/j2s-development > > > |
|
From: Steven D. <ste...@gm...> - 2006-12-02 15:36:24
|
All, I was planning to write my own ASTVisitor extension for j2s. The best way to get started for me seemed to look at the existing visitor classes. Thanks to the tutorial here http://j2s.sourceforge.net/articles/tutorial-extended-compiler.html it was easy to find the right class to look at: ASTScriptVisitor. Sadly I soon found out this class is in decay. It's a whooping 3430 lines long (that's about 3000 lines in excess) and my guess is that about one in every 5 lines of code is commented out. As if this is not bad enough it gets worse. There are many very very deeply nested code blocks that make this class literally Chinese to anyone who wants to get to understand it. In fact, although I have quite some experience in performing code reviews I've never seen any class as poorly written as ASTScriptVisitor. And mind you, this is the first and only class I looked at in the entire j2s code base. Now, you may think I'm ranting. Consider this. I've selected one deeply nested code block out of many. This is its level of nesting. This code block that starts on line 2234 in ASTScriptVisitor is nested in: an else block in a while loop in an if block in an if block in an if block in an else block in an if block in an else block in a while loop in an if block in an if block in an if block in an else block in an else block in an if block in a method body. That's 16 (!!!) levels of nesting without encapsulation!!! And again, this is one example in a huge class in a big project. My recommendations are simple: - check in everything and create a tag in SVN today. - stop adding new features today so that the project is frozen. Don't add any new feature before the cleanup is complete. - in every class of the project, remove all code that is commented out. The only comments that are allowed are real comments in english, no code. Start with the classes that have the most lines and continues until you have checked every class in the codebase. - test all features of your project and make sure your code works as expected. Document exactly how you've tested every part of your code base. Create an issue for every bug you come across that's likely related to code that has been commented out. - at this point, stop making any modifications to your code base. - get together with all developers - either online to in real life - and start discussing the state of the code base. Start with the classes that have the most lines (the number of lines need to be recounted after all commented out code has been removed). Discuss why each class is as long as it is. Try to find out why these classes are so long. Try to come up with abstractions and encapsulations. Create some prototypes and verify if they are up to the job. If not improve them or come up with alternatives. If you found something interesting try it out on your code and see if it can improve the expressiveness of your code. - once you've selected a couple of code abstractions DOCUMENT THEM!!! - now attack your code base and implement the abstractions you''ve selected. Document each abstraction you implement like: ThisClass, line x to y, ThisAbstraction, This and That class created. - Re-test your codebase using the test descriptions you've written down before. Create an issue for every bug your discover that wasn't reported before. - fix the issues that were discovered after adding the abstractions. - now fix the issues that were discovered after the first test run. It will require some time but not more that one or two months. Anyway, if you don't do exactly as I've described your project is lost beyond repair and you'd better stop working on it today. Hope this helps. If you have any questions please feel free to contact me. Steven Devijver |
|
From: Vojtech T. <hic...@ca...> - 2006-11-30 20:34:12
|
Hi, CHfEAP PfARMACY http://www.kaseruijingenfunhasderun.com =20 The sound of a number of thudding feet added a note of urgency to his |
|
From: Zhou R. <jo...@sj...> - 2006-11-12 19:51:47
|
After some delay, Java2Script 1.0.0 M4 now released. And mention again: we are moving to http://groups.google.com/group/java2script/, later we may not post any more new topics or discussion here in the mail-list. New and Noteworthy ================== Java2Script Core ---------------- 1. Support org.eclipse.swt.widgets.Dialog#open in compiler level 2. Extension point for external script visitor, see http://j2s.sourceforge.net/articles/tutorial-extended-compiler.html 3. Bug-fix of M3 compiler Java2Script SWT --------------- 1. CoolBar, ToolBar, Menu, ColorDialog, FontDialog, Tree, Table, Combo, and other widgets improvement 2. Support org.eclipse.swt.widgets.Dialog#open in asynchronous mode. Java2Script AJAX ---------------- 1. Simple RPC. See http://j2s.sourceforge.net/blog/2006/10/12/java2script-introduces-sim... 2. Update HttpRequest according to working draft of http://www.w3.org/TR/XMLHttpRequest/ Java2Script Developer Team -------------------------- 1. Welcome our new developer - Sal Ferro, who joined Java2Script in October, 2006. 2. Google Group http://groups.google.com/group/java2script/ created. Joined us! ******** Next Release would be 1.0.0 RC with improved performance in late December, 2006. Stay tuned. -- Regards, Zhou Renjian http://j2s.sourceforge.net/ Java2Script: Bridge of RCP to RIA Reusing Java codes and tools into JavaScript |
|
From: Zhou R. <jo...@sj...> - 2006-11-07 12:55:38
|
Hi all, Now, the list will be a new group at: http://groups.google.com/group/java2script Meet you there. -- Regards, Zhou Renjian http://j2s.sourceforge.net/ Java2Script: Bridge of RCP to RIA Reusing Java codes and tools into JavaScript |
|
From: Sal <sv...@gm...> - 2006-10-23 22:23:42
|
Zhou,
Sorry for my late response, I have actually been actively working on this
issue. Your information was very helpful - thank you much for the
asssistance!
It seems that the listeners will position the child Shells properly, however
the parent shell will not clip its children shells (as with an MDI
interface). It seems that parenting widgets to a shell is very much
supported in j2s (for example, a 'Button' as a child of a Shell), as well as
clipping these children, so I know the parent->child relationship of windows
is supported currently, it just needs to be enabled for the Shell objects.
As, I'm sure to web browser there is no difference from a Shell object to a
Button, this is probably a J2S implementation detail.
I was going to post a proposal for implementation once I had a better idea
of the code architecture - as I don't want to pollute your list with silly
questions! =) Let me know if you have any thoughts or comments, otherwise I
will continue to look into it,
Thanks much,
- Sal
On 10/16/06, Zhou Renjian <jo...@sj...> wrote:
>
> Hi Sal,
>
> Sorry for misunderstanding about "nested Shells" concept.
>
> For "MDI" type interfaces by SWT, you may add Control listeners to
> parent Shell so parent Shell and children Shells can perform as MDI.
>
> Here is a SWT snippet (You can also check it out from
>
> sources/tests/net.sf.j2s.test.swt/src/net/sf/j2s/test/swt/widgets/TestNestedShells.java)
> Display display = new Display ();
> final Shell shell = new Shell (display);
> shell.setText ("hi");
> shell.setSize(210, 120);
> shell.open ();
> final Shell shell2 = new Shell(shell);
> shell2.setSize(110, 60);
> shell2.open();
> shell.addControlListener(new ControlListener() {
> int lastX, lastY;
> public void controlResized(ControlEvent e) {
> }
> public void controlMoved(ControlEvent e) {
> Point pt = shell.getLocation();
> Point pt2 = shell2.getLocation();
> shell2.setLocation(pt2.x + pt.x - lastX, pt2.y + pt.y -
> lastY);
> lastX = pt.x;
> lastY = pt.y;
> }
> });
> while (!shell.isDisposed()) {
> if (!display.readAndDispatch ()) display.sleep ();
> }
> display.dispose ();
>
> Before you mentioned such a thing, moving and resizing a J2S Shell do
> not send out SWT.move and SWT.resize events. It was a bug. And I just
> fixed that bug.
>
> So before you can run the above snippet in Java2Script mode, you should
> check out the latest code and build the whole things (Following
> instructions of setting up Java2Script environment from SVN repository
> by the website).
>
> Regards
>
> Sal wrote:
> > Zhou,
> >
> > Thanks much for the info. I think I may have been a little unclear on
> > the 'nested Shells' comment, I apologize for that.
> >
> > For example I have this snippet:
> >
> > Shell child = new Shell(parent);
> > child.setSize(200, 200);
> > child.open();
> >
> > My understanding is that this should put the child shell into the
> > parent shell. So that they will nest inside of each other, and if the
> > parent shell is moved, the child shell will also move. They'll appear
> > 'nested' as in - the 'MDI' type interfaces supported in some Windows
> > apps.
> >
> > It seems this feature is supported in the Windows-SWT, so I was
> > curious as to if it will be implemented in j2s.
> >
> > The reason I am attempting this is because I need all the
> > functionality of a Shell (title bar, open/close buttons, etc.) but
> > have them as children of another window which has the same kind of
> > title bar. (And use the same codebase for the Web/j2s version as the
> > Desktop version).
> >
> > Thanks much for the help,
> >
> > - Sal
> >
> >
> > On 10/14/06, *Zhou Renjian* <jo...@sj... <mailto:jo...@sj...>> wrote:
> >
> > Hi Sal,
> >
> > GWT has its advantages: its generated *.js file size is much smaller
> > than Java2Script's and its performance is very good. GWT's *.js is
> > project dependent while Java2Script's *.js is library dependent.
> > And the
> > motivation of GWT's code generation is "to be as small and as
> > efficient
> > as possible" while Java2Script's motivation is "to provide same
> > familiar
> > Java APIs in JavaScript". And there are lots of other differences.
> In
> > fact, GWT is great in many designs.
> >
> > And about nested Shells: if a shell is designed to popup in a
> > method B,
> > the method B won't block later method C. For example:
> > public void methodB() {
> > ...
> > shell.open();
> > while (...)
> > ...
> > }
> > public void callMethod() {
> > methodA();
> > methodB();
> > methodC();
> > }
> >
> > methodC will always be called after methodB without blocking of the
> > shell inside methodB, which is incorrect. And developer should avoid
> > such method calls by wrapping them into callbacks of methodB.
> >
> > If you popup shells orderly in the same method scope, Java2Script
> > compiler will generate JavaScript correctly and shells will popup in
> > correct order. For example:
> > public void aMethod() {
> > ...
> > shell.open();
> > while (...)
> > ...
> > ...
> > anotherShell.open();
> > while (...)
> > ...
> > }
> > anotherShell open only after the first shell is closed, which is
> > correct.
> >
> > You can inspect into the generated JavaScript to get the details.
> >
> > Concept of nested Shells is considered a problem of "Asynchronous
> > Programming v.s. Synchronous Programming" in JavaScript. In
> > JavaScript,
> > no blocking by while loop or Thread.sleep or Object.wait exists. So
> > synchronous programming should be converted into asynchronous
> > programming. Java2Script compiler tries to help such conversions but
> > won't help all. And I think nested Shells may not be implemented in
> > release 1.0. If you find any possible ways to implement it, please
> > discuss it on the mail list or implement it.
> >
> > Regards,
> > Zhou Renjian
> >
> > Sal Ferro wrote:
> > > Hi,
> > >
> > > I'm new to the list. By the way - j2s is really cool, hands down
> > the
> > > best Javascript/RIA framework in existence currently, in my
> opinion.
> > > I just hope sourceforge is ready for the traffic, when word
> spreads
> > > and people come flocking to use this great new technology!! I
> > don't
> > > understand the people comparing it to GWT. Very different
> products,
> > > GWT's scope and functionality kindof pales in my comparison (and
> no
> > > eclipse integration! yuck!).
> > >
> > > My question: I noticed nested Shells are not supported yet. Am I
> > > missing anything, or is it just not yet implemented? If not are
> > there
> > > any plan for implementing the feature yet? I am willing to
> > > help implement it.
> > >
> > > I've become somewhat familiar with j2s sources, using it for
> > several
> > > weeks now, but a pointer or two on the 'suggested' approach to
> > > implement it would help a little to be sure I don't go off into
> > the weeds.
> > >
> > > Thanks to the devs that make this library possible - I hope I
> > can help
> > > soon.
> > >
> > > Thanks,
> > >
> > > - Sal
> > >
> >
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> j2s-development mailing list
> j2s...@li...
> https://lists.sourceforge.net/lists/listinfo/j2s-development
>
|
|
From: Zhou R. <jo...@sj...> - 2006-10-22 13:13:43
|
Ash Wima wrote: > hi zhou, > > as i type this response i cant help but feel that this discussion is a > distraction from you remaining focused on delivering your two > remaining milestones. i want to see you complete this achievement as > much as any other member in your community. > > i thought that it is important to first focus on the business problem > rather the techincal problem. hence, i would like to return to the > statement that i ended the last message with: "is the right problem > was being solved?" > > the reason why i keep returning here is because i also keep arriving > at the same answers to the following problems: > > Problem 1. > ---------- > if you had a desktop java application (or you are an enterprise with a > significant investment in java desktop apps), what is the most > effective way of making that application available on a browser and > reduce the total cost of ownership? > > if feel that if xml11 was more mature, then that would be my preferred option. > > why did i not choose j2s? > well xml11 is more about taking an existing asset (unchanged), and > remoting its display like X11. if i represented the business, i would > not want IT to take an existing asset, create a derivative asset, > fully test the new derivative work and now pay for the ongoing > operations and maintenance of both assets with zero additional > business value. > > > Problem 2. > ---------- > if you need to build a new RIA application, what is the most effective > way to improve time-to-market and quality to reduce the total cost of > ownership? > > i feel that gwt with gwt-designer is the preferred option. > > why did i not choose j2s? > well gwt lets me leverage java resources, does not require me to > retool, enables me to debug the client in pure java, has a large OSS > community around it with commercial sponsorship, has a third party > visual designer tool to support it, and promotes simplexity. > > --- > > what i find paradoxical is that i like your work so much, yet i > wouldnt choose it to solve either of the two problems above. this is > elaborated in my presentation[1] that i delivered. please review > slides 3, 4 & 5 in the cited document. > > what you will notice from these slides is that on my 6 month journey, > i concluded that j2s is the technology that fits my motivation profile > best. i have always said, that there is so much that you are doing > right, but because i believe your technology sits somewhere between > Problem 1 and Problem 2, you are effectively solving a problem that i > do not share. hence, my question to you and your community, "are you > solving the right problem?". > > > after you deliver release 1 of j2s, i hope that you get the > opportunity to reevaluate the position of the technology. > > > --- > > as part of my presentation to the enterprise java forum i decided to > develop a jee application that showcased gwt. i chose to create > gwt-Petstore[2], a gwt implementation of the classic Sun Java > Petstore. i have often wondered what an swt implementation of Petstore > would look like when rendered with j2s. i have tried to imagine web > consumers using the j2s implementation :-). what i have concluded is > that gwt needs to be spiced up with classic desk widgets, but j2s also > needs to be spiced up with broshureware web widgets. > > when you start adding features like broshureware web widgets and > simple rpc, i feel like you are stretching the motivations of rcp. to > me you are now creating a new beast - one that i feel has an identity > crisis! > > --- > > zhou, i want to remind you that these are just one guys crazy > thoughts. i may well be completely wrong. > > btw, sorry to keep you waiting so long for the reply. > > > rgds ash > http://www.gworks.com.au > > 1. http://ashinw.googlepages.com/EJA_GWT_presentation.ppt > 2. http://code.google.com/p/gwtpetstore/ > 3. http://gwtpetstore.googlecode.com/svn/trunk > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > j2s-development mailing list > j2s...@li... > https://lists.sourceforge.net/lists/listinfo/j2s-development > > > Hi Ash, Thanks for your response. Thanks for your view of problems. And I agree with those "why not j2s" reasons after thinking about them for a while. Exporting old existed desktop applications purely does not add new business values but requires maintenance. And maybe few people take such exporting tries. And about developing new RIAs, SWT is not a right choice. And RIAs and desktop applications are a lot different. And more about exporting old assets, if old desktop applications can be refactored into web applications, it will surely add new values. Lots of open source Java desktop applications may be in this scope of consideration (http://eclipse.org/proposals/rap/ thinks about Eclipse RCP directly). But lots of those desktop application projects are Swing based. And Swing is another thing for Java2Script but only be considered after in release of 1.0. And the next milestone of Java2Script is delayed because some key features (most are SWT-related) are still not implemented. And we j2s team will try to catch up with release schedule. And about RPC, which maybe a new beast as you mentioned, it is an early scheduled key feature. Even though I once considered removing it from Java2Script 1.0 feature list, I implemented it as "Simple", hoping it won't become too complicate. Regards -- Regards, Zhou Renjian http://j2s.sourceforge.net/ Java2Script: Bridge of RCP to RIA Reusing Java codes and tools into JavaScript |
5 messages has been excluded from this view by a project administrator.
