Hey guys.

Imho having Generators in the "CCL club" is icing on the cake...very
cool but not really essential.

I can confirm using JavaRebel solves both problems (generator code
change, and gin module changes, @Inject added etc). For the time being
I think this is a reasonable compromise for people who want to change
gin code in hosted mode.

afaik you don't need to supply source code of the generator. Should we
want them fully in the CCL club this would break backwards
compatibility.

As Class loading goes. How about: Load generator and all its libraries
from SystemCL to a GeneratorClassLoader and load all gwt client code
from CCL into GeneratorClassLoader to. Like a hybrid space of SystemCL
and CCL.

I see 2 problems with this. Passing the TreeLogger and Context isn't
compatible since one is from GeneratorCL the other from SystemCL (with
some very heavy lifting this can be worked around). Afraid that super
source code from CCL would be picked up before the same stuff from
SystemCL(I don't see any way to get this info).

Other ways might require more comprehensive changes to gwt codebase.

imho this is starting to sound like one of those things that are more
trouble than they are worth.

Cheers
Alen

On Jul 22, 4:53 pm, Scott Blum <sco...@google.com> wrote:
> But there is no CCL when running the compiler.  We never go through the
> trouble of constructing a "client" class loader environment for generators
> to access, they just run in the system class loader.  Supposing we did build
> a client classloader and run the generators there, how would generators then
> access stuff outside the client space?  IE, how would the Gin generator
> access Guice since it wouldn't be in client space?
>
> On Wed, Jul 22, 2009 at 10:30 AM, Bruce Johnson <br...@google.com> wrote:
> > @Scott: Hasn't there been a subtle shift in this regard? With GWT 1.5,
> > didn't we conclude that loading classes at least for annotations would make
> > the most sense?
> > I think now that we have enhanced the CCL, for deRPC, to delegate to "grey
> > area" classes that aren't strictly in the client space, maybe we actually
> > could run generators in the CCL.
>
> > On Wed, Jul 22, 2009 at 10:24 AM, Brian Stoler <bsto...@google.com> wrote:
>
> >> Hi Scott,
> >> Gin uses reflection because it reuses the heavy lifting from Guice, which
> >> is not GWT-aware.
>
> >> Seems like both issues could be resolved if generators were loaded in the
> >> client code ClassLoader. Is there a technical or philosophical problem with
> >> doing so? I can understand it might not be at the top of the priority list
> >> right now, but wanted to know if it would be a bad thing if someone were to
> >> propose a patch.
>
> >> -brian
>
> >> On Wed, Jul 22, 2009 at 7:20 AM, Scott Blum <sco...@google.com> wrote:
>
> >>> Generally speaking, you do not want to use reflection inside a generator
> >>> to try to view the client code.  That's what TypeOracle is for, that's the
> >>> supported way of viewing client code.
> >>> As for the separate issue of modifying and recompiling a generator itself
> >>> while running, you're right in that we don't explicitly support it.  Using
> >>> unit tests during generator development as you suggest sounds like a good
> >>> strategy to me.  In some cases, you might also get your IDE to do a
> >>> hot-replace if you modify the code while debugging, but this can be flaky.
>
> >>> On Wed, Jul 22, 2009 at 6:45 AM, Alen Vrecko <alen_vre...@yahoo.com>wrote:
>
> >>>> Hi,
>
> >>>> continuing from
> >>>>http://groups.google.com/group/Google-Web-Toolkit/browse_thread/threa...
> >>>> . Sorry for the added garbage could have known better to post it here
> >>>> in the first place.
>
> >>>> I see generators as en extension to client code therefore I expect
> >>>> them to behave a bit like client code namely refresh recompiles the
> >>>> generator and client class code changes are visible to the generator.
>
> >>>> As recompiling the generator feature goes maybe it is a bit like
> >>>> fairytale i.e. not really needed. Will just write the unit tests for
> >>>> generators in any case before running the hosted mode and not play
> >>>> with the generator on the fly with change code shutdown-start hosted
> >>>> mode repeat.
>
> >>>> But seeing the latest class files inside generator is needed for
> >>>> refresh to work in some cases. Sure you can do much with TypeOracle
> >>>> but you can't instantiate the JType. Afaik there is no bridge between
> >>>> a JType and Class type.
>
> >>>> What do you think?
>
> >>>> Cheers
> >>>> Alen
>
>
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---

Reply via email to