Re: Scary: GWT Team does not fix serious GWT Compiler Bugs

[Manuel Carrasco Moñino]

I think it is a good idea to get rid of methods which always return true/false/true because it saves a lot of code in the final js, and it gives the option to the developer to remove code programatically.

In my opinion the example you show and the examples in the issue page are not examples of good codding, but maybe there are edge cases where it could make sense.

I trust in the compiler and I have several projects in production and never I faced this problem, so IMHO knowing a couple of good practices to follow with gwt  should be enough.

Anyway, in the case it were difficult to fix, I think the compiler should be more verbose and fail with methods which have any line apart from the return true one, 

- Manolo

On Fri, Sep 28, 2012 at 2:24 PM, Marc2000 <whip...@googlemail.com> wrote:

Hallo,

After finishing development on my GWT (2.4) project, I found out, that the compiled version does not work exactly as in the development mode.

Some method ( isValid() ) seems not to be called.

Calling code (simplified):

boolean valid=true;
if(! mypanel.isValid())
   valid=false;

method:

public boolean isValid()
{
    updateSomeData();
    return true;
}

This works well in development mode, but in compiled code, isValid() was never called. From this point things got strange. I've added a log-command to the method:

public boolean isValid()
{
    updateSomeData();
    logger.info("method called");
    return true;
}

The method was called and the log entry written.

I removed the log entry and changed the calling part to:

boolean valid=true;
boolean x=mypanel.isValid();
if(!x)
   valid=false;

Now again the method was called. This seems to be some problem in the compiler optimizer. After switching off the optimizer, the compiled code did work as expected.

After searching the web, I found an issue report, DESCRIBING THE EXACT SAME PROBLEM !

See: http://code.google.com/p/google-web-toolkit/issues/detail?id=6551

So this is a know issue since over a year and present since GWT 2.3 !!!

I have not problem with bugs, but I can't understand, why no one seems to care. Can there be something more serious, than a compiler-bug ?

If you search the database, there are some compiler / optimizer issues, that seem not to have been fixed.

Example:

http://code.google.com/p/google-web-toolkit/issues/detail?id=5739 

This is scary ! If you can't trust the compiler, you'll never know, if your code works in production as I did under development. Adding / removing a single line may change the whole behavior. Testing will become a nightmare !

Some one should care.

regards

Marc

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/K3Zt9B3sxW8J.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Jeff Chimene]

+1 on Manolo's point.

However, in the interests of debugging: what happens if you use the boxed version of boolean?

[Juan Pablo Gardella]

+1 too

2012/10/2 Jeff Chimene <jchi...@gmail.com>

[kim young ill]

+1 too

[Chris Lercher]

Sorry, but definitely no. Admittedly, I've never actually encountered such a GWT bug in my own code. But that's irrelevant. Imagine you're changing a method temporarily to debug some code (in a way, that it always returns true), and in compiled mode it will simply not do what you expect - you'll search thousands of places before thinking that it could be a compiler bug.

1. Such bugs are avoidable. 2. It's a compiler's job to make sure you can rely on the basics - everything builds upon that, and errors at that level may amplify, leading to completely unpredictable results. This has nothing to do with good coding on the GWT developer's side (BTW, unit tests are often examples of intentional bad coding. What if they fail - or worse: pass - unpredictably?)

[Daniel Kurka]

I will raise some attention to this.

-Daniel

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/GkEDfwGo3PcJ.

[Manuel Carrasco Moñino]

1. Such bugs are avoidable. 2. It's a compiler's job to make sure you can rely on the basics - everything builds upon that, and errors at that level may amplify, leading to completely unpredictable results. This has nothing to do with good coding on the GWT developer's side (BTW, unit tests are often examples of intentional bad coding. What if they fail - or worse: pass - unpredictably?)

Agree 100%: compiled code should behave the same than debug mode, and should match all java language specifications.

But any gwt developer knows that the gwt compiler has a set of limitations which are widely admitted and documented (regex, number arithmetic, etc), I have spent a lot of time trying to figure out why some tests passed in dev and not in production though. 

So, the point here is what to do with the issue, IMO it should be fixed if possible, otherwise it should be documented or make the compiler print an error, but I wouldn't revert the optimization strategy.

Related with the huge gwt issues list, I think that the gwt team should face them seriously (I hope this is a priority for the steering committee).

- Manolo

 

[Thomas Broyer]

As Chris Lercher pointed out in issue 6551, this is fixed in 2.5.0-rc1. I thus dug in the commit logs and found it's actually been fixed in trunk a couple weeks after being reported (I suppose it was reported independently internally at Google, which explains why the issue wasn't updated).

[Richard]

On Wednesday, October 3, 2012 12:22:57 AM UTC+2, Manuel Carrasco wrote:

But any gwt developer knows that the gwt compiler has a set of limitations which are widely admitted and documented (regex, number arithmetic, etc), I have spent a lot of time trying to figure out why some tests passed in dev and not in production though. 

Number arithmetic? Is this still an issue, even though we can now use BigDecimal?  Is the relevant JS not reliable? 

[Marc2000]

Hallo,

thank you for your responses.

It seems, that the bug has been fixed (Revision r10360, date Jun 21, 2011 ) even before the Issue 6551 report from Jul 4, 2011, but did not make it into GWT 2.4 release.

So that's not as scary as I thought, just the Bug-tracking was not updated ;-)

As to the bad coding point:

Good practice or not, implementing or overriding classical abstract methods like 'isValid()' may result in methods always returning 'true', if there is nothing to validate. A Compiler should produce working code, even with bad coding ( or throw a warning). To ignore a method's side-effect is a clear bug.

Problem is, that this was my first GWT project and I was very pleased with the workflow and great functionality ( I'm using it with Ext GWT 2.2.5).

I had to convince my client to use this technique, who was very skeptical about the Java / JavaScript cross compiling part. So stumbling over an optimizer bug in the first project was not helpful ;-)

I must admit, the GWT team fixed that quite fast. Now I'm looking forward to the GWT 2.5 release.

Best regards

Marc