My experience of coding a GWT webapp (~900 classes, ~20 GWT modules)

53 views
Skip to first unread message

Khun Yee Fung

unread,
Jul 30, 2008, 12:39:19 PM7/30/08
to Google Web Toolkit
We put our GWT-based job site (http://www.careercommons.com) in
production on Monday. This is a summary of my experience coding the
whole thing in GWT. Not sure how useful this is for other people, but
here it goes:

Some statistics:
------------------------
1. It has about 900 classes, including all the interface classes, data
transfer classes, etc. Not a big system for a team, but not a small
system for two people.

2. We have about 17 GWT modules, as one module would take too long to
load for this kind of application, in our opinion. It takes about 18
minutes to compile on my Windows machine, and 1 minute longer on my
newer and much faster Linux machine, which baffles me no ends. Why is
JDK faster on Windows? I am curious about the speed of compiling GWT
on a Solaris machine now.

3. It took six months to code. It was mostly done by me, with a friend
helping here and there. And it was my decision to use GWT. And I can
honestly say that without GWT, it would have taken a lot longer than 6
months, and the result would be much worse.

4. We use OpenOffice as the backend to generate Microsoft Word and PDF
documents. So, we have to create ODT documents on the fly. We have to
convert some data from HTML entered by the user into the RichTextArea
widget. The HTML to ODT capability is quite limited right now, but
will be improved as time goes on.

5. We use Tomcat 6.0.16 on the server side. As a production system, it
has its problems. But after using Tomcat for the last 8 years, we sort
of know what to expect and what to avoid.

6. We use postgres 8.3.3. as the database. In our pre-production
period, we were patching the database from deployment to deployment to
figure out the character of the system (every system reacts
differently in production, and we wanted to learn that character
before putting the system in production), and PLPerl is really good in
handling data migration on the fly. Underpowered (try passing arrays
in as parameters), that is for sure, but easy to handle.

Lessons learnt
------------------------

Now, these are lessons learnt by me coding this application. They
might not apply to your situations. And they are really common sense.
If you don't agree with them, I am all ears.

1. Can't reuse data transfer classes. Initially, we had general
purpose data transfer classes between the database and the browser.
Then we found out that we are transferring way too much information,
and data security was getting scary. So, mid-way, we decided to have
data-transfer classes that are tailored for particular remote methods.
Both approaches have their disadvantages, of course, but I am happier
now as I don't have to worry as much about data being leaked to the
wrong side.

2. (Non-GWT) JPA is godsend in 90% of what we need to do with a
database. For the other 10%, it is a drag. We use Hibernate first and
then OpenJPA, the performance for some operations is still not good
enough for me. JPA is doing too much sometimes (fetching stuff not
needed), and too little in other times (not fetching stuff that is
needed almost right away). But no system can read the programmer's
mind, so I am extremely grateful to be able to use JPA for the 90%,
and I have no problem coding by hand the other 10%. The only thing is
that refactoring is made harder by JPA, as the queries are in
strings.

It would be nice to have a tool that allows programmers to code in
Java for the queries, to make refactoring of the entity classes
easier. But then that will need a GWT-like compiler to make it
possible to write queries in Java, so that people can develop and
debug in the Java mode, and then compiled into JDBC or JPA queries
strings for a "production-mode". Sounds like an interesting project to
me.

3. GWT 1.5 is easier to handle than GWT1.4. The system was in GWT1.4,
and I moved it to GWT1.5 to anticipate the next version of GWT. But we
could not stay with 1.4, as the generics and annotations are simply
too valuable for refactoring. The lesson learnt is that even though we
don't create our own generics, just as a compilation checking tool and
its ability to facilitate refactoring for GWT, it is worth it.

4. Test the browsers. Don't assume everything will work in the same
way. We did have to avoid some browser problems, like one time we were
causing Opera to crash consistently over some HTML produced by MS
Word. That is not a GWT issue, of course, it is an Opera issue (it
should not crash when fed with that HTML), and our issue (we should
not feed Opera HTML that it is going to choke on). And the other time,
when we crashed IE with the PushButton widget; this is a GWT issue, as
it should not crash IE, and it is IE's issue, as it should not crash,
period. But compared to what we would have to handle hand-coding
JavaScript, these are minor issues.

The other thing is, if you have a lot of information to display, the
browsers don't display them in the same way. For instance, Firefox
would display information when it comes, IE would display only after
all the information has arrived, etc. So, a progress widget is easy to
code for Firefox, but much tougher for IE.

Other thoughts
---------------------

We are not usability experts, and we are not graphic designers either.
But because of the interactivity allowed by JavaScript (via GWT), we
wanted to build a system that is clean, and made the editing
operations in-place, so that the user's attention does not have to
switch to a new page, and then back, whenever they want to do
something. Instead, they will look at the same widgets when
information is displayed, and when they want to change the information
being displayed. I think we accomplished that.

For the site, we aimed to make the UI as clutter-free as possible, and
make the different operations available as cleanly as possible. I
think we succeeded in those two goals as well. But see for yourself,
as the site is free for everyone. Obviously, we have just started, and
we have not started to talk to companies and recruiters yet, so there
are no job postings right now. But you can enter information, and see
how the information is displayed, edited, etc.

If you did try the site, please let us know what you think of it. We
value your suggestions, criticisms, and comments very much.

Obviously, whether the site is going to be successful really does not
depend on what toolkit we used to code it.

Khun Yee

Roger Marin

unread,
Jul 30, 2008, 1:07:09 PM7/30/08
to Google-We...@googlegroups.com
Nice work Khun!

Have you guys thought about open sourcing your app or part of it?, i'm really interested in the OpenOffice integration you talked about seems really cool.

Roger Marin

2008/7/30 Khun Yee Fung <khunye...@gmail.com>

WadeC

unread,
Jul 30, 2008, 1:39:50 PM7/30/08
to Google Web Toolkit
Khun,

Looks like an impressive site...

Can you expand on #5 and give some more details on the problems of
running a TomCat production server and how you managed to get around
these issues.


Thanks,

WadeC

sim123

unread,
Jul 30, 2008, 2:25:06 PM7/30/08
to Google Web Toolkit
Hello,

Nice post specially the "lesson learnt" section, did you use GWT RPC
for data transfer? if so how is your experience with that? And why did
you choose GWT RPC over JSON transfer?

Thanks.

Khun Yee Fung

unread,
Jul 30, 2008, 10:12:42 PM7/30/08
to Google Web Toolkit
We might open source the whole thing later.

About OpenOffice integration. We use JODConverter as the communication
library between our system and OpenOffice. It is LGPL licensed. It is
good enough for us right now, as we are getting DOC and PDF out of it.
We run OpenOffice as a server.

We create ODT on the fly, using JDOM to create content.xml, style.xml,
and metadata.xml; then we create the ODT file using the standard Java
library. A ODT file is really a ZIP file, containing these XML files
and other resources.

Creating the content.xml file inside an ODT file took the longest
time, translating HTML to ODT, and making sure the result looks
similar. We only have a simple CSS parser right now; we will improve
that, and eventually make it a full-fledged HTML+CSS to ODT later. If
that thing is half-decent and useful, I will open source it.

Khun Yee

On Jul 30, 1:07 pm, "Roger Marin" <rsman...@gmail.com> wrote:
> Nice work Khun!
>
> Have you guys thought about open sourcing your app or part of it?, i'm
> really interested in the OpenOffice integration you talked about seems
> really cool.
>
> Roger Marin
>
> 2008/7/30 Khun Yee Fung <khunyee.f...@gmail.com>

Khun Yee Fung

unread,
Jul 30, 2008, 11:12:18 PM7/30/08
to Google Web Toolkit
I used GWT RPC. It has everything I needed, so I never used JSON. But
that reminds me to check JSON out again.

Khun Yee

Khun Yee Fung

unread,
Jul 30, 2008, 11:23:25 PM7/30/08
to Google Web Toolkit
Well, in my previous life, I was responsible for a software-as-a-
service system. We deployed at least once a week, and we had multiple
clients on one tomcat, even though we had a few tomcat servers. The
clients ran essentially the same code. We used to run everything on
Windows, and gradually we moved to Linux. So, we had a few interesting
problems with Tomcat in that kind of environment.

For instance, when we were using the DBCP in tomcat to manage the
connection pool for us, one time, we had a client seeing the database
of another client. Apparently, Tomcat mixed up some connections. Could
not reproduce the problem, but we used a separate connection pool for
each client after that.

When we were moving from Windows to Linux, at one time, we had a
Tomcat server running on Windows and Apache HTTPD running on Linux,
with Jk connecting them. Tomcat ran out of memory about every hour.
Ruined my Christmas trying to prove to our VC that even though hundred
of thousands of websites ran Apache+Tomcat and having no problem, that
problem was real, and only happened if the combination was precisely
that.

And so on. I doubt it is interesting for other people to read these
environment specific issues with Tomcat, which is off-topic for this
group, I think.

Don't get me wrong. I love Tomcat. It made my life much easier. I only
have praises, thanks, and compliments for the Tomcat guys. I would use
Tomcat in production with no hesitation. Especially now that I know
how what to look out for.

Khun Yee

AstroIvan

unread,
Aug 1, 2008, 10:27:47 AM8/1/08
to Google Web Toolkit
Excellent breakdown Khun, thanks for posting your experience.
> > > Khun Yee- Hide quoted text -
>
> - Show quoted text -

Adam Malter

unread,
Aug 1, 2008, 11:22:40 AM8/1/08
to Google Web Toolkit
Great post Khun!

We are also in the midst of a GWT production rollout and seeing
similar positives and negatives is comforting.

Anybody know if a compiler optimization is on the GWT guys roadmap?
Every time I see it brought up I hear the "Well, why aren't you using
hosted mode" or whatever line, but we also are starting to feel the
development time and build time squeeze.

Does anybody have any experiences with compile speed differences
between 1.4 and 1.5? We are seeing about a 15% slowdown, even with the
pruning of linkers and targets. For now it's okay to hand the build
over to our big honking CruiseControl machine, but, with a couple
dozen additional modules planned, and maybe translation into 3-4
languages, I'm worried GWT could end up being the majority of our
build process. Also, I'm dismayed to hear the performance difference
your seeing on Linux vs Windows. Our current build box is Win2003, but
we've had a plan to migrate over to CentOS. A performance regression
of that magnitude could cause us to reconsider. Has anyone else
experienced this?

Anyway, thanks again Khun for sharing your experiences. You shame
those of us that don't contribute our lessons learned back to the
community. (*cough* got to get off my butt and write one also *cough*)

Adam Malter

Dale

unread,
Aug 1, 2008, 1:56:10 PM8/1/08
to Google Web Toolkit
ad #2: While you were using Hibernate, did you try using using
Hibernate Criteria API? That should allow you to do queries in Java,
and the would be changed during refactoring.

Cheers,
Dale
Message has been deleted

Maxim

unread,
Aug 1, 2008, 4:27:26 PM8/1/08
to Google Web Toolkit
On Aug 1, 7:22 pm, Adam Malter <amal...@illegalcheese.com> wrote:

>Does anybody have any experiences with compile speed differences between 1.4 and 1.5?

Affirmative, 1.5 ~ 20% slower then 1.4, though we do not use 1.5 in
production yet, just made some investigation attempts.

> dozen additional modules planned, and maybe translation into 3-4
> languages, I'm worried GWT could end up being the majority of our
> build process.

Same to us ( http://www.triniforce.com/pk.html ). Slow compilation was
one of the reason why we decided not to use standart GWT i18n
approach. We keep dictionaries in database, it gives the following
obvious advantages:
1) Only one compilation
2) Customer is able to add/modify localization ( our app is
redistributable one ).

Of course this is for price of additional coding and debugging.

> Our current build box is Win2003, but we've had a plan to migrate over to CentOS. A performance regression of that magnitude could cause us to reconsider.

Perfomance difference indeed can take place, moreover I must admit
that moving between platforms is not quite seamless even if you use
Java. I spent one working day just making sources (~ 1200 classes ) to
be compilable on Linux.

Regards,
Maxim

Khun Yee Fung

unread,
Aug 2, 2008, 9:47:07 AM8/2/08
to Google Web Toolkit
For me, the build time is a concern only when I need to build the
whole system. That happens only when I modify the base class of the
RPC return type (so that I can have only one set of interfaces to
handle all modules, and 3 classes/interfaces per module because I need
a literal class name for the service class); and common elements used
by all the modules are modified[1].

For day-to-day compilation for development, I have Ant targets that
compile only one module, or a set of related modules. So, in general,
it takes me 1 to 2 minutes to compile the newly modified module. And
if only the server side has been modified, then, of course, it would
take about 15 seconds to compile the server side. And building for
production is again not an issue.

The common things that I do with the module compilation targets are
compiling the Java classes and the bundling of the war file. And I
keep the previously compiled modules intact. If their classes have not
been changed, I don't need to compile them again.

So, not really a problem in almost all cases. I tend to compile the
whole thing probably fewer than five times a day.

What baffled me was the speed difference between Windows and Linux. On
the other hand, I don't have enough machines to do benchmarks and no
inclination to find out why the difference between the operating
systems myself. I have the machines that I have; I will deal with
that. But it is intriguing to know whether it runs faster on Solaris,
as I expect JDK to be more optimized on that OS.

And of course, when I compile on Windows, GWT compiler takes more or
less 100% CPU. And the only activity I can have during compilation is
to read Groklaw and Slashdot. Hence the attempt to use my Linux
machines to compile (all my other machines are Linux machines).

Khun Yee
[1] It would be nice to be able to have multiple modules on the same
page. That would save some of the compilation time for modules with
common elements. I tried it on 1.4, and it did not work (alpha
substitution does not cross module boundary?). I have yet to try it on
1.5 Does it work on 1.5?

On Aug 1, 4:27 pm, Maxim <maxim...@gmail.com> wrote:
> On Aug 1, 7:22 pm, Adam Malter <amal...@illegalcheese.com> wrote:
>
> >Does anybody have any experiences with compile speed differences between 1.4 and 1.5?
>
> Affirmative, 1.5 ~ 20% slower then 1.4, though we do not use 1.5 in
> production yet, just made some investigation attempts.
>
> > dozen additional modules planned, and maybe translation into 3-4
> > languages, I'm worried GWT could end up being the majority of our
> > build process.
>
> Same to us (http://www.triniforce.com/pk.html). Slow compilation was

Khun Yee Fung

unread,
Aug 2, 2008, 10:00:22 AM8/2/08
to Google Web Toolkit
To tell you the truth, I knew I was going to move away from Hibernate,
sooner or later. Nothing against Hibernate, I was just uneasy about
JPA in general, about my ability to use JPA effectively, and the
amount of time it would take me to tune it correctly. So, anything
that is not easy to move away from, I did not use.

I like Hibernate, especially since its caching (EHCache) and
connection pooling (c3p0) work. I have some issues with OpenJPA
caching and connection pooling. In any case, there is a huge
refactoring coming for me, if the traffic of the site gets to a
certain level. And it will have something to do with database access.
Just the nature of the beast.

Khun Yee
Message has been deleted

Maxim

unread,
Aug 2, 2008, 10:19:30 AM8/2/08
to Google Web Toolkit
On Aug 2, 5:47 pm, Khun Yee Fung <khunyee.f...@gmail.com> wrote:

>So, in general, it takes me 1 to 2 minutes to compile the newly modified module.

You are right, if system is spited into dozen modules then in normal
circumstances compilation time it is not a problem. But if you have
fewer modules and you are fighting with browsers incompatibility - the
problem raises. Unfortunately appearance in hosted mode is not 100%
trusty ...

Maxim

Khun Yee Fung

unread,
Aug 2, 2008, 11:20:25 AM8/2/08
to Google Web Toolkit
I totally agree with you.

I used the hosted mode extensively in the beginning of my development
for my GWT projects. But once I started to have a database and
multiple modules, the hosted mode takes a while to start up (I am
eagerly awaiting the removal of @gwt.typeArgs support, that seems to
be the main reason with the long start-up time, or so I read/
listened). The refresh button seems to take longer to start up some of
my modules than simply re-run the module in many situations, and
sometimes it would not even come up properly. And I need to wire the
module correctly to add session support, by using a filter just for
the hosted mode (so I have two web.xml files, one for the real tomcat
server, and one for hosted mode). So, tons to do to get hosted mode
working for a module for me. But hey, my situation is just weird, and
I am totally happy to be able to debug at all in Java mode. I could
not imagine how much time I saved by using GWT just for that one thing
alone.

And you are also right in saying the appearance in hosted mode is not
the same as in the browsers themselves. But I don't use the hosted
mode to test/debug appearances and layouts. I tried testing the
appearances and layouts in the individual browsers.

Khun Yee

Ian Bambury

unread,
Aug 2, 2008, 12:26:10 PM8/2/08
to Google-We...@googlegroups.com
Hi Khun,
 
I've been looking at your site, and I'm sure a lot of hard work has gone into it. But there is room for improvement. Don't read on if you have a thin skin, I'm going to be honest.
 
No way to remember logon so you get timed out if you go to make a cup of coffee, you have to retype your email and password from scratch (autocomplete, autofill and remembering passwords are not catered for). It's only a job application system, it's not a bank account, you lose all the information you were typing in, and, more to the point, I'm the only person in the house, so who are you saving me from?
 
Top level menu items are reselectable
 
Top level menu items don't indicate selection
 
One of the top level menu items (policies) is different in appearance and in a different place in the layout.
 
Secondary level menu items block top level menu items and won't go away without a click somewhere on the page.
 
Headers are the same colour as menu items
 
Some selected buttons are the same colour as menu items
 
Some unselected buttons are identical to input labels
 
Text boxes and list boxes are identical to header lines
 
Many of the features are very cryptic ("Visibility J A C E" for example)
 
Tooltips sometimes hang around for ever and just won't go away
 
Tooltips cover one another and get stuck on-screen while blocking buttons.
 
Button mouse-over appearance a) appears when you go to a new page sometimes b) doesn't always get removed
 
Some titles are styled the same as some of the buttons
 
Some pages are not at all self explanatory, e.g. this page (in full)
 
------------------------------
INVITATIONS
Invitations
There are no invitations
© Mivanti Systems Inc. 2008
------------------------------
 
What are peoiple supposed to make of that?
 
Action buttons (e.g. Add Resume) are right over on the RH side of the screen while all information and the other buttons (apart from 'Help) are right over on the LH side
 
Location defaults to "AB Canada" i.e. you didn't bother to set up 'Please enter your...' list items.
 
Although there is a theme (i.e. there is one colour) there is still no standardised approach (e.g. some buttons have links, some don't some are blue, some are white and either way, they look like other elements on the page).
 
It is not obvious how to use the pages that appear
 
It is not easy to use even when you realise what you are supposed to do
 
Options are strange (why would a job applicant want to add a 'good to have' skill on a CV?)
 
Functionality is weird - you can save an unusable query for example, and you can try to use it. But if you do, you get something like "Please enter at least one location and one skill/technology" but there is no way to enter the skill, no indication how to do it (unless you happen to try clicking the blue, undecorated query name, and if you didn't enter a query name, there is absolutely no way to edit the query).
 
Compared to what can be done these days, it has a very 80's, very claustrophobic, bent-coathanger-string-and-glue feel about it. E.g. in preferences, click to edit password (you get shown three textboxes), then click the top edit button (to edit preferences), and you get told "Concurrent editing - Something else is being edited." and disallowed to do it. Why? What's the problem?
 
Why do I have to enter a city to do a search? What if I'm willing to travel/relocate?
 
Why can't I limit my searches to, say I.T?
 
Why do I need to add my contact info before I can add a resumé?
 
Why do I have to write my resumé from scratch instead of being able to upload it?
 
What is the point of multiple resumés whn there is only ever one version of any of the sections allowed?
 
How does the one I wrote from scratch get integrated with the stuff I enter in the data entry pages?
 
Because you use different module, you lose (without warning) anything you are entering if you navigate away within your site.
 
There are other things, but I'll leave it at that - I never managed to find a job, so I didn''t get any further than this, and I didn't look at the employer side.
 
All in all, it looks naff, it's difficult (sometimes impossible) to understand how to do what you want to do, and the way of doing it could be improved.
 
Now I know that is *really* harsh, but if your site is going to be a success, you just *have* to get a better look, a consistent interface, test the thing, and above all, make it easy to use.
 
Ian

Khun Yee Fung

unread,
Aug 2, 2008, 1:18:36 PM8/2/08
to Google Web Toolkit
Oh, don't worry, I don't have a thick skin, but I can take criticisms.
I learnt that from writing a book (I have not checked lately, but you
might still find my out-of-print book on Amazon) a few years back. The
comments from the anonymous reviewers during the publication process
were much harsher than you. Actually, the non-anonymous reviewers were
not very kind either. As long as the criticisms are constructive, I am
all ears.

Can't reply right away, as I need to digest what you said. However, I
thank you very much for the comments. And thanks for going through the
site.

Khun Yee
> (c) Mivanti Systems Inc. 2008

Maxim

unread,
Aug 3, 2008, 12:41:01 PM8/3/08
to Google Web Toolkit
Khun, small question.

There is a parameter in profile: Display timezone: EST5EDT.
Why do you use it in your application ? We keep all the "times" in
Java long datatype, as it is returned by currentTimeMillis(), so far
it's been enough ...

Maxim

unread,
Aug 3, 2008, 4:33:19 PM8/3/08
to Google Web Toolkit
what I mean - we do not user timezone on server side, server always
keeps GMT time and time is always rendered by the client using browser
settings.

Jon Brisbin

unread,
Aug 3, 2008, 9:43:04 PM8/3/08
to Google-We...@googlegroups.com
This might not be the case in their instance, but I'm keeping track of
the user's timezone because the created on and last edited timestamps
that come from the uploaded documents in my app have to be adjusted
back to server time via the user's timezone settings. I'm using pytz
on the server side Django code.

For timestamps created on the server, I can see where it doesn't
really matter. But if you're handling dates from user-uploaded data
(that comes from the metadata of the user's documents--a time that
might not have any correlation to the uploaded time), I thought it
best to keep track of the user's actual timezone.

Thanks!

Jon Brisibn
http://jbrisbin.com

Ravi M

unread,
Aug 4, 2008, 2:12:11 AM8/4/08
to Google Web Toolkit
This may work fine as long as the client and the server are in the
same timezone. When that is not the case, there is a need to know what
timezone is in the user's intent on the client side.

For example, suppose your server is in Boston (UTC-5:00) and your
client is in Bucharest (UTC+2:00). Your application has something to
do with setting alarms that go off at particular times, and your
Romanian user wants one such alarm to trigger at 1330 on 04 August
2008 in Bucharest time (=0630 on 04 Aug 2008 in Boston). She chooses
this setting in the browser and clicks "Save" or whatever which causes
this setting to be persisted on your server. The scheduling software
(maybe something like OpenSymphony Quartz) runs on your server and it
needs to run the alarm at 6:30 in the morning.

How will it know this without knowing both what timezone it's in, and
what timezone the client/user meant to use?

Since java.util.Calendar and the timezone related classes are not
emulated yet (as of GWT 1.4), the only way to get this information
seems to be to ask the user herself to tell you what timezone she's
in, which is what Khun's application is possibly doing? Just a guess.

I am working on an application that has a need as I described above,
and for now it appears that the best we can do is ask the user to
select the timezone that they intend to set times in. It needn't be
terribly painful from a usability perspective, we'd do it once per
user and save it somewhere on the server so that every time the user
sends a timestamp, we know what offsets to compute etc.

Cheers
Ravi

Maxim

unread,
Aug 4, 2008, 3:50:53 AM8/4/08
to Google Web Toolkit
On Aug 4, 10:12 am, Ravi M <mund...@gmail.com> wrote:
> For example, suppose your server is in Boston (UTC-5:00) and your
> client is in Bucharest (UTC+2:00). Your application has something to
> do with setting alarms that go off at particular times, and your
> Romanian user wants one such alarm to trigger at 1330 on 04 August
> 2008 in Bucharest time (=0630 on 04 Aug 2008 in Boston). She chooses
> this setting in the browser and clicks "Save" or whatever which causes
> this setting to be persisted on your server. The scheduling software
> (maybe something like OpenSymphony Quartz) runs on your server and it
> needs to run the alarm at 6:30 in the morning.
>
> How will it know this without knowing both what timezone it's in, and
> what timezone the client/user meant to use?

If user enters local datetime in local string form then you can get
UTC time using:

DateTimeFormat.getShortDateFormat().parse(m_startDate.getText()).getTime()

Having UTC time you can run alarm appropriately. Though this works
100% fine only if you have compiled appropriate locale for you GTW
client.

Anyhow, you can get time difference automatically, using code like:

DateTimeFormat.getFormat("hh").format(new
Date(System.currentTimeMillis()))

This code returns local clients hours, knowing server UTC hours you
can do whatever you want, e.g. set value for "timezone" field in user
profiler :)

Maxim

davi...@gmail.com

unread,
Aug 3, 2008, 4:04:43 AM8/3/08
to Google Web Toolkit

Hi,

and what about SEO? Are you differentiating between "html" pages
and "application" pages?

Ravi M

unread,
Aug 4, 2008, 1:03:45 PM8/4/08
to Google Web Toolkit
What you say seems to make sense, Maxim. I had never taken a close
look at DateTimeFormat before, thanks for the tip. Aren't there
possibly a few corner cases where this approach might lead to errors?
It would be pretty rare, I suppose, but because of timing issues it
could be that you got the time on the client at say 13:59:59.500 (i.e.
a few milliseconds before the switch into the next hour) and so your
"hour" reading was 13. Suppose at the same time the server time is
07:59.59.500, so the real time difference is 13 minus 7 = 6 hours. Now
suppose that a second elapsed between the client sending the hour and
the server receiving it. Time on the server is now 08:00:00.500 and
the "hour" on the server is "8". The time difference is now computed
as 13 minus 8 = 5 hours which would be an error.

Is there a way to get around this, or am I missing something?

Thanks

Ravi

PS Apologies if this should be in a different thread/topic!

Maxim

unread,
Aug 4, 2008, 1:27:53 PM8/4/08
to Google Web Toolkit
Ravi

> Now suppose that a second elapsed between the client sending the hour and
> the server receiving it. Time on the server is now 08:00:00.500 and
> the "hour" on the server is "8". The time difference is now computed
> as 13 minus 8 = 5 hours which would be an error.
>
> Is there a way to get around this, or am I missing something?

This particular problem can be solved sending timestamp with known UTC
hour from server to client and getting local hour on the client, this
way there is no gap.

But actually it is not enough just to have hour value - year and day
should also be compared to get the difference. I'm not sure that it is
most srtaightforward way though, may be there is more elegant
solution, kind of javascript function ...

Maxim

unread,
Aug 4, 2008, 2:02:16 PM8/4/08
to Google Web Toolkit
Indeed:

var curdate = new Date()
var offset = curdate.getTimezoneOffset();

does the job

Sumit Chandel

unread,
Aug 7, 2008, 1:11:08 PM8/7/08
to Google-We...@googlegroups.com
Hi Khun,

Thanks so much for sharing your development experience with the community. Glad to hear you're happy using GWT for CareerCommons.

I wanted to mention that we've recently introduced parallelized compilation in GWT 1.5 RC2, and some developers have been reporting compilation speed improvements. If you have a chance to make the switch, please do let us know if your compile time goes down, and if so, by how much.

I also wanted to second some of Ian's usability improvement suggestions. I think an application like CareerCommons can have a lot of promise, and I realize that this is a first cut of the application that you will be continuously improving.

Cheers,
-Sumit Chandel

Scott Blum

unread,
Aug 7, 2008, 2:31:07 PM8/7/08
to Google-We...@googlegroups.com
Actually, parallel compilers are not in 1.5.  This is a 1.6 feature.

Jon Brisbin

unread,
Aug 7, 2008, 3:15:40 PM8/7/08
to Google-We...@googlegroups.com

On Aug 7, 2008, at 1:31 PM, Scott Blum wrote:

> Actually, parallel compilers are not in 1.5. This is a 1.6 feature.

I wondered that myself, as I've been using trunk and the compiles are
very fast now. When RC2 came out, I downgraded and tried that and the
compiles are noticeably longer. Painfully longer, as a matter of fact.

I'm sticking with trunk for the time being. It's stable, so far as
I've used it, and the compile time is a great boost to productivity.
Since I'm doing iPhone development, I frequently have to turn on the
"compile modules automatically" option and let it compile after every
save. It makes my MacBook hot (and it's a little of a pain to wait on
it before hitting refresh on the iPod), but it's the only way to
reliably develop when your code acts differently on that platform than
in the hosted browser.

Thanks!

Jon Brisbin
http://jbrisbin.com

Brian

unread,
Aug 7, 2008, 8:11:34 PM8/7/08
to Google Web Toolkit
I pulled the trunk and incubator trunk, rebuilt both, then rebuilt my
project, and compiles are the same speed. How do you know if you're
getting parallel compiles? Is there a switch to enable?

Thanks.

Jon Brisbin

unread,
Aug 7, 2008, 9:37:30 PM8/7/08
to Google Web Toolkit
I asked if there were switches I needed to use partaklelization but I
never got an answer. It sure seems faster to me anyway. I havn't run
numbers or anything to measure it exactly. I'd sure be interested to
hear if anyone actually has done real testing.

Sent from my iPod

Jon Brisbin

unread,
Aug 7, 2008, 9:40:06 PM8/7/08
to Google Web Toolkit
Forgot to mention that I also was using the Apple java 1.6, which is a
64-bit JVM. Not sure if it makes any difference...

Sent from my iPod

On Aug 7, 2008, at 7:11 PM, Brian <hib...@gmail.com> wrote:

Brian

unread,
Aug 7, 2008, 10:02:29 PM8/7/08
to Google Web Toolkit
It's faster on the Showcase sample, no doubt. I did builds using the
1.5rc2 release and its showcase sample and saw approx 3min compiles.
Using the trunk and its Showcase sample was around 1.5min builds.
Not sure what it is about my project that's not getting much
optimization. Ah well, guess I'll wait until we hear more about 1.6
and parallel builds.


On Aug 7, 9:40 pm, Jon Brisbin <jon.bris...@gmail.com> wrote:
> Forgot to mention that I also was using the Apple java1.6, which is a  
> 64-bit JVM. Not sure if it makes any difference...
>
> Sent from my iPod
>
Reply all
Reply to author
Forward
0 new messages