Richard Monson-Haefel's Blog

JSR-241: Groovy � A New Standard Programming Language for the Java Platform

Until now the Java programming language has reigned supreme as the standard programming language for the Java Platform. It has served us well for close to nine years, but it cannot be all things to all people. And it shouldn't. The Java Programming language, like C++ and C#, is a strongly and statically typed programming language. While this type of language, sometimes called a "conventional" language, is useful for solving many problems, it is not a panacea. Conventional programming languages are very exacting, meaning that you have to dot every 'i' and cross every 't' in order for the program to compile. This orthography of statically defining all the types may result in more predictable code, but it also tends to slow developers down.

An alternative to conventional programming languages are agile programming languages like Python, Ruby and Perl among others. These agile languages have long been called "scripting" languages, but that term is not, IMO, sufficient. Many in IT perceive scripting languages as layman languages that sacrifice technical sophistication for easy of use. This may be true of some scripting languages, but it's certainly not the case with Python, Ruby or Perl. These are dynamic and powerful programming languages that happen to use less syntax to accomplish more.

To be perfectly honest, although I'm listed on the JSR as a co-spec lead, I'm a Johnny-come-lately to the Groovy bandwagon. Groovy already has a grass roots following and all the credit for the development of Groovy goes James Strachan and other contributors to the Groovy open source project. I'm not a language designer, but I understand the power that languages like Python and Ruby offer developers and I believe it is time for the Java Platform to include an agile programming language. It's this personal conviction that led me to initiate and co-develop JSR-241 with James Strachan and Gier Magnusson of Apache. My role as a specification lead is to manage the progression of this JSR through the JCP and author the Groovy Language Specification � two tasks that can be terribly distracting to those doing the really hard work of developing the JSR itself.

Groovy represents the beginning of a new era in the Java platform, one in which the Java community embraces language diversification and harnesses the full potential of the Java platform. It�s the recognition that the Java is more than a programming language; it�s a robust platform upon which multiple languages can operate and co-exist. To me this has always been the unrealized promise of the Java Platform.

The Java programming language is, simply put, a convenient abstraction for the real language of the Java platform: byte code. As a user-friendly abstraction for byte code the Java programming language is powerful, but it's not omnipotent. There are circumstances in which a different language, an agile programming language, is more expressive and productive.

So why Groovy? Why not Jython or JRuby? Why not one of the dozens of other programming languages that are designed to run on the Java Virtual Machine? It's my opinion, and I believe the opinion of those who support this JSR, that Groovy is the best choice because it was built from the ground up for the Java Platform and uses syntax that is familiar to Java developers, while leveraging some of best features that Python, Ruby and Smalltalk have to offer. Jython and JRuby are excellent examples of how existing languages can be ported to the Java platform, but they are, after all, ports. They use syntax that is not designed with Java developers in mind and they are founded on a completely different set of code libraries. Groovy is designed for Java developers and its foundation is the standard APIs of the Java Platform.

Comments

• Interesting... I think this project is a great idea because it shows the diversity of the Java platform. However, I am a little cynical about this whole "agile"/scripting language stuff. Maybe it's just because I've been a little too often burnt by scripts I've written which I thought were manipulating a *string* containing the name of a file, but turned out to be screwing up the *file itself* - type safety is sometimes a good thing... Also, although prototyping in these languages is often quicker, maintenance becomes a real pain and I'd contend that there is basically no such thing as "throw away code". (Sorry, didn't mean this to turn into a scripting languages rant) Either way, I think this project is a great opporunity to show off the Java platform and I'm looking forward to having a play.

  Posted by: archangel on March 16, 2004 at 06:28 AM

• too much choice. Groovy is a good idea, but from the spesifications i saw, it gives too much power to the user. There are too many choices to do one thing. this is, IMHO evil. this results crating unmaintainable code easier. i for example saw one person wants "if" to work also without the paranthesis. if groovy accepts such requests and implements, it will be just like perl or php soon. some times less is more. But if it is accepted by JCP, probably the creators of Groovy will have to ponder twice before adding more functionality. Thus, applying to JCP is good news.

  Posted by: ahmetaa on March 16, 2004 at 06:42 AM

• Groovy doesn't work with unsigned JWS Unfortunately I can't plug Groovy into my application because groovy requires all sorts of SecurityManager permissions to work properly. This makes it completely unusable as an embedable Java scripting language.

  Posted by: markswanson on March 16, 2004 at 07:11 AM

• Interesting... In which language did you think you had a string, where you in fact had a file and you messed it up?

  Posted by: jherr on March 16, 2004 at 07:12 AM

• Two problems First, the statement; "It�s the recognition that the Java is more than a programming language; it�s a robust platform upon which multiple languages can operate and co-exist. To me this has always been the unrealized promise of the Java Platform." Seems a bit odd since it has always been McNealy's position that Java is the one true programming language and the only one you will ever need. Second, why is it critical that this new language be intimately tied to the Java platform. If Groovy is an easy new syntax, why not create a loose coupling between Groovy and it's platform?

  Posted by: jherr on March 16, 2004 at 07:18 AM

• Alternatives: pnuts and BeanShell BeanShell compiles pure Java except for a single case I found (emailed to the BeanShell guy), but does not work in a SecurityManager so is also unusable as an embedable Java scripting language. http://www.beanshell.org/ pnuts: https://pnuts.dev.java.net/ works perfectly with a SecurityManager and unsigned (secure) Java Web Start applications. The syntax does not seem to be exactly Java, but it is only a couple of minor things: http://javacenter.sun.co.jp/pnuts/doc/faq.html#2.3

  Posted by: markswanson on March 16, 2004 at 07:43 AM

• You can always "choose" to not use Groovy I'm a programmer who is most comfortable in statically typed languages, but there are milions of programmer's who like scripting (or "agile") languages that could contribute to the success of the Java platform. These people like "too many choices" and some even like writing "unmaintainable code". The Java community *must* create at least one option for these programmers. Those who are wary of "too many choices" can choose to avoid Groovy or projects that use Groovy. Natural selection will take its toll on projects with unmaintainable code as people choose not to use or contribute to them. I agree that the JSR/JCP process will be good for Groovy, but us traditional Java programmers need to realize that Groovy has a different philosophy and (most likely) a different target user.

  Posted by: msgilligan on March 16, 2004 at 09:21 AM

• As significant as Open Source Java Groovy (or any scripting option with critical mass and/or standardization) could be as significant for the adoption of the Java platform by the Python/Perl/PHP/Open Source community as an OSS (Open Source Software) implementation of Java. Using Eric Raymond as an example, he has a strong preference for Python and scripting languages, and also is an OSS advocate. How much of the distaste for Java comes from it not being OSS and how much from it being "rigid"? In some cases it may be that the stated reason for not using Java is that it is not OSS, but the real reason (or more significant reason) is that there is no scripting option.

  Posted by: msgilligan on March 16, 2004 at 09:33 AM

• too much choice. "Groovy is a good idea, but from the spesifications[sic] i saw, it gives too much power to the user. " Yow! That's about the funniest thing I've heard in weeks. Oh no! We can't give power to the users; they just can't be trusted not to run amok! How about this motto? "Java: It's all about freedom from choice." I've been using Ruby for about 2 years now, and have yet to shoot myself in the foot. When I switch over to Java(tm), I find myself taking twice as long to get the same amount of work done because I have to waste time pleasing the compilier gods instead of focusing on the task at hand. Groovy looks quite good (looks quite a bit like Ruby, actually), and should be encouraged. At least there will be a migration path for entry-level programmers to step up to dynamically-typed progamming when they feel they are ready to handle the power.

  Posted by: jamesbritt on March 16, 2004 at 09:38 AM

• BeanShell? "So why Groovy? Why not Jython or JRuby? Why not one of the dozens of other programming languages that are designed to run on the Java Virtual Machine? It's my opinion, and I believe the opinion of those who support this JSR, that Groovy is the best choice because it was built from the ground up for the Java Platform and uses syntax that is familiar to Java developers, while leveraging some of best features that Python, Ruby and Smalltalk have to offer. Jython are JRuby are excellent examples of how existing languages can be ported to the Java platform, but they are, after all, ports. They use syntax that is not designed with Java developers in mind and they are founded on a completely different set of code libraries. Groovy is designed for Java developers and its foundation is the standard APIs of the Java Platform." So why not BeanShell?

  Posted by: coxcu on March 16, 2004 at 10:28 AM

• Can it at least reach 1.0 first? It's just kind of sad to see a few people turn Java into their own private sandbox. Groovy is the very definition of unproven technology. It's still beta and it has essentially zero adoption. Can we even point to a single production application using Groovy? Heck, does the language even a specification or is this another case of open source winging it? Let's be very, very careful about we make into a standard. Once something's enshrined in a JSR then it never goes away. Instead of trying to make Groovy ride off Java's popularity, why don't we let Groovy go into the market by itself and prove itself to the market. Then, once it's mature and clearly demonstrated some value, then we can talk about standardizing it. Let Groovy demonstrate that it's actually better than all the other scripting languages out there including the PHP/Java integration already being worked on. I'd rather see the market decide on an official Java scripting language rather than a bunch of publicity-whoring bloggers.

  Posted by: ocean on March 16, 2004 at 11:41 AM

• BeanShell? Good question. I don't know what the technical pros and cons are between Beanshell and Groovy (I haven't really used either) but here are some questions and things to consider: 1) Would Beanshell get the political support necessaary to become a JSR? 2) Could there be two seperate JSRs? 3) Could there be a supporting facility in Java (as a JSR) to standardize the support of scripting languages (such as BSF)?

  Posted by: msgilligan on March 16, 2004 at 11:41 AM

• Can it at least reach 1.0 first? The Java community needs to do something in this area and do it fast. Groovy may not be the right solution, but saying lets let the market decide threatens the health of the Java platform. Does a JSR really "enshrine" something. Aren't there plenty of JSRs that are being ignored?

  Posted by: msgilligan on March 16, 2004 at 11:46 AM

• Can it at least reach 1.0 first? The Java community is already doing something - there is Groovy, Pnuts, and BeanShell. Why should Groovy be the standard? BeanShell is integrated with BEA WebLogic 6.1+ so seems better positioned than Groovy. I really like the idea that "Ocean" put forward about letting the market first give some weight to an "official" standard.

  Posted by: markswanson on March 16, 2004 at 12:11 PM

• Can it at least reach 1.0 first? Speaking from a market perspective, I've been investigating BeanShell, Groovy, and pnuts to see if I could incorporate them as the scripting engine for ScheduleWorld. I'm not an expert by far in any of these (though I have submitted patches for BeanShell) but I have done a lot of work preparing ScheduleWorld - and I've integrated all three inside of ScheduleWorld. Only one worked: pnuts. The other two have SecurityManager problems - and I have not found or received any indication they will be fixed any time soon. I also really like the thought the pnuts folks put into security - that matters to me. Having said that, I think the whole Java scripting concept is really fascinating and have nothing but encouragement for all projects. Let's just wait awhile before we etch one in stone eh?

  Posted by: markswanson on March 16, 2004 at 12:22 PM

• JSR 223 (Scripting Pages in Java Web Applications) JSR 223 (http://www.jcp.org/en/jsr/detail?id=223) addresses some of the same issues, but focusing on the Servlet/WAR environment. PHP is supposed to be a reference implementation, but looking at the PHP5 project mailing lists it seems like there is no actual code available yet. Does anyone know where a publicly available update on the status of this project is available? (JSR 241 says there is no overlap with 223, but there should be no reason why Groovy can't be a scripting language under 223 as well.)

  Posted by: msgilligan on March 16, 2004 at 12:26 PM

• Official standards, JCP, and scripting I don't understand the JCP process enough to know that inclusion of Groovy as a standard would exlude Beanshell, Pnuts, etc. Perhaps there should be a syntax-independent JSR that addresses issues in integrating scripting languages with the JVM (client and server, as opposed to JSR 223)? Issues like the security issue you have brought up, etc. Can the benefits of standardization through JCP be achieved without favoring one syntax/implementation over another? BTW, the JSR sas BEA is supporting it.

  Posted by: msgilligan on March 16, 2004 at 12:38 PM

• too much choice. well. i coded in Php a lot. and i saw the codes people has written. an incredible mess. But you can write nice and undestandable code too. Problem is, php gives you the choice to make a mess easitly. And most people goes that way. With a strongly typed language this is lets say "less difficult". Besides, With the current IDE's like IDEA etc it is much easier to write accessors, constructors etc , or modify everything easily in java, i do not need a scripting language who makes them completely ivisible, if the matter is writing more code for doing the same. i do not reject the need for a scripting language but one should be careful about making things "too easy" for particular things resulting hard to solve consequences.

  Posted by: ahmetaa on March 16, 2004 at 06:30 PM

• too much choice. sorry, the words would be "..more difficult" at the end of first paragraph. Pardon my English.

  Posted by: ahmetaa on March 16, 2004 at 06:33 PM

• JSR 223 (Scripting Pages in Java Web Applications) Incidentally I'm a member of JSR 223 and we'll be ensuring that Groovy fully supports JSR 223. Note JSR 223 is a specification for how scripting languages in general connect with the web container, so it will work nicely with JSR 241.

  Posted by: jstrachan on March 16, 2004 at 10:30 PM

• Whatever happened to Rhino (Javascript)? I feel as if I had been hiding under a rock for ages. Pnuts, Groovy? I thought the main players in Java scripting integration arena were Beanshell, Jython and... Rhino. Javascript (at least where I work) has a larger user base than any of those, including Python. So tell me: did Rhino go the way of the dinosaurs without me noticing? Is Javascript anathema for some new and shiny programming paradigm?

  Posted by: irivera on March 17, 2004 at 01:21 AM

• BeanShell? Why use Groovy instead of ${someLanguage}? Quick answer - use whatever you want! Longer answer... http://groovy.codehaus.org/faq.html#why-groovy

  Posted by: jstrachan on March 17, 2004 at 06:01 AM

• Vote "NO" for the Groovy JSR I'm hoping I misunderstand the current state of the JSR. As it stands, I'm quite upset about this, and more than a little disappointed and frustrated. Groovy absolutely can not work with unsigned Java Web Start applications - or any application that does not meet Groovy's specific SecurityManager requirements. If Groovy does not work with unsigned Java Web Start I think it is perfectly fair to say that Groovy does not work with the Java Platform. Groovy fails the JSR 241 requirement section 2.5 as it does not "interoperate with the entire J2SE platform" as it does not work in the unsigned Java Web Start environment. Section 2.6 of JSR 241 is false: there is BeanShell and Pnuts. Groovy fails section 2.10 of JSR 241: there are major security issues that can NOT be addressed. What is disturbing is that recently I read posts on the Groovy developer mailing list about removing the ability of running in interpreted mode (Interpreted mode could be made to work in an unsigned Java Web Start environment - that's how Pnuts does it, and how BeanShell tries to but falls just a little bit short). I think Groovy is a great idea, but the direction its developers have taken will render Groovy unusable for a lot of Java developers and for major Java applications. I don't claim to be a Groovy expert, and I actually hope I'm wrong on every single issue. Unless someone does correct me, please vote "NO" by subscribing to the link below and participating in the process. http://www.jcp.org/en/jsr/detail?id=241 Thanks for listening.

  Posted by: markswanson on March 17, 2004 at 06:34 AM

• Yay! The static typing of Java often gets in my way when I am working on a problem. While Java has a lot of nice features compared to C++, now it will have even more. I for one am glad for Groovy. I believe you should give the programmer a choice. Dictating to a programmer how they will work is a really bad idea, unless the programmer sucks. In that case, they should do something they are good at instead of programming.

  Posted by: bob on March 17, 2004 at 06:40 AM

• don't confuse implementation details with specifiactions (was) Vote "NO" for the Groovy JSR Relax Mark. > Groovy absolutely can not work with > unsigned Java Web Start applications > - or any application that does not meet > Groovy's specific SecurityManager requirements. Why not just submit an issue to the open source project and I'm sure your issue will be addressed. Its just a matter of patching the code to work inside WebStart. http://groovy.codehaus.org/ There's nothing inherently wrong with Groovy-the-language. This is purely an implementation issue that can fairly easily be addressed.

  Posted by: jstrachan on March 17, 2004 at 07:28 AM

• don't confuse implementation details with specifiactions (was) Vote "NO" for the Groovy JSR I did ask on Sat Jan 4, 2004. I asked, "Hello, I don't seem to be able to create groovy objects and execute them in an unsigned JWS environment (it is not possible to create a ClassLoader in this environment). I also can not execute groovy scripts in an unsigned JWS environment. It would be great to embed groovy inside ScheduleWorld as people have been asking for a way to export Schedules and integrate with it in all sorts of ways. I could not in good conscience run groovy outside of the secure sandbox..." and also... "P.S. I've noticed in the archives that developers working on groovy are moving away from using reflection for dynamic method dispatching. It would seem to me this is moving in a direction that will totally prevent Groovy from working in secure environments no?" The response was: "If you can't create a ClassLoader then you must compile all the groovy scripts to bytecode as part of the build process. Then they are just like normal Java objects." This means Groovy can not be used as an embedded scripting language inside unsigned Java Web Start environments and the developers do not seem to be interested in making Groovy work in such environments. If the Groovy developers will not make the changes to work in the unsigned Java Web Start environment we should vote "NO" and send a message that we want to be able to build secure applications. I don't want my freedom to build applications limited. This implementation issue is not easily addressed at all, and if the developers have no interest in fixing it the Java community _will_ get stuck with a standard scripting language that doesn't work and may never work. It's too frustrating to even contemplate.

  Posted by: markswanson on March 17, 2004 at 01:13 PM

• don't confuse implementation details with specifiactions (was) Vote "NO" for the Groovy JSR Mark - we can and will solve this issue. Please bear with us and lets discuss this on the groovy-dev list. FWIW using reflection is still possible. (call groovy.lang.MetaClass.useReflection(true)) However trying to stop the Groovy language standardization effort as there is currently an issue running it inside WebStart does sound a little dramatic - why not help us fix this particular implementation issue rather than spending your energy on trying to stop the standardardization of the language syntax?

  Posted by: jstrachan on March 17, 2004 at 11:46 PM

• don't confuse implementation details with specifiactions (was) Vote "NO" for the Groovy JSR Not dramatic, passionate. For the record, I am providing strong well-reasoned arguments for making the Java scripting language work in all Java environments. My hope is that people look at my comments as valuable feedback from someone who has a vested interest in (and is personally fascinated by) the technology. If no one gave stong well-reasoned arguments for porting Java to Linux then Sun might never have provided a Linux version of Java. I believe the same applies to everything in life. Stuff gets done for a reason. I'm giving some reasons. Peace.

  Posted by: markswanson on March 18, 2004 at 06:01 AM

• Ironic As someone who uses jython in a production application, I took a brief look at groovy to assess it. I find it ironic that it's similarity to java syntax is considered a strength. IMHO, it makes the groovy code look ugly compared to jython code. The ability to paste java code into a groovy code seems of little value since it is usually done the other way around--you tinker at a scripting console and get the algorithm working and then port the code into java if needed. I doubt if groovy would port much easier than anything else since the functionality is different (that's the whole point of a using an alternative language). I have helped several developers learn python sytax so they could start scripting in jython and they always pick it up in a day or two--and then they know python too (and can access it's vast libraries that come along with it) for when they aren't restricted to using a JVM. Functionality-wise, groovy looks like it has a decent blend of features and I didn't see anything I would miss except for python's terse syntax (and triple quote syntax for literals, useful for templating without escaping embedded single and double quotes). But that's based on just browsing the docs. Pedigree-wise, groovy is very immature compared to jython (and even more so compared to python). Hence the consternation on selecting groovy as the subject of a JSR. For me, the choice to stay with jython is obvious--even ignoring groovy's immaturity. I don't just want an "agile" language for the jvm. I want an another language for the jvm that can also bridge me into the python world loaded with tools, apps, libraries and books with a vibrant community. But if you work with developers who won't be comfortable working outside of java's syntax and you only want to run on a jvm and you don't mind the relative immaturity, then groovy is probably a good alternative.

  Posted by: cupdike on March 21, 2004 at 02:36 PM

• Reinventing the weel? I wonder why the JCP loves to create new APIs, libraries (and now even programming languages) when there are widely adopted open source tools that could do the job. The only answer I can think about is letting companies sell new implementation -- they can't do this if an OSS tools is sanctioned as a JCP standard. The logging API, Java Server Faces and now Groovy just seems to me ways to frament the community -- will you rewrite your apps just because another thing became an "official" JCP standard? It would be better from developers point of view and also for users (but not big $$$ JCP members) if existing OSS strengths and limitations tools were discused by the JCP and were improved to meet the JSR goals. OSS is so successfull because it avoids reinventing the weel. If there's something that works, even partially, the community join efforts to improve it, not to create something else that's "better" by whatever means you define "better". The JCP could learn somehthing with OSS.

  Posted by: flozano on March 24, 2004 at 09:41 AM

• Vote "NO" for the Groovy JSR I think it's premature to appose this JSR just because the early beta version of the RI can't currently work with unsigned Java Web Start applications. We are actually working on the security manager now and there is talk of supporting an Interpreted mode. But, I guess your point is somewhat moot. The JSR was accepted.

  Posted by: bl7385 on March 30, 2004 at 03:02 PM

• 搬屋公司 shipping container 月餅 depot 燈光 環保袋 Video system 視聽器材 containers 膠袋 中秋節 Shopping Bag moon cake Tomy 寵物善終

  Posted by: xuefeng8 on July 30, 2007 at 09:25 PM

• 月餅 租車 租车公司

  Posted by: peak on August 08, 2007 at 12:31 AM

• 搬屋| 搬屋|物流 buying office project management 廣告設計 logistics management office furniture 货架Shipping agent

  Posted by: teiddy on August 12, 2007 at 06:44 PM

• fdfdfd

  Posted by: yuebing on August 15, 2007 at 05:36 PM

• Valentine Day-情人節-情人-花束-花球-果籃-襟花-花籃-禮品

  Posted by: peak on August 16, 2007 at 03:38 AM

• 1,月饼 2,月饼 3,月饼 4,月饼 5,月饼 6,月饼

  Posted by: mooncake on August 25, 2007 at 04:46 PM

• Peripheral venous catheterization centers 1. Methods 1.1 preoperative preparation (1) items to: PICC puncture kits, including (torn .The drugs can cause The etiology of cancer has not yet fully clear, but most of that contact is .Bladder cancer qigong conditioning Sitting in the chair, with feet shoulder width and separately, into the thigh and calf .Male breast cancer can Male breast cancer can also occur, or about 0.1% of all breast cancer, and that .CANCER HELP Providing the knowledge of cancer, including cancer prevention, treatment, diagnosis Advisory . The Year of the Year Of The Pig 1923, 1935, 1947, 1959, 1971, 1983, 1995, 2007, 2019, 2020, 2031, 2043 People .The Year Of The Year of the Rat 1912, 1924, 1936, 1948, 1960, 1972, 1984, 1996, 2008, 2020, 2032, 2044 People .Chinese Zodiac Animals As sometimes happens with historical developments, several versions of the origin of the Chinese Zodiac .Chinese Zodiac and Feng What does Chinese Feng Shui have to do with the Chinese Zodiac? More than you .The Year Of The Year Of The Tiger 1914, 1926, 1938, 1950, 1962, 1974, 1986, 1998 Tigers, considered to be brave, . The European Institute of Urological Institute Europe (EAU) in the first prostate cancer treatment guidelines published in 2001. In .Earlier studies showed that Johns Hopkins University School of Medicine study of 14 patients with pancreatic cancer vaccine experiment. .PROSTATE CANCER Treatment and Tests diagnosis of PROSTATE CANCER. .Surgical treatment of prostate Surgical treatment: 1) prostate cancer radical operation, covering the prostate gland and prostate capsule; .Sunbathing may prevent prostate Now people know, if you can keep people in higher vitamin level, the erosion . Breast cancer endocrine treatment Breast cancer and endocrine (particularly ovarian) is close to endocrine therapy in the disease only .More fish may prevent Japan's Ministry of Education, Culture, Sports, Science and Research Group survey found that more women .Restaurants and sunlight exposure One pair of different national diet studies have confirmed that eating too much animal fat .BREAST CANCER BASE Treatment and Tests diagnosis of Breast Cancer. .Extended cycle of chemotherapy 10-year study showed that the node-positive breast cancer before menopause women to accept if . 强人的单张剪纸 很有创意的一组剪纸艺术 .

  Posted by: ruthrobeson on September 23, 2007 at 11:44 PM

• Tips on Buying Office Desks The furniture in an office has
  home office computer furniture An Office or Home Office is
  home office computer furniture Furniture. What would we do without
  Office Furniture Provided office furniture, and
  Different Office Furniture When we talk about office furniture,
  Wedding Dresses What To You have begun to plan your
  Wedding Dresses And Their Importance wedding is solemn occasion.
  Looking Great in your Bridesmaid So, the wedding is two weeks
  Wedding Dresses Find the wedding dresses
  Planning Colors for Your Wedding: Dreaming about your wedding is one
  

  Posted by: ruthrobeson on September 26, 2007 at 03:28 AM

• agree this project is great, and wait to see it finished. from Michael @ tinpok.com

  Posted by: mmmicng on September 28, 2007 at 01:58 AM

• 手机铃声 手机铃声,手机铃声,手机铃声,手机铃声手机铃声,手机铃声,手机铃声手机铃声 深圳家具厂 深圳家具厂 机票查询 机票查询

  Posted by: stillstayhere on November 30, 2007 at 01:51 AM

This work is licensed under a Creative Commons License.