I'm glad you find this project useful. I don't have the time right now to 
fill issues  :( 

Please feel free to use the project for founding bugs and fill the issues. 

About the test, for my personal taste, it concentrates too much on testing 
if a NPE is or is not throwed. I agree this is not a "serious" bug and that 
GWT won't fix it (and I agree with the reasons). But as you mention there 
are other bugs that I thing are worthwhile. 

The list of issues I have collected were discovered by my with these tests 
in a day or two. I think with some more time several and "more concrete" / 
positive bugs can be found. 

Also I know of at least one person that, after my project, cloned the 
original java mauve project for better GWT and maven integration 
(https://github.com/niloc132/mauve-gwt). 

On Friday, March 22, 2013 7:31:51 PM UTC-3, John A. Tamplin wrote:
>
> On Thu, Mar 21, 2013 at 9:16 PM, Sebastián Gurin 
> <[email protected]<javascript:>
> > wrote:
>
>> I think this can be really interesting to those looking to find GWT jre 
>> emulation bugs. I myself just discovered some of them listed on 
>> http://gwtmauve.googlecode.com/svn/trunk/gwtmauve/readme.txt
>>
>> (rich conclusions of this project results can be taken from these bugs)
>>
>> Well, I hope this can be useful to those who want to find and fix GWT 
>> bugs and also to know which parts of the GWT JRE emulation are "more 
>> broken" in production mode. Use it as you like. Had to release it under 
>> gpl3 for respecting mauve sources license. Comments and ideas are most 
>> welcome. Regards
>>
>> Thanks, this is useful.  Note that clone isn't supported (it can't be 
> supported in general in JS), and generally you shouldn't expect the same 
> exceptions to be thrown where doing so is inefficient -- see 
> https://developers.google.com/web-toolkit/doc/latest/DevGuideCodingBasicsCompatibility.
>  
>  For example, Java String is directly mapped to a JS string, so the only 
> way to give the same IOOB exceptions would be to add checks around every 
> index/substring/etc operation.  Likewise for many NPEs. 
>
> That explains a large chunk of them.  Some of the others, such as 
> Character.toTitleCase, are because they can't be implemented properly and 
> shouldn't really be used anyway (in many cases, the title case of a 
> character should be multiple characters).  BigInteger is itself a slow 
> emulation in JS, so I am not surprised that isProbablyPrime is extremely 
> slow on a large number.
>
> The others, such as the missing Collections.rotate and bugs in 
> Arrays.fill, Collections.copy, and String.compareTo are good catches and 
> should have issues filed.
>
> -- 
> John A. Tamplin 
>

-- 
-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to