Re: [gwt-contrib] Re: Infinite loop at compile time

[Paul Robinson]

Thanks Colin. I should have looked at the issue tracker. Sorry about that.

On Mon, Jan 22, 2024 at 5:01 PM Colin Alworth  wrote:

> Thanks for reporting - perhaps better for the bug tracker, and indeed we
> do this (or something like it) filed already, see
> https://github.com/gwtproject/gwt/issues/9840.
>
> Your email title says that this is a compile time infinite loop, but then
> the body suggests that it was a runtime error. If it were to be exhibited
> at runtime, it would almost certainly be a stackoverflow rather than
> looping forever (barring some sort of tail call optimization). The actual
> loop that you're seeing is waaay up the stack in
>
> at
> com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.optimizeJsLoop(JavaToJavaScriptCompiler.java:1001)
>
> where the compiler decides to optimize until it reaches your optimization
> level, or until nothing changes. While SDM stands for "Super Dev Mode", it
> can also be understood to mean "Super Draft Mode", so the compiler builds
> as quickly and cheaply as possible, letting your app escape with very
> little optimization. This means that in SDM, you will not get stuck in this
> loop - the optimization loop won't run at all (see one frame up,
> shouldOptimize will return false), and you'll instead experience a
> stackoverflow at runtime.
>
> I didn't continue investigation of the problem further yet, but the linked
> ticket does have some analysis to consider.
> On Monday, January 22, 2024 at 8:30:50 AM UTC-6 Paul Robinson wrote:
>
>> I just found an infinite loop while running the GWT compiler.
>>
>> There was a trivial bug in my code which resulted in an infinite loop at
>> *runtime*. This is a method that was calling itself recursively. It was
>> inside a generic class, and the method had a single line that was something
>> like this:
>>
>> public class A extends C {
>> public static  A getA(D d, E e, F f) {
>> return getA(d, e, null);
>> }
>> }
>>
>> I have been running in dev mode with it like this, but not hitting this
>> code so I didn't notice the infinite loop.
>>
>> Wanting to test GWT 2.11.0, I switched from GWT 2.10.0 and did a full GWT
>> compile. The interesting thing is that the GWT compile also hit an infinite
>> loop. Or rather, it was apparently infinite. I stopped it after 50 minutes,
>> where it would normally complete in about about 90 seconds. I dropped back
>> to 2.10.0, and found the same behaviour. So it's not caused by the new
>> release.
>>
>> Fixing the bug in my code meant it then compiled properly (in both 2.11.0
>> and 2.10.0).
>>
>> Is this interesting enough to warrant further investigation? This is code
>> inside a large application, so isolating a simple example that demonstrates
>> it might not work easily.
>>
>> FWIW there's a stack trace taken while stuck in the loop, compiling with
>> 2.11.0 here: https://pastebin.com/qckpswRD
>>
>> Paul
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/58e74afc-7677-4a92-8895-880d884cd802n%40googlegroups.com
> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/58e74afc-7677-4a92-8895-880d884cd802n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAGHNWN%2Bej52aGjUnGKMMBKSjLiJCGQ_0Z1PtM6O2t_NoQHbXhg%40mail.gmail.com.

[gwt-contrib] Infinite loop at compile time

[Paul Robinson]

I just found an infinite loop while running the GWT compiler.

There was a trivial bug in my code which resulted in an infinite loop at 
*runtime*. This is a method that was calling itself recursively. It was 
inside a generic class, and the method had a single line that was something 
like this:

public class A extends C {
public static  A getA(D d, E e, F f) {
return getA(d, e, null);
}
}

I have been running in dev mode with it like this, but not hitting this 
code so I didn't notice the infinite loop.

Wanting to test GWT 2.11.0, I switched from GWT 2.10.0 and did a full GWT 
compile. The interesting thing is that the GWT compile also hit an infinite 
loop. Or rather, it was apparently infinite. I stopped it after 50 minutes, 
where it would normally complete in about about 90 seconds. I dropped back 
to 2.10.0, and found the same behaviour. So it's not caused by the new 
release.

Fixing the bug in my code meant it then compiled properly (in both 2.11.0 
and 2.10.0).

Is this interesting enough to warrant further investigation? This is code 
inside a large application, so isolating a simple example that demonstrates 
it might not work easily.

FWIW there's a stack trace taken while stuck in the loop, compiling with 
2.11.0 here: https://pastebin.com/qckpswRD

Paul

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/e83dce79-9dd5-4985-9c86-9277e7261c25n%40googlegroups.com.

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

[Paul Robinson]

On Sat, Apr 17, 2021 at 7:45 PM eliasbala...@gmail.com <
eliasbala...@gmail.com> wrote:

> During development,
> with "SuperDevMode"+"Jetty" and "Google Plugin for Eclipse",
> GWT client-side code compilation (including the nocache.js files) is done
> at runtime by DevMode.
>
> Any other scenario demands that we,
> separately compile the GWT client-side code,
> separately run a servlet,
> separately deploy the GWT code to the server (both client-side and
> server-side),
> separately run GWT CodeServer,
> then run a browser,
> then genearate the CodeServer link etc.
> The complexity difference is obvious.
>

It's not obvious because the 6 steps you listed are not 6 manually executed
steps. Let's look at them:

(1) You can start servlets and CodeServer with one click.
(2) Compiling the GWT client code happens automatically on refreshing the
browser page.  As Thomas said, it has been like this since GWT 2.7
(3) You don't need to deploy to the server - at least in Eclipse (and
probably IntelliJ too) you can run a Jetty server inside Eclipse and have
it use the Eclipse-compiled classpath.
(4) You do need to run a browser - but that's always required in every
scenario.
(5) I don't know what you mean by "generate the CodeServer link" - you just
point your browser at your servlet Jetty server and everything just works.

The only practical difference with the planned change is that you need to
configure a servlet engine, and it then runs in two separate processes
instead of one. But you can still initiate those two processes with a
single click if that's important to you.

Paul

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAGHNWNJVaOOgZMPr0AbBxg1exzsVvQYfUn-PQsLop0iGuyN6rw%40mail.gmail.com.

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

[Paul Robinson]

Would it be plausible to split GWT into two projects - one as it is now but
without Jetty built in, and another that adds the bits relating to Jetty?

Then the GWT Jetty project could be maintained by those that require it.

Paul

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAGHNWNKR5uS3iG%3Dh14pU%3DDKANUSsUBYEWeWqowr9dhzPKsLziQ%40mail.gmail.com.

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

[Paul Robinson]

Vassilis - I don't use the bookmarklet. It may still work (I don't know)
but it's not needed in recent GWT versions. I just refresh my browser and
it recompiles automatically if anything has changed.

Paul

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAGHNWNJQdCRQ5NfRA--B7SLmxBZikc1tjfiabfX8%2BKnDWTgYOQ%40mail.gmail.com.

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

[Paul Robinson]

I used the built in Jetty server until a year or so ago. Occasionally I
have to use the older version in development as we haven't upgraded
everybody in production to the new version yet.

>From a development perspective, I find running a separate code server and
Jetty to be much more productive.

Whenever I need to restart, it's usually only Jetty I need to restart, and
it's much faster to not restart the code server part as well.

So there may be an extra step, but I'm much happier with it this way.

Paul

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAGHNWN%2BYgug5qMirEg-6fDC1Lyj6xvsh7VHBJ4xdicq1UwPOAA%40mail.gmail.com.

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

[Paul Robinson]

As a heavy user of GWT-RPC in a large app, I've become disillusioned with
it. That's for three reasons:

- I often need to see what data is being sent, and it's just not very good
for that. It makes debugging harder than it could be.

- it's not good for communicating from a mobile app.

- it's much too easy to accidentally send much more data than necessary.
Being forced to think about your content on-the-wire would probably make a
better product in the long run.

So we're going to pay the price to migrate away from GWT-RPC and I don't
feel too bad about it going away.

I just hope we don't have to give up widgets too. I don't see that being
practical for us.

Paul

On 20 May 2017 2:56 pm, "Learner Evermore" 
wrote:

> ... and before someone mentions version/compatibility issues with
> serialization (using any framework) not that NO framework solves this, they
> just have different ways of not solving it. And all frameworks expose
> *exactly* equal ways of dealing with it should one be interested. Including
> java.io.Serializable. And if you happen to not care and change things, it
> always results in errors (default cases excepted) only with
> java.io.Serializable you get that error immediately and with some other
> popular frameworks you get the error at the time of first use - hence less
> detectable.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/google-web-toolkit-contributors/1eaced67-96f6-
> 4ea0-9ef7-5bbabb2cf569%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAGHNWNLr2jT1WKHs7qnYdG1K_LpT1WdB3TQJ5X26ucKLCROdqA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: GWT 2.8.0-beta1 available for testing

[Paul Robinson]

Thanks for the clarification Thomas.

On Tue, Dec 8, 2015 at 1:45 PM, Thomas Broyer  wrote:

>
>
> On Tuesday, December 8, 2015 at 1:54:40 PM UTC+1, Paul Robinson wrote:
>>
>>
>>
>> On Mon, Dec 7, 2015 at 3:06 PM, Colin Alworth  wrote:
>>
>>> If I could be permitted to slight restate what Julien just said: We will
>>> make a note of it, as we have done in the past, such as when the default
>>> moved from java6 to java7:
>>> http://www.gwtproject.org/release-notes.html#Release_Notes_2_6_0_RC1.
>>>
>>
>> I was questioning what happens for GWT RPC in production at runtime.
>>
>> GWT 2.6 (and also 2.7) did not require Java 7 at runtime for RPC, whereas
>> GWT 2.8 does. Does the suggestion that it might require Java 8 by the time
>> GWT 2.8 is released apply to compile time or run time?
>>
>
> With the current build scripts, yes; and it'll be quite hard to decouple
> the two.
>
>
>> The release notes should separate the requirements for compile time and
>> run time Java environment.
>>
>
> You have no guarantee that your code will run in an earlier Java
> environment when you compile with a later one (i.e. if you cross-compile;
> see
> https://docs.oracle.com/javase/8/docs/technotes/tools/unix/javac.html#BHCIJIEG).
> Things used to work earlier, but Java 8 makes it very real.
> See
> http://developer-blog.cloudbees.com/2014/12/beware-siren-target-call.html
> and http://www.draconianoverlord.com/2014/04/01/jdk-compatibility.html
> for examples of that.
> If you want to be compatible with Java 6, you should use a Java 6 JDK or
> at least a Java 6 bootclasspath (though as I said, Java 7 is in most cases
> –if not all– compatible with Java 6 if you make sure you don't use
> Java7-specific APIs).
> If you require Java 8 at compile-time, then there are risks that your code
> won't work in a Java 6 or Java 7 environment.
>
> If any statement could me made, it'd be about client-side and server-side;
> or compile-time in the sense of the GWT Compiler, not to be confused with
> JavaC.
>
> Building GWT in a way such that it's compatible at runtime with Java 7 (or
> 6) would at a minimum require building it (JavaC) with Java 7 (or 6) and
> then running tests with Java 8; or running Retrolambda or similar on
> gwt-servlet and requestfactory-* (but then ideally those would have to be
> exercised too). Anything else would require changing the build scripts and
> be much more complicated.
> Because Oracle Java 7 is EOL'd, the chances that this happens are very low
> *unless* someone helps make it happen (or Vaadin, Sencha or RedHat –who
> have paying customers that probably would face that issue– possibly jump
> in).
> (note: this is *me* talking, *not* in the name of the steering committee).
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/837ee151-4b87-42d5-8b2c-a9a83a157e68%40googlegroups.com
> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/837ee151-4b87-42d5-8b2c-a9a83a157e68%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAGHNWNJh97QN%3D3yywU8fhh7OdNoZWEer9dZ3K%2B%3Ds76POVLHN8w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: GWT 2.8.0-beta1 available for testing

[Paul Robinson]

On Mon, Dec 7, 2015 at 3:06 PM, Colin Alworth  wrote:

> If I could be permitted to slight restate what Julien just said: We will
> make a note of it, as we have done in the past, such as when the default
> moved from java6 to java7:
> http://www.gwtproject.org/release-notes.html#Release_Notes_2_6_0_RC1.
>

I was questioning what happens for GWT RPC in production at runtime.

GWT 2.6 (and also 2.7) did not require Java 7 at runtime for RPC, whereas
GWT 2.8 does. Does the suggestion that it might require Java 8 by the time
GWT 2.8 is released apply to compile time or run time?

The release notes should separate the requirements for compile time and run
time Java environment.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAGHNWNL1w7LPMXJL%2BBAy0kiRAkim_rVnEZjdUHbWgnLp86ANhw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] GWT 2.8.0-beta1 available for testing

[Paul Robinson]

Is it intentional/necessary that gwt-servlet.jar is compiled for Java 7 and
not Java 6?

On Fri, Dec 4, 2015 at 9:51 AM, Daniel Kurka  wrote:

> Hi all,
>
> we just finished testing for GWT 2.8.0-beta1. You can either download it
> from goo.gl/62SeR5 or from maven central.
>
> Release notes can be found here
> .
>
> Please start testing and let us know about any issues you encounter by
> either discussion here or filing bugs on github
> .
>
> -Daniel
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/2daed4d2-41df-44e9-b00e-25d1cec0e8c9%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAGHNWNKERkDMGdJNfkM%3D1ZQx8-pbeguTAwN2bZ9Q%3DbqGfdGv2g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] GWT 2.8 RC1

[Paul Robinson]

Yes, I know. The thing is, there's always a level of paranoia about GWT's
impending doom and apparent lack of activity shown in the gwt users group,
and a release coming at an unknown time helps to fuel that paranoia.

Having said that, I've voted for the bug :)

On Wed, Oct 28, 2015 at 2:14 PM, Colin Alworth  wrote:

> Paul, do keep in mind that the latest in git (and the 2.8.0-SNAPSHOT in
> maven) is fairly stable. Some projects (for example, everything that Google
> makes) live off of trunk, and many projects upgrade to a snapshot, test
> that things are sane, and then 'pin' that build internally to keep running
> with it until they decide to update again.
>
> On Wed, Oct 28, 2015 at 8:57 AM Seamus McMorrow 
> wrote:
>
>> To try to speed up the fix, maybe if people voted for the issue, it may
>> help.
>> I just cast my vote to get it fixed.
>>
>>
>> On Wednesday, 28 October 2015 12:53:17 UTC, Paul Robinson wrote:
>>>
>>> Speaking for myself, a GWT 2.8.0 release that works, but uses too much
>>> memory compiling code, to be followed by GWT 2.8.1 with the memory fix, is
>>> better than waiting for an unknown amount of time until JDT is fixed.
>>>
>>> On Wed, Oct 28, 2015 at 8:46 AM, 'Goktug Gokdogan' via GWT Contributors
>>>  wrote:
>>>
>>>> Hey guys.
>>>>
>>>> We are planning to make the release cut by next Monday to start testing
>>>> sooner. Hopefully by the time we will complete most of the critical pieces
>>>> for JsInterop.
>>>>
>>>> Also FYI, JDT has a huge memory problem with Java8
>>>> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=472177> so doing a
>>>> final release without a fix may make the release less useful for a lot of
>>>> people. Let's hope that gets fixed soon.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "GWT Contributors" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to
>>>> google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA1Se5eNCNjwS5F8c-wzc7BYqd0rWY%2Bq--Yg9cP7353UnA%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA1Se5eNCNjwS5F8c-wzc7BYqd0rWY%2Bq--Yg9cP7353UnA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>> .
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/0856-c756-4493-936d-41be54f8d33d%40googlegroups.com
>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/0856-c756-4493-936d-41be54f8d33d%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CADcXZMyM%3DZut%3DHky4hcWunWZL0WWmH%2B0xNDY5KrshM8k4F48wg%40mail.gmail.com
> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/CADcXZMyM%3DZut%3DHky4hcWunWZL0WWmH%2B0xNDY5KrshM8k4F48wg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAGHNWNKKFzkeCKMeCJQPPJ6VE4L3YNoLY-3FuyzZH690XdoLEQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] GWT 2.8 RC1

[Paul Robinson]

Speaking for myself, a GWT 2.8.0 release that works, but uses too much
memory compiling code, to be followed by GWT 2.8.1 with the memory fix, is
better than waiting for an unknown amount of time until JDT is fixed.

On Wed, Oct 28, 2015 at 8:46 AM, 'Goktug Gokdogan' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

> Hey guys.
>
> We are planning to make the release cut by next Monday to start testing
> sooner. Hopefully by the time we will complete most of the critical pieces
> for JsInterop.
>
> Also FYI, JDT has a huge memory problem with Java8
>  so doing a final
> release without a fix may make the release less useful for a lot of people.
> Let's hope that gets fixed soon.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA1Se5eNCNjwS5F8c-wzc7BYqd0rWY%2Bq--Yg9cP7353UnA%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAGHNWNJjpmEbhtv8yb-2pwTXBgm-MX3%3DAeddvZx-MpQbMKu64A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Stop calling it GWT 3.0

[Paul Robinson]

On Saturday, 13 June 2015 12:18:37 UTC+1, Thomas Broyer wrote:
>
> it's expected that you could future-proof your application in GWT 2.8.

 
Yes, except that if you're heavily invested in GWT widgets, then 
"future-proofing" means switching to a different rendering library and so 
almost a complete re-write of your UI code. It may not be practical for 
many widget-based GWT applications.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/06f7d82b-9c93-4445-a160-f8be9f0e40ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Stop calling it GWT 3.0

[Paul Robinson]

 

The GWT Meetup 2015 videos are very interesting.


I can see why the proposals for GWT 3.0 have been made. However, we should 
be clear about the fact that GWT 3.0 is not just going to break a few 
little things that can easily be fixed, but break things to the point that 
it's a completely different product and there will be lots of GWT 
applications that will never be ported to the new system.


It will be confusing to all GWT users to continue to use the name GWT 3.0. 
It would be much better to use a new name for the new system and treat it 
as what it is: a new idea about how Java can be used to build modern web 
applications.


The situation we have now is that GWT will end at 2.8 and a new thing, that 
is currently vapourware, will be coming that people are expected to use. 
There's going to be a lot of confusion and those using GWT now, as well as 
those that will use the new thing when it does exist, will all be served 
much better if everybody stops calling the new thing "GWT".


Paul


-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/23171750-56e5-498f-a122-9aebdec44dcd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Steering committee meeting on GWT 3.0 IE & Java compatibility

[Paul Robinson]

This discussion has covered what the general rules for dropping support for 
browsers, APIs and JVMs should be. That's a good thing, but what I would really 
like is for GWT to specify the actual dates when it is expected that GWT will 
no longer support particular runtime server JVM versions and those browsers 
with a slow release cycle (IE).

Most of my clients are using SAAS in which I control the server environment and 
so I can happily change the server JVM. But for the non-SAAS customers, I need 
to give them as much notice as possible that they will need to provide a Java 7 
or Java 8 server environment. For that, an approximate date from GWT would be 
very helpful.

Ideally, there would be a list of all the planned deprecations and breakages 
shown on gwtproject.org along with the dates they will be dropped, even if the 
actual dates are a bit fuzzy.

Paul

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Re: Another approach to DevMode: taking advantage of browsers' remote debugging protocol

[Paul Robinson]

On 14/12/12 11:24, Thomas Broyer wrote:
>
>  and there's also the issue with GWT-RPC serialization policies that make 
> using SuperDevMode tricky (apparently, I don't use RPC).
"Tricky" is too strong a word for it. It only takes a small amount of code, so 
that the RPC servlet's doGetSerializationPolicy(...) can fetch the 
serialization policy file from the code server. Once that's done, it just 
works. I never have to think about it or actively do anything to make 
SuperDevMode work with RPC.

Paul

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: Delivery Status Notification (Failure)

[Paul Robinson]

On 22/11/12 17:16, Jens wrote:
>
> If its only renaming a package from X to Y then, as a developer, I am totally 
> fine if my code becomes broken after updating GWT because I could fix that 
> via some IDE automatism like organize imports or a global search/replace on 
> import statements. As long as its well documented in the release notes, so it 
> does not hit me like a surprise, this should be fine.
+1

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] *.rpc.log files

[Paul Robinson]

I went looking for the *.rpc.log files that get generated during the GWT 
compile yesterday, only to find that they don't get generated by default any 
more. After a bit of digging in the source code, it seems that you have to turn 
them on now with an argument of "-logLevel DEBUG" to the GWT compiler.

This was a change made in rev 10833.

Perhaps this should be documented somewhere? It would be good if it were in or 
near to here:
https://developers.google.com/web-toolkit/doc/latest/DevGuideServerCommunication#DevGuideSerializableTypes

I looked, but failed to find anything in the docs about the existence of the 
*.rpc.log files, how to turn them on, or what they are good for.

Paul

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: SuperDevMode CodeServer extensions

[Paul Robinson]

On 11/06/12 12:01, Thomas Broyer wrote:
> How about customizing the CrossSiteIframeLinker instead?
> Customizing either the computeUrlForResource or loadExternalStylesheets to no 
> longer be relative to the "module base url" (but rather to, say, the "host 
> page base url").
> Or if you need it to be relative to the "module base url", add a linker to 
> emit the appropriate CSS files in the module output dir (where the Super Dev 
> Mode's will find them).
I have this working, so I'm back to using the standard code server. I have to 
remember to disable my custom linker before a production release, but I had to 
do that anyway with the new Super Dev Mode.

I gave my new linker the same name as the original (xsiframe) so that the 
change in ScriptTagLoadingStrategory  
continues to work without me having to replicate that explicitly for my own 
linker.

Some things I've noticed about Super Dev Mode:
(1) ImageBundle requests for *.cache.png do not go to the code server, nor do 
they go through computeUrlForResource. They should probably always come from 
the code server in super dev mode. Worse than this though, it seems that the 
computed strong name is different in client and server. I don't know if this is 
just me, but the client asks for a *.cache.png file that doesn't exist in a 
production compiled app, but does exist in the code server. So I don't have any 
ImageBundles working.

(2) Chrome doesn't seem to ask for the source maps unless the javascript 
console is open while a compilation is done. This means that you can't debug 
your app without an additional compilation if you happened to compile with the 
console closed.

(3) I only worked out what was going on in (2) because the custom code server I 
was originally using was set to log a message every time there was an http GET. 
Perhaps there should be a verbose option on code server to provide something 
similar?

(4) I have two host html files, with different deferred binding settings in 
them. If I change the URL in the browser's address bar to switch between them, 
a subsequent compile doesn't pick up the new bindings. I have to close the 
browser tab and open a new one.

(5) If you create an interface, and then define classes that implement that 
interface within the same source file, then the implementations don't appear 
inside Chrome. Eg:
public interface Foo {
public int getValue();

public class FooImpl implements Foo { // --> FooImpl doesn't show up
public int getValue() { return something; }
}
}


I can live with these things, especially given the experimental nature of Super 
Dev Mode. And I wouldn't want to delay 2.5 :)

Paul

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: SuperDevMode CodeServer extensions

[Paul Robinson]

I've not played with linkers before, but I can see that your suggestion should 
work and would be cleaner than what I have. I'd effectively have to translate 
my existing codeserver changes from java to javascript, but that shouldn't be 
difficult (even for a javascript novice :)

Thanks,
Paul

On 11/06/12 12:01, Thomas Broyer wrote:

How about customizing the CrossSiteIframeLinker instead?
Customizing either the computeUrlForResource or loadExternalStylesheets to no longer be relative to 
the "module base url" (but rather to, say, the "host page base url").
Or if you need it to be relative to the "module base url", add a linker to emit 
the appropriate CSS files in the module output dir (where the Super Dev Mode's will find 
them).

On Monday, June 11, 2012 12:16:19 PM UTC+2, Paul Robinson wrote:

The new superDevMode is *very* impressive. Well done!

I don't know how unusual my use-case is, but I require custom handling of 
some CSS files to make things work properly. For example, I allow customers to 
skin my app, and that requires CSS in a database. So there's a CSS file 
referenced in a gwt.xml file that does not exist as a regular file on disk. 
Consequently, the code server cannot possibly handle it correctly.

I also use ant to write a build number into the name of some CSS files in 
gwt.xml files. The CSS files are stored without the build number, and so I have 
an http filter that removes the build number from the file name. This means 
that users' browsers are forced to update their CSS whenever I release a new 
build.

Modifying com.google.gwt.dev.codeserver.WebServer to do what I want was 
pretty easy, but I'd prefer not to change it at all. Ideally, it would be 
easier to customise its behaviour via subclassing.

In particular, I would like the following changes:
(a) WebServer.doGet(...) to be protected, not private
(b) WebServer.sendOutputFile(String, HttpServletResponse) to be protected, 
not private
(c) The signature of WebServer.sendOutputFile(String, HttpServletResponse) 
to be modified so that the HttpServletRequest is passed in (so that I can work 
out who the http referer was, and pass on the request for the 
database-generated CSS to my tomcat server)
(d) CodeServer constructs WebServer directly. That means I would have to copy 
& paste CodeServer and make the replacement create my WebServer subclass. 
Alternatively, it would be easier if CodeServer.main(String[]) were to construct an 
instance, and then use protected instance methods to do all the work, including 
parsing the options and creating the WebServer instance. That way, I could subclass 
CodeServer as well.

Is this possible?

Thanks,
Paul

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors 


--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] SuperDevMode CodeServer extensions

[Paul Robinson]

The new superDevMode is *very* impressive. Well done!

I don't know how unusual my use-case is, but I require custom handling of some 
CSS files to make things work properly. For example, I allow customers to skin 
my app, and that requires CSS in a database. So there's a CSS file referenced 
in a gwt.xml file that does not exist as a regular file on disk. Consequently, 
the code server cannot possibly handle it correctly.

I also use ant to write a build number into the name of some CSS files in 
gwt.xml files. The CSS files are stored without the build number, and so I have 
an http filter that removes the build number from the file name. This means 
that users' browsers are forced to update their CSS whenever I release a new 
build.

Modifying com.google.gwt.dev.codeserver.WebServer to do what I want was pretty 
easy, but I'd prefer not to change it at all. Ideally, it would be easier to 
customise its behaviour via subclassing.

In particular, I would like the following changes:
(a) WebServer.doGet(...) to be protected, not private
(b) WebServer.sendOutputFile(String, HttpServletResponse) to be protected, not 
private
(c) The signature of WebServer.sendOutputFile(String, HttpServletResponse) to 
be modified so that the HttpServletRequest is passed in (so that I can work out 
who the http referer was, and pass on the request for the database-generated 
CSS to my tomcat server)
(d) CodeServer constructs WebServer directly. That means I would have to copy & 
paste CodeServer and make the replacement create my WebServer subclass. 
Alternatively, it would be easier if CodeServer.main(String[]) were to construct an 
instance, and then use protected instance methods to do all the work, including 
parsing the options and creating the WebServer instance. That way, I could subclass 
CodeServer as well.

Is this possible?

Thanks,
Paul

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: Move Super Dev Mode to the open source repository. (issue1727804)

[Paul Robinson]

I've sent the speed tracer file directly to you.

Also, I have some http GET requests that the code server cannot find (quite 
reasonably). It would be nice if it could delegate anything it can't find to 
the external tomcat/jetty.

It's also objecting to some of the characters in the URL of some of my http GET 
requests. Is it possible c.g.g.dev.codeserver.WebServer's safe filename pattern 
could be an optional argument?

Thanks,
Paul

On 08/06/12 22:53, Ray Cromwell wrote:

Opps, sorry, the speedtracer log is always on anyway. Look in the
super-dev-mode work dir, e.g.
/tmp/gwt-codeserver-*/modulename/speedtracer.html

I think the issue might be that I18N generators don't implement
IncrementalGenerator, and so they run every compile, even if nothing
in your interfaces or property files changed.  We are talking about
having perhaps two buttons in the UI, "Compile" and "Run Generators
and Compile", or maybe checkbox. Then, we'd run the generators once on
the first compile, and subsequent recompiles would not re-run them.
Except when people are editing css, images, or i18n interfaces, they
can then do a full 'regenerate and recompile'. Later when all of the
standard GWT generators are taught to behave better it would be needed
less and less.



On Fri, Jun 8, 2012 at 2:41 PM, Paul Robinson  wrote:

I'm not using UiBinder or Gin.

I am using GWT RPC, I18N and ImageResource.

I have approximately:
- 100 methods across several ClientBundles returning an ImageResource.
- 700 I18N methods spread over about 30 interfaces (my initial 2
permutations were for the default locale)
- for GWT RPC, I have about 40 RPC methods. One of those is used for the
command pattern and has a hierarchy of about 70 request classes that can be
passed to it.

My initial VM args were:
-Xmx1024M -Xss8M

This is running on linux 64 bit, with enough spare RAM that it never used
any swap space.

After changing to your suggested VM args, the initial compile was 62s
(instead of 3 minutes), then compiling from the browser took 18.4s, 16.8s,
17.0s, 17.4s, 15.4s, 16.8s, 16.0s

I did add a "-Dgwt.speedtracerlog=/tmp/superdevmode.json" argument, but no
file was produced.

HTH
Paul


On 08/06/12 22:12, Ray Cromwell wrote:

Hmm, that's still not where we'd like to be. Our design goal is<10s.
  Are you using UiBinder, Gin, ImageResource, I18N, GWT RPC?  I'm
wondering if one of the generators may or may not have an issue with
incremental compilation.

This may not do anything, but try it anyway, add these JVM flags
-Dgwt.persistentunitcache
-Dgwt.persistentunitcachedir=/tmp
  -XX:MaxPermSize=512M
  -Xmx2048m

Also add -Dgwt.speedtracerlog=/tmp/superdevmode.json

And send me the resulting file after a few recompile runs. This may
give me a hint as to which parts of the compiler are taking too long.

-Ray

On Fri, Jun 8, 2012 at 2:03 PM, Paul Robinsonwrote:

I've just tried SuperDevMode for the first time. I have around 250KLOC,
of
which around 200KLOC are translated to javascript.

The code server reported 3 minutes for the initial compile (with 2
permutations), then 37 seconds for the first compile from the browser,
and
then consistently 18-19 seconds thereafter.

Paul


On 08/06/12 21:38, Ray Cromwell wrote:

I just checked again, one of the internal apps we are trying
SuperDevMode against has about 400,000 lines of code and combines in
about 7-8 seconds. So maybe your app has 6x as much code? If not, it
gives us a clue that perhaps there's some other edge condition causing
the compile to be slow.

-Ray


On Fri, Jun 8, 2012 at 12:09 PM, Ray Cromwell
  wrote:

How big is your app? (KLOC)  Internally, we'd had success with<10s
refresh on some fairly largish apps. I'm wondering if something else
isn't going on. Note that the first compile usually takes long, but
subsequent ones are faster. Are you using UiBinder? One issue could be
generators using too much time.


On Fri, Jun 8, 2012 at 11:21 AM, Jens
  wrote:

Just to finish this off in case anyone else has the same problem -
this was fixed in r11031.

https://code.google.com/p/google-web-toolkit/source/detail?r=11031


Thanks for the info. I had the same problem but now it works. Now lets
hope
the compilation process will become a lot faster in the future. A
single
permutation of our app compiles on the code server in ~45 seconds and
thats
not really acceptable during development compared to the "classic"
DevMode.

-- J.

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors


--
http://groups.google.com/group/Google-Web-Toolkit-Contributors


--
http://groups.google.com/group/Google-Web-Toolkit-Contributors


--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: Move Super Dev Mode to the open source repository. (issue1727804)

[Paul Robinson]

I'm not using UiBinder or Gin.

I am using GWT RPC, I18N and ImageResource.

I have approximately:
- 100 methods across several ClientBundles returning an ImageResource.
- 700 I18N methods spread over about 30 interfaces (my initial 2 permutations 
were for the default locale)
- for GWT RPC, I have about 40 RPC methods. One of those is used for the 
command pattern and has a hierarchy of about 70 request classes that can be 
passed to it.

My initial VM args were:
-Xmx1024M -Xss8M

This is running on linux 64 bit, with enough spare RAM that it never used any 
swap space.

After changing to your suggested VM args, the initial compile was 62s (instead 
of 3 minutes), then compiling from the browser took 18.4s, 16.8s, 17.0s, 17.4s, 
15.4s, 16.8s, 16.0s

I did add a "-Dgwt.speedtracerlog=/tmp/superdevmode.json" argument, but no file 
was produced.

HTH
Paul

On 08/06/12 22:12, Ray Cromwell wrote:

Hmm, that's still not where we'd like to be. Our design goal is<  10s.
  Are you using UiBinder, Gin, ImageResource, I18N, GWT RPC?  I'm
wondering if one of the generators may or may not have an issue with
incremental compilation.

This may not do anything, but try it anyway, add these JVM flags
-Dgwt.persistentunitcache
-Dgwt.persistentunitcachedir=/tmp
  -XX:MaxPermSize=512M
  -Xmx2048m

Also add -Dgwt.speedtracerlog=/tmp/superdevmode.json

And send me the resulting file after a few recompile runs. This may
give me a hint as to which parts of the compiler are taking too long.

-Ray

On Fri, Jun 8, 2012 at 2:03 PM, Paul Robinson  wrote:

I've just tried SuperDevMode for the first time. I have around 250KLOC, of
which around 200KLOC are translated to javascript.

The code server reported 3 minutes for the initial compile (with 2
permutations), then 37 seconds for the first compile from the browser, and
then consistently 18-19 seconds thereafter.

Paul


On 08/06/12 21:38, Ray Cromwell wrote:

I just checked again, one of the internal apps we are trying
SuperDevMode against has about 400,000 lines of code and combines in
about 7-8 seconds. So maybe your app has 6x as much code? If not, it
gives us a clue that perhaps there's some other edge condition causing
the compile to be slow.

-Ray


On Fri, Jun 8, 2012 at 12:09 PM, Ray Cromwell
  wrote:

How big is your app? (KLOC)  Internally, we'd had success with<10s
refresh on some fairly largish apps. I'm wondering if something else
isn't going on. Note that the first compile usually takes long, but
subsequent ones are faster. Are you using UiBinder? One issue could be
generators using too much time.


On Fri, Jun 8, 2012 at 11:21 AM, Jenswrote:

Just to finish this off in case anyone else has the same problem -
this was fixed in r11031.

https://code.google.com/p/google-web-toolkit/source/detail?r=11031


Thanks for the info. I had the same problem but now it works. Now lets
hope
the compilation process will become a lot faster in the future. A single
permutation of our app compiles on the code server in ~45 seconds and
thats
not really acceptable during development compared to the "classic"
DevMode.

-- J.

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors


--
http://groups.google.com/group/Google-Web-Toolkit-Contributors


--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: Move Super Dev Mode to the open source repository. (issue1727804)

[Paul Robinson]

I've just tried SuperDevMode for the first time. I have around 250KLOC, of 
which around 200KLOC are translated to javascript.

The code server reported 3 minutes for the initial compile (with 2 
permutations), then 37 seconds for the first compile from the browser, and then 
consistently 18-19 seconds thereafter.

Paul

On 08/06/12 21:38, Ray Cromwell wrote:

I just checked again, one of the internal apps we are trying
SuperDevMode against has about 400,000 lines of code and combines in
about 7-8 seconds. So maybe your app has 6x as much code? If not, it
gives us a clue that perhaps there's some other edge condition causing
the compile to be slow.

-Ray


On Fri, Jun 8, 2012 at 12:09 PM, Ray Cromwell  wrote:

How big is your app? (KLOC)  Internally, we'd had success with<10s
refresh on some fairly largish apps. I'm wondering if something else
isn't going on. Note that the first compile usually takes long, but
subsequent ones are faster. Are you using UiBinder? One issue could be
generators using too much time.


On Fri, Jun 8, 2012 at 11:21 AM, Jens  wrote:

Just to finish this off in case anyone else has the same problem -
this was fixed in r11031.

https://code.google.com/p/google-web-toolkit/source/detail?r=11031


Thanks for the info. I had the same problem but now it works. Now lets hope
the compilation process will become a lot faster in the future. A single
permutation of our app compiles on the code server in ~45 seconds and thats
not really acceptable during development compared to the "classic" DevMode.

-- J.

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors


--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] ClientBundle compilation performance

[Paul Robinson]

Hi,

I recently introduced an ImageBundle to my code with 1000 images. Everything 
worked ok, but I then converted it to a ClientBundle and found a couple of 
problems:

(1) It seems that ClientBundle holds files open during the compilation where ImageBundle 
does not. I had to dramatically increase the number of open files I was allowed to have 
so that the GWT compile would work. This is on linux, with GWT 2.3. I was getting a 
"Too many open files" system error.

(2) I had hoped that GWT would work out that I was only using 5 of the images, 
and so wouldn't do anything with all the others. However, GWT appears to open 
all the image files and do something with the data. The compilation could have 
been faster if it had identified which ones were used first, and only did 
something with them. Is this a bug, or an unfortunate but necessary side-effect 
of the way ClientBundle works?

I've now rewritten my code so that the bundle interface only includes the 
images I actually use.

Item (2) is covered by this issue:
http://code.google.com/p/google-web-toolkit/issues/detail?id=6507

but I couldn't find any open issue for (1). Should I open an issue, or is it 
just the way it has to work?

Thanks,
Paul

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: png compression

[Paul Robinson]

No reply on this, so I've just created issue 5651 so it doesn't get 
lost. It would be nice if the GWT compiler could produce png image 
bundles in compressed format.


Background: The png file format has support for the deflate algorithm 
built-in, but png files don't *have* to use it. So some png files will 
contain compressed data, while others will not. GWT with an 
out-of-the-box JDK do not generate compressed png files.


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

Thanks,
Paul

On 03/11/10 00:13, Paul Robinson wrote:

I've just started using this colour picker:
http://code.google.com/p/auroris/wiki/ColorPicker

One of the warnings its documentation provides is that when you 
compile it with GWT, the images it contains are compiled into a png 
file that is about 1MB. Whereas, if you then open that file in any 
image processing software and re-save it, it compresses down to around 
110kb.


The problem is that during the compile, GWT's ImageBundleBuilder uses 
javax.imageio.Imageio.write(BufferedImage, "png", outputStream), and 
with an out-of-the-box JDK installation, the javax.imageio.Imageio 
stuff does not support png compression. (png has support for the 
deflate algorithm built-in, but it seems you don't *have* to use it 
when writing out png files)


However, by installing an additional package to add to my JDK, I 
managed to get a gwt compile to produce compressed png files:

http://download.java.net/media/jai-imageio/builds/release/1.1/INSTALL-jai_imageio.html#Manual

Some of my small png files got slightly bigger, but that 1MB png got 
much smaller.


This is a known bug in the JDK, and there's a bug report here:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4829970

but that's a very old bug report, so may not be fixed any time soon.

Is this something that GWT could address, so that this would work 
correctly out-of-the-box?


Thanks,
Paul


--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] png compression

[Paul Robinson]

I've just started using this colour picker:
http://code.google.com/p/auroris/wiki/ColorPicker

One of the warnings its documentation provides is that when you compile 
it with GWT, the images it contains are compiled into a png file that is 
about 1MB. Whereas, if you then open that file in any image processing 
software and re-save it, it compresses down to around 110kb.


The problem is that during the compile, GWT's ImageBundleBuilder uses 
javax.imageio.Imageio.write(BufferedImage, "png", outputStream), and 
with an out-of-the-box JDK installation, the javax.imageio.Imageio stuff 
does not support png compression. (png has support for the deflate 
algorithm built-in, but it seems you don't *have* to use it when writing 
out png files)


However, by installing an additional package to add to my JDK, I managed 
to get a gwt compile to produce compressed png files:

http://download.java.net/media/jai-imageio/builds/release/1.1/INSTALL-jai_imageio.html#Manual

Some of my small png files got slightly bigger, but that 1MB png got 
much smaller.


This is a known bug in the JDK, and there's a bug report here:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4829970

but that's a very old bug report, so may not be fixed any time soon.

Is this something that GWT could address, so that this would work 
correctly out-of-the-box?


Thanks,
Paul

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] RPC vs DeRPC in 2.1

[Paul Robinson]

stuckagain wrote:
> GWT contributors,
>
> Will there be a production quality RPC mechanism available in GWT 2.1
> as part of the RequestFactory stuff ? Or do we still have to suffer
> the stackoverflow inducing RPC implementation ?
>
> I'm currently fighting to get RPC to work with a tree structure that
> is not that big in bytesize, but it has about 20 levels of nesting in
> my example. RPC on IE6/7/8 just shokes on it, but no warning is shown.
> I just don't get all the data - which is very disturbing.
>   
This may not be the same problem, but you might want to check out this
issue:
http://code.google.com/p/google-web-toolkit/issues/detail?id=3577

It describes how it's possible for references to objects within a set or
map to be lost during deserialization.

Paul

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: RR: allow CheckBox to accept null?

[Paul Robinson]

Having Checkbox.getValue() able to return null would probably break a
lot of code. For example:
if (cb.getValue())
   doSomething();

Paul

Andrew Pietsch wrote:
> It prefer it if it returned null instead.  i.e.
>
> CheckBox cb = new CheckBox();
>
> cb.setValue(null);
> assertNull(cb.getValue()); // and assert a ValueChangeEvent fired
> with null
>
> Having said that my NullSafeCheckBox converts nulls to false as you
> proposed, so it works but it's not ideal.  Also HasValue's that mutate
> their value during setValue seems to me to be a tricky/painful/
> impossible problem to solve for automatic bi-directional bindings so
> I'm keen to avoid it if possible.
>
> Cheers
> Andrew
>
> On Aug 27, 11:02 am, Ray Ryan  wrote:
>   
>> Andrew, how would this be?
>>
>> CheckBox cb = new CheckBox();
>>
>> cb.setValue(null);
>> assertFalse(cb.getValue());
>>
>> rjrjr
>>
>> On Thu, Aug 26, 2010 at 5:57 PM, Andrew Pietsch 
>> wrote:
>>
>> 
>>> I personally would like to see it support null, not because null is a
>>> valid UI state but just to be consistent with all the other widgets.
>>> As far as pectin is concerned the bindings always created before the
>>> real value arrives so wigets are aften set to null. I've tried to
>>> avoid wiget specific logic in the core bindings as much as possible
>>> (it's a slippery slope to ugliness) and CheckBox is the odd one out.
>>> As a somewhat silly thought would a marker interface be an option i.e.
>>> perhaps something like `CheckBox implements HasValue, BarfsOnNull` so
>>> there's at least a mechanism to find out?
>>>   
>>> On Aug 26, 6:00 pm, Johan Rydberg  wrote:
>>>   
 On 8/25/10 6:16 PM, Ray Ryan wrote:> The use case is dealing with boolean
 
>>> values that may benull, and
>>>   
> really a check box is just the wrong UI there. Withdrawn.
>   
 I know of at least one data binding framework, gwt-pectin, that signals
 "no value" usingnull. As a work-around gwt-pectin has it's ownCheckBox
 impl that acceptsnull.
 
 Take this example; We have a master-detail interface.  aCheckBoxhas
 been bound to "selectedElement.male".  If there is not a selected
 element, a "no value" signal should be sent down through data binding,
 not "False". Right?
 
 But then again, there's really no way to communicate something like a
 placeholder value for acheckbox.  But I still
 
>>> thinkCheckBoxshouldacceptnull, for the interface to be consistent.
>>>   
>>> --
>>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>>   
>> 
>
>   

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Interest in Wave for design docs?

[Paul Robinson]

Yes please.

> Reply to this thread if you'd like to get an invitation. 
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: r7517 committed - Adding RegExp to public GWT (native version, pure Java version, tests)

[Paul Robinson]

I'd hate to see even more discussions moving away from here (because I,
and maybe quite a few others here, don't have access to Wave).

Paul

Ray Ryan wrote:
>
> We can use the public Wave instance with alternate addresses.
> Inconvenient, but it's not that big a deal.
>
>  

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] InsertPanel change to AbsolutePanel breaks GlassPanel

[Paul Robinson]

AbsolutePanel.add(Widget,int,int) used to append widgets, the same as
AbsolutePanel.add(Widget) still does now. Following rev 6070/6071, it
now inserts instead, and not always at the end. This caused a problem
for me because I'm using this method to add a GlassPanel using
RootPanel.get().add(glass,0,0), and trunk after 6070 means that the
glass panel isn't in front of all the things it's meant to be in front
of because it's been inserted in the wrong place.

It used to say this:

  public void add(Widget w, int left, int top) {
w.removeFromParent();
setWidgetPositionImpl(w, left, top);
add(w);
  }

but was changed to say this:

  public void add(Widget w, int left, int top) {
w.removeFromParent();
int beforeIndex = getWidgetCount();
setWidgetPositionImpl(w, left, top);
insert(w, beforeIndex);
  }

The reason this fails for me is that not everything in the panel is a
widget, so RootPanel.get().getWidgetCount() returns a number smaller
than DOM.getChildCount(RootPanel.get().getElement())

I presume that this is a bug and not a feature. Reverting this one
method looks like the right thing to do to me.

I created issue 4073 for this:
http://code.google.com/p/google-web-toolkit/issues/detail?id=4073

Paul

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: RPC HashSet & HashMap deserialization bug/limitation

[Paul Robinson]

I've created an issue for this:
http://code.google.com/p/google-web-toolkit/issues/detail?id=3577

The issue includes a complete code example demonstrating the problem
(written for GWT 1.6.4), together with a detailed explanation of what
happens during deserialization to cause the effect.

Paul

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: RPC HashSet & HashMap deserialization bug/limitation

[Paul Robinson]

Cycles are handled properly - the problem comes with calling methods on
partially formed objects during deserialization. It doesn't matter how you
implement equals or hashCode if those methods are called before any data is
deserialized onto your objects. You just need a suitable object graph for
this to show itself.

On Fri, Apr 17, 2009 at 1:01 AM, Miroslav Pokorny <
miroslav.poko...@gmail.com> wrote:

>
> If one were to serialize the entries rather than recreating the map
> via put alot of other things would need to be changed.
>
> For one the calculation of hashcodes in emulated jre would need to
> match those on the server otherwise look ups by string in a hashmap
> sent over the wire would never work. Which jre would one base
> calculation a on - I say this because wire formsts can and do chsnge -
> which is why serialUID exists etc . We don't need to introduce that
> into gwt serialization and make things more complicated and bloated.
>
> Unfornately javascript is not the fastest ultimately to improve
> serialization performance in javascript one needs to to sensible
> things like tailoring what gets marshalled. The browser has limits and
> one needs to do the hard work and change accordingly...
>
> Um peetty sure gwt handles cycles properly without problems - perhaps
> your objects in the map / set are changing in some way or your equals/
> hashcode is broken.
>
> Regarding your problem gave you confirmed serializi g the same
> instances to bytes and back in real java???
>
> Hth.
>
> On 17/04/2009, at 2:04 AM, Paul Robinson  wrote:
>
> >
> > I've found what I think is a bug in the RPC deserialization code for
> > handling HashSet and HashMap in GWT 1.5.3 (though I believe it applies
> > to trunk as well). The symptoms I had initially were that I sent an
> > object tree to the client, and a HashSet that had 2 elements on the
> > server only had 1 by the time it got to the client.
> >
> > When deserializing, an instance is created, stored in a map so
> > repeated
> > references can use the same instance, and then the fields of the
> > instance are  deserialized.  If you have an object tree where A
> > contains
> > a reference to something that has a reference to B, and B contains
> > something that has a reference to a HashSet that contains both A and
> > B,
> > then when deserializing the set, both A and B may only be partially
> > constructed (depending on the order in which the fields and instances
> > are deserialized). This would be ok except that HashSet
> > deserialization
> > is done by Collection_CustomFieldSerializerBase which ends up calling
> > HashSet.add(Object) to reconstitute the set, and that in turn calls
> > equals() and hashCode() on the object being added in.
> >
> > This gives rise to two possible errors:
> > (1) Depending on how the equals() method on A and B is implemented and
> > on the order in which the fields are deserialized, A.equals(B) may be
> > true at the time that A and B are added to the set. However,
> > A.equals(B)
> > could later evaluate to false once the whole deserialization has
> > completed. This would mean the set is missing one of the objects,
> > since
> > HashSet.add() thinks they are the same.
> >
> > (2) When adding an object to a HashSet or HashMap during
> > deserialization, if the object being added is partially constructed,
> > then the hashCode() method may return a different value as it is added
> > to the set from what it does when deserialization is complete. This
> > could lead to occasional data-driven bugs that are very hard to
> > track down.
> >
> > Have I got this right? Is this a bug (or perhaps a known limitation)?
> >
> > In my case, I have been able to work around this by creating a custom
> > field serializer that chooses the order in which fields are written
> > out
> > so that partially constructed objects will still behave properly in a
> > HashSet/HashMap.
> >
> > Paul
> >
> >
> > >
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: RPC HashSet & HashMap deserialization bug/limitation

[Paul Robinson]

I think the solution is:
(1) HashMap_CustomFieldSerializer should write out all the fields within a
HashMap - ie including the hashes. The real problem here is that
Map.put(key, value) is used to rebuild a map.
(2) HashSet_CustomFieldSerializer should do something similar - this means
writing out the private map stored within the hash set.
(3) Any other set/map implementation needs to be looked at in case they
suffer from similar problems.

I imagine plain old java serialization probably does it this way - just dump
the raw fields. The above would mean sending more data on the wire, but you
wouldn't have to compute hash codes and equals(), so things may balance out
performance-wise.

Paul

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] RPC HashSet & HashMap deserialization bug/limitation

[Paul Robinson]

I've found what I think is a bug in the RPC deserialization code for
handling HashSet and HashMap in GWT 1.5.3 (though I believe it applies
to trunk as well). The symptoms I had initially were that I sent an
object tree to the client, and a HashSet that had 2 elements on the
server only had 1 by the time it got to the client.

When deserializing, an instance is created, stored in a map so repeated
references can use the same instance, and then the fields of the
instance are  deserialized.  If you have an object tree where A contains
a reference to something that has a reference to B, and B contains
something that has a reference to a HashSet that contains both A and B,
then when deserializing the set, both A and B may only be partially
constructed (depending on the order in which the fields and instances
are deserialized). This would be ok except that HashSet deserialization
is done by Collection_CustomFieldSerializerBase which ends up calling
HashSet.add(Object) to reconstitute the set, and that in turn calls
equals() and hashCode() on the object being added in.

This gives rise to two possible errors:
(1) Depending on how the equals() method on A and B is implemented and
on the order in which the fields are deserialized, A.equals(B) may be
true at the time that A and B are added to the set. However, A.equals(B)
could later evaluate to false once the whole deserialization has
completed. This would mean the set is missing one of the objects, since
HashSet.add() thinks they are the same.

(2) When adding an object to a HashSet or HashMap during
deserialization, if the object being added is partially constructed,
then the hashCode() method may return a different value as it is added
to the set from what it does when deserialization is complete. This
could lead to occasional data-driven bugs that are very hard to track down.

Have I got this right? Is this a bug (or perhaps a known limitation)?

In my case, I have been able to work around this by creating a custom
field serializer that chooses the order in which fields are written out
so that partially constructed objects will still behave properly in a
HashSet/HashMap.

Paul


--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: code-splitting user manual

[Paul Robinson]

Lex Spoon wrote:
> At long last, I have started a wiki page on how to use GWT.runAsync.
> It covers the basics, how to use SOYC to iterate to something better,
> and a couple of recommended coding patterns.
>
>   http://code.google.com/p/google-web-toolkit/wiki/CodeSplitting
>
> Thoughts welcome.  Or, gee, it's a wiki.  Just go improve it.  :)
>
> Lex
>   
Can you give a code example that shows what would qualify as exclusive,
base or leftovers? It's not clear to me what would consistute each
category. In the leftovers description, it makes a passing reference to
"the second split point", but I can't quite work out whether that should
be "a second split point" or whether secondary split points are what
help create leftovers.

Paul

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Compiling trunk on linux 64 bit - OOME

[Paul Robinson]

I have a shiny new machine 64 bit linux box to make my GWT compiles go
faster. However, it fails to compile trunk rev 4585, despite it
compiling ok on windows 32 bit. The failure was an OOME while compiling
showcase. So I played around with the settings in samples/common.ant.xml
to set different values for -Xmx. For those compiles that worked, I made
a note of how long it took as well. This is what I got:

-Xmx256M   (the default) OOME
-Xmx268M OOME
-Xmx274M compiled showcase in 4 mins 42
-Xmx300M compiled showcase in 3:28
-Xmx512M compiled showcase in 2:28

All the above was without modifying anything else (so no multithreaded
or multi process args).

I think either the default amount of memory needs to be increased so
this can compile on 64 bit, or else you might just view this as another
symptom of the increased memory requirements of 1.6 that needs to be fixed.

I am running:
OS: Ubuntu 8.10 64 bit
JDK: Sun 1.6.0_10 64 bit server VM
CPU: Intel Core i7 920

Paul

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Safari/Chrome FocusPanel inside ScrollPanel

[Paul Robinson]

I have found what I think is a bug in the interaction between FocusPanel
and ScrollPanel on Safari and Chrome. What I'm seeing is that when you
create a FocusPanel and put it inside a ScrollPanel, clicking inside the
focus panel cause the scroll panel to scroll to the top.

I think that what's happening here is that the browser is scrolling to
bring into view the hidden input element that FocusImplSafari creates.

I'm seeing this in GWT 1.5.2. I found a similar issue here (although
this is marked fixed):
http://code.google.com/p/google-web-toolkit/issues/detail?id=1313

Here's a code snippet that shows the necessary parts to make the bug
happenjust run this in web mode on safari or chrome, scroll the
window down a bit, then click on one of the labels to see the window
scroll back to the top.

public class FooPanel extends DockPanel {

public FooPanel() {
VerticalPanel ap = new VerticalPanel();
for (int i = 0; i < 50; i++) {
ap.add(new Label(Integer.toString(i)));
}
   
MyFocusPanel focus = new MyFocusPanel();
focus.setWidget(ap);

super.add(new ScrollPanel(focus), DockPanel.CENTER);
}
}

// you can use the normal FocusPanel to show the bugthis just shows
it's the FocusImpl that's the problem
class MyFocusPanel extends SimplePanel {

  static final FocusImpl impl = FocusImpl.getFocusImplForPanel();

  public MyFocusPanel() {
super(impl.createFocusable());
  }
}

Paul

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: TimePicker/ValueSpinner bug

[Paul Robinson]

Done.

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

Paul

Emily Crutcher wrote:
> Can you file a bug report? That way I can assign it appropriately. 
>
> On Wed, Oct 1, 2008 at 6:39 AM, Paul Robinson <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
>
> I don't know whether TimePicker is going to be reworked into gen2 as
> well as DatePicker, but I've found a bug in the current incubator
> version of TimePicker. It's in the ValueSpinner constructor. It adds a
> text box, then sets the vertical alignment for the ValueSpinner, then
> adds the spinner. On IE this displays normally, but on chrome and
> firefox the text box vertical alignment is inconsistent with the
> rest of
> the line.
>
> The solution is to move the call to
> "setVerticalAlignment(ALIGN_MIDDLE);" to be before the text box is
> added
> (just swap lines 157 & 158)
>
> I also had problems with ValueSpinner's use of
> StyleInjector.injectStylesheet() on IE. This is deprecated anyway,
> so I
> presume any reworking would replace this. I removed StyleInjector from
> my copy of ValueSpiiner.
>
> HTH
> Paul
>
>
>
>
>
> -- 
> "There are only 10 types of people in the world: Those who understand
> binary, and those who don't"
>
> >

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] TimePicker/ValueSpinner bug

[Paul Robinson]

I don't know whether TimePicker is going to be reworked into gen2 as
well as DatePicker, but I've found a bug in the current incubator
version of TimePicker. It's in the ValueSpinner constructor. It adds a
text box, then sets the vertical alignment for the ValueSpinner, then
adds the spinner. On IE this displays normally, but on chrome and
firefox the text box vertical alignment is inconsistent with the rest of
the line.

The solution is to move the call to
"setVerticalAlignment(ALIGN_MIDDLE);" to be before the text box is added
(just swap lines 157 & 158)

I also had problems with ValueSpinner's use of
StyleInjector.injectStylesheet() on IE. This is deprecated anyway, so I
presume any reworking would replace this. I removed StyleInjector from
my copy of ValueSpiiner.

HTH
Paul

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---