[gwt-contrib] Re: Java 9

[James Nelson]

>
>
> It is my understanding that we use ASM to load the annotation attributes 
> from source classes, and then create a Proxy to load member values / 
> classes / enums off the classpath.  JDT is not involved at all (strange 
> that it isn't...).  
>
>
The most likely reason we aren't using JDT to compile the annotaitons is we 
are really only using the parser, but not the linker (no code to emit 
classfiles) 

-- 
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/d08d7ad2-4f67-4118-bf81-2924fedfddf3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Java 9

[James Nelson]

>
>
> Fwiw, I think it would work, according to 
> https://github.com/AdoptOpenJDK/openjdk-jdk9/blob/f9129bba032f3b75be9b67f45636f76940e029a6/jdk/src/java.base/share/classes/jdk/internal/loader/ClassLoaders.java#L70-L73
> (for now, I'm not interested in supporting modules, just making GWT 2 work 
> in a Java 9 VM)
>

Hm.  One would assume that most people using Java 9 are going to be using 
modules, since, AFAIK, you can't access anything but the java.base module 
without requiring said modules (no java.logging, java.sql, java.xml, 
java.xml.bind, or jdk.management allowed).  Not sure how ReflectiveParser 
is going to create ModuleDefs w/out java.xml unless we repackage all of 
org.xml.sax... Though, I suppose we could try it and see if / how it blows 
up?

I mean, reading the java.class.path as a fallback would be ok, but we'd 
still want to prefer classloader scanning for cases where the user is 
launching their gwtc on a thread with a different classloader than the 
system classloader.

Though, I think any solution which requires "never run gwtc with modules 
involved at all" would be pretty poor, considering almost any dependency 
which also uses java 9 will almost assuredly choke and die.
Considering the ugly hack I have does technically work, it doesn't seem 
worth it to limit scope so we can use a less-bad hack.

 

> Another alternative is to go the way of apt and use something akin to 
>> AnnotationMirror... meaning you can't just do MyAnnoClass anno = 
>> member.getAnnotation(MyAnnoClass.class), but will instead be stuck 
>> operating on a generic mirror which can get members by string name.  Not 
>> exactly pretty, but if it's good enough for apt, it can clearly be made to 
>> work (plus, with the impetus to ditch generators, we'd be stuck with it 
>> anyway).
>>
>
> But isn't the whole issue with annotations due to JDT?
>

It is my understanding that we use ASM to load the annotation attributes 
from source classes, and then create a Proxy to load member values / 
classes / enums off the classpath.  JDT is not involved at all (strange 
that it isn't...).  

Really, any solution which exposes actual instances of the annotation class 
are somewhat doomed to have to be able to load those types off the 
classpath.

One solution, not sure it's a good one, would be to generate a 
MyAnnotationMirror type, which still affords type safety and ease of use, 
but exposes classes and enums as objects containing only type / name 
information.  Obviously not going to work w/out a precompilation pass, but 
could work well in combination with other tools to help get generators out 
of gwtc (AKA, not a good solution for right now). 
 

>  
>
>> I (also) have another project which converts AnnotationMirror to a proxy 
>> of MyAnnoClass that can either load a dependent Class/Enum, or fail if that 
>> class is not on classpath (but only fail if you try to access that member).
>>
>
> You mean like 
> https://docs.oracle.com/javase/7/docs/api/javax/lang/model/element/Element.html#getAnnotation(java.lang.Class)
>  ?
> (ok, that one won't load the Class/enum from the classpath, but always 
> throw when accessing members of those types)
>


Precisely that, actually.  Except I catch those exceptions (which contain 
the TypeMirror of the offending type), and then try to recover by loading 
the class (and could make that even better by looking for source and 
compiling on the fly, as needed... requires a dynamic classloader though, 
which can make things... complex.) 

-- 
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/18414c9f-6050-44e5-87ef-4eb11299cf57%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Java 9

[James Nelson]

>
>
> Could that work if we complemented the "instanceof URLClassLoader" with 
> some check for "is the system classloader" and then use 
> System.getProperty("java.class.path") (or the equivalent 
> ManagementFactory.getRuntimeMXBean().getClassPath()) to get the system 
> classpath entries? (do we also need the bootclasspath?)
>


Here is the hack in full.  Could be better using a more standard "get my 
classpath" mechanism (though, to be honest, I think it might be better to 
have an alternate means of specifying classpath for Gwt; for example, 
specifying maven-repo coordinates and resolving them via maven cli)

String java9Modules = System.getProperty("gwt.java9.modules");
for (ClassLoader candidate = wrapped; candidate != null; candidate = 
candidate.getParent()) {
  if (candidate instanceof URLClassLoader) {
for (URL url : ((URLClassLoader) candidate).getURLs()) {
  result.put(url.toExternalForm(), url);
}
  } else  if (java9Modules != null) {
  // If the user specified java 9 modules to load for classpath,
  // we'll want to do it all through reflection,
  // to avoid losing support for java 8
try {
  final Class modRef = 
candidate.loadClass("java.lang.module.ModuleReference");
  final Method getLocation = modRef.getMethod("location");
  // In the case of java 9, the only way to scrape classloaders is this 
ugly reflection
  // on an internal class (used to be a URLClassLoader).
  // you will need to add `--add-opens 
java.base/jdk.internal.loader=myJava9ModuleName`
  // to your gwt runtime as a VM argument
  final Class loader = 
candidate.loadClass("jdk.internal.loader.BuiltinClassLoader");
  // TODO: Don't use classloader for resource loading
  final Method findMod = loader.getDeclaredMethod("findModule", 
String.class);
  // This is why we have to open the package; just being visible is not 
enough
  // to be allowed to act reflectively
  findMod.setAccessible(true);

  for (String source : java9Modules.split(",")) {
System.out.println("Loading java 9 module " + source);
Object mod = findMod.invoke(candidate, source);
// Safe to cast; we must be in java 9 to get here,
// so we know that this cast should be safe
Optional location = (Optional) getLocation.invoke(mod);
if (location.isPresent()) {
  final URL url = location.get().toURL();
  result.put(url.toExternalForm(), url);
}
  }
} catch (Exception ignored) {
  if (ignored instanceof InterruptedException) {
Thread.currentThread().interrupt();
throw new RuntimeException(ignored);
  }
  ignored.printStackTrace();
}
  }
}



My method uses a system property to specify which java 9 modules to use as 
source, then rips those out of the BuiltinClassloader.
This is obviously too egregious to use in production, but worked enough to 
get a HelloWorld example to compile (w/ new language features for testing).

Due to java 9's encapsulation, we can't just load the whole classpath 
anyway, since the modules we want to read must be opened (thus the 
property, which could be a config prop instead).

Because we will already have to name the modules we want, it's not a far 
cry to specify source coordinates and resolve the jars as well (I have 
other tools that do this nicely).

It's not pretty, but at least it is possible. :-)

>
> IIRC, when CodeServer was added, with its -src argument, I suggested 
> passing classpaths as argument rather than using the system classpath.
> At the time though, there was even more code that relied on the context 
> classloader than today (rather than using the ResourceOracle). This was 
> fixed later for the most part, but I believe there's still code that uses 
> the context classloader (including looking up annotations from 
> com.google.gwt.core.ext.typeinfo, and AFAIK also JDT loading bytecode that 
> ends up being looked up in the context classloader; 
> see 8b584f412d055ff39949d8b28a8e78d6b0bfe9b6 for example)
> I suppose that could be fixed by using a child URLClassLoader from the 
> classpath argument (that could be necessary anyway for generators and 
> linkers)
>  
>

Aye...  the way we load/compile annotations has always irked me.
Java 9 also comes with full-fledged support for dynamically compiling 
arbitrary source, and it is my opinion that we should use this for 
annotations (so we don't need to run javac before gwtc).
Because annotations contain classes and enums, those classes and enums must 
also be loaded to get annotation support, so it gets... sticky, especially 
once java 9 modules get involved.
By running the compiler on source, then the myriad of original modules 
won't really matter...

Another alternative is to go the way of apt and use something akin to 
AnnotationMirror... meaning you can't just do MyAnnoClass anno = 
member.getAnnotation(MyAnnoClass.class), but will instead be stuck 
operating on a generic mirror which 

[gwt-contrib] Re: Java 9

[James Nelson]

So, to be pedantic:

Language features -> no issues there at all, since JDT happily compiles 
java 8 code w/ a java 9-compatible compiler.
Emul updates -> standard "don't use java 9 methods if you need java 8 
support"
Classpathery -> Made it use ugly reflection to not require java 9 classes 
on classpath; it does require more opening of modules and ugliness, but 
ensures that we don't break when using java 8.

I'm actually using the java 9 compatible version of gwt daily in java 8 
code.

we could make the classpath nastiness a little better using sane feature 
detection and loading classes that don't need (as much) reflection to be 
able to extract the URLs from java 9 classloader...
...however, long term, I still think that we should reconsider how 
ResourceLoader works, and possibly consider something that accepts 
classpaths as arguments.  It's fairly trivial to have arbitrary java code 
use maven to cache/download dependencies, so we could, technically, get 
classpath into Gwt without relying on classloader scanning.

That would be a broader discussion to have though.


The one big caveat is code modularity.  We can't release two jars with code 
in the same packages (unless recent changes to module system now allowed 
"concealed package conflicts").  So, that means either one big, ugly 
uber-jar for compilation (my hack unzips gwt-user and gwt-dev locally to 
avoid these issues)... or we actually, finally modularize the codebase.

Given the intent to rip out useful bits and get them supported in the 3.X 
line, I'd angle towards modularization as that is necessary anyway to 
create smaller, independent libraries.

-- 
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/c3dc1778-a6a2-4a7c-b760-1c09f1212974%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Java 9

[James Nelson]

>
> Are there specific Java9 JRE classes that we should focus on to get into 
> GWT?
>
>
I didn't go through the full changelog, but I believe there have been more 
helper methods added to Optional and other classes; will need emul updates 
for sure.

 

> Would making GWT support Java9 sources and running in a Java9 env cause 
> backward incompatible changes that prevent GWT from running in Java8?
>

There is approximately zero likelihood of breaking changes there.
The only language changes are private interface methods, and relaxed 
try-with-resources.
So, the only risk would be using any updated emul code, and even then, that 
would only apply to any poor souls still using legacy dev mode, or people 
using java 8 importing a library using java 9.

In the case of using new language features, it would be possible to 
automate a transpile from 9 to 8, and in the case of emul, it's standard 
"don't use new things if you need to support old things". 

-- 
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/6110c48b-646f-4c4e-a82d-6a7e89264acb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Java 9

[James Nelson]

As I've mentioned 
elsewhere, https://plus.google.com/+JamesNelsonX/posts/gBfpBDnwV9V , java 9 
support is entirely possible.

When I last tried it out, it required a fair number of hacks, but it worked 
fine.
I expect the final version of java 9 modules to require slightly fewer 
hacks,
and for it to take a fair amount of time to properly refactor gwt jars 
enough to be usable in java 9 systems.

If you are in a rush to get java 9, you are going to have to roll up your 
sleeves, hold your nose, and dive into the early-access bug-zone.
I can get you jars that (can be made to) work, but are very likely to 
change when integrated properly into Gwt
(I did some unspeakable things to make it work the weekend I did it as my 
project).

If you are comfortable waiting until there is more official support, I 
can't really tell you what Google is planning...
I, however, will be releasing my fork w/ java 9 support when I am sure the 
underlying module system is completely done changing;
a few colleagues and I are considering opening a gwt-shop with support for 
the 2.X line, and would handle this kind of stuff directly,
however, it's still being done in my "spare" time, which is actually 
supposed to be for building a new ui templating language for gwt,
coming up with an javax.model replacement for gwt generators, and building 
a social network to fix democracy...  hehe.
"Sleep is the Cousin of Death" :D

-- 
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/a685f645-1abb-4413-ae5c-e589d9dd643c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[James Nelson]

Have not read the whole thread yet, but just wanted to point out a few 
small things.

First, whole-world compilations and transforms are something I've been 
working on as a replacement for generator subsystem since I heard it was 
dying a couple years ago.
I have a toy implementation working with java 8 javac compiler plugins, 
though it looks like that is going away now that java 9 modules exposes the 
compiler in a more powerful / official capacity
(I have a commit w/ java 9 support already, btw).

>From these experiments, I can conclude that it is possible to get typesafe 
whole-world analysis out of your standard javac process, and do ...anything 
you want.
The whole-world part does involve forcing javac to reconsider referenced 
types, and so will be slower than standard javac...  but it is, indeed 
possible.

My main use cases were a GWT.create-like replacement; I have a prototype 
able to slurp up the class literals the same (or better) than stock GWT (I 
also run a fork of GWT 2.X that does other magic-method-magic),
which can then run replacement rules that generate code (completely 
different AST, and no TypeOracle just yet, but all things are possible with 
time).  I didn't bother w/ gwt.xml support yet, as it was just a toy to see 
if it was possible (it is).
My other main use-case was a new ui-templating library to replace the need 
for ui binder;
the solution I came up with includes a DSL that generates cross-platform 
view components for web and javafx... android and ios will likely get a 
kotlin target someday,
but it could easily be stripped down to something that emits artifacts 
suitable for webpack et al.


Both of these efforts have prototypes laying around that could be cleaned 
off if there was significant community interest,
but it's hard to spend lots of time on these things when I've also got a 
day job and an infant at home :-)



So, while I'm not promising I can magically deliver everything that will go 
missing overnight, it is possible, and there are other members of the 
community who are interested.
However, to get production-ready support and testing, this would likely 
need to be a fulltime effort.

*Do ye dissatisfied members of the community think it possible that support 
contracts for GWT 2.X and porting of features into GWT 3.X would be viable?*

While I'm currently happily employed,
I would certainly consider working on fulltime support for these 
replacements *if* it could occupy my working hours rather than my scant 
hours of rest.

If your mission critical applications depend on keeping up to date with 
latest GWT versions but need older GWT features,
well... somebody has to put in time, and it's not looking likely that it's 
going to come for free from community members' spare time.

In reality though, existing applications can stay on 2.X for a long time, 
provided odd compiler bugs get worked out.

While I can find a night here or there to fixup things like sysprops not 
generating permutations correctly (took about 5 hours work),
I also have my own projects on top of work and GWT community and family, so 
I'm stretched pretty thin.

PS -> I already maintain an open source fork of GWT which includes support 
for reflection and arbitrary magic method injection.
I did not even try to get these merged upstream because they move in the 
opposite direction of GWT (I was going for more magic, and they for less);
my long term game plan is to get my extra bells and whistles pulled into 
the javac plugin system (with my other prototypes in that area), so I can 
prefer J2CL as well.

While I will get to this eventually, if there is enough motivation to pay 
to get to it in a hurry, I think there is enough willing talent to pull off 
...whatever we want. :-)

-- 
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/9f7563ef-9774-4c86-b620-46bd6259f24a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Elemental2 and JsInterop base beta releases available.

[James Nelson]

Huzzah!!

I'll be taking this for a spin on my week off; see if I can make custom 
elements completely hack free (at long last)!

Many thanks good sirs.

-- 
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/1ce76a70-bb1d-42a6-adc4-8bc31526644d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: System.getProperty as a replacement for replace-with, generate-with

[James Nelson]

Yup.  CompilerParameters.gwt.xml:








/**
 * Returns the binding property values to be embedded into the initial 
JavaScript fragment
 * for this permutation. (There will be one map for each soft permutation.)
 */
public ImmutableList> 
findEmbeddedProperties(TreeLogger logger) {

  Set propsWanted = 
Sets.newTreeSet(getConfigurationProperties().getStrings(
  "js.embedded.properties"));



This is new to me, so will let someone else describe in detail, but it 
seems "local" and "user.agent" are both system-level magic keys you should 
not be using except for their blessed purpose.

-- 
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/840f19c8-d850-40a5-b597-4f9f2b9b811c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: System.getProperty as a replacement for replace-with, generate-with

[James Nelson]

Here is the code that is doing the selection, in 
ResolvePermutationDependentValues:


private JExpression propertyValueExpression(JPermutationDependentValue x) {
  List propertyValues = 
props.getConfigurationProperties().getStrings(x.getRequestedValue());

  String propertyValue = propertyValues.isEmpty() ? null : 
Joiner.on(",").join(propertyValues);

  if (propertyValue != null) {
// It is a configuration property.
return program.getLiteral(x.getSourceInfo(), propertyValue);
  }

  if (isSoftPermutationProperty(x.getRequestedValue())) {
JMethod method = getOrCreateSoftPropertyMethod(x.getSourceInfo(), 
x.getRequestedValue());
return new JMethodCall(x.getSourceInfo(), null, method);
  }

  propertyValue = 
commonPropertyAndBindingInfo.getPropertyValue(x.getRequestedValue());

  if (propertyValue != null) {
return program.getLiteral(x.getSourceInfo(), propertyValue);
  }

  return x.getDefaultValueExpression();
}



I'd set a breakpoint there to see where it's getting its values from, and 
why it leads to combinatorial explosion.

My guess is overloading the property "locale".

Here are some places where it is special cased:

@RunsLocal(requiresProperties = {"locale.queryparam", "locale", 
"runtime.locales", "locale.cookie"})
public class LocalizableGenerator extends Generator {


sdm Recompiler.java:


if (!binding.isAllowedValue(newValue)) {

  String[] allowedValues = binding.getAllowedValues(binding.getRootCondition());
  logger.log(TreeLogger.Type.WARN, "property '" + propName +
  "' cannot be set to '" + newValue + "'");
  logger.log(TreeLogger.Type.INFO, "allowed values: " +
  Joiner.on(", ").join(allowedValues));

  // See if we can fall back on a reasonable default.
  if (allowedValues.length == 1) {
// There is only one possibility, so use it.
newValue = allowedValues[0];
  } else if (binding.getName().equals("locale")) {
// TODO: come up with a more general solution. Perhaps fail
// the compile and give the user a way to override the property?
newValue = chooseDefault(binding, "default", "en", "en_US");
  } else {
// There is more than one. Continue and possibly compile multiple 
permutations.
logger.log(TreeLogger.Type.INFO, "continuing without " + propName +
". Sourcemaps may not work.");
return null;
  }


AbstractLocalizableImplCreator (#JavaNames):


  SelectionProperty localeProp = context.getPropertyOracle()
  .getSelectionProperty(logger, "locale");
  String defaultLocale = localeProp.getFallbackValue();
  if (defaultLocale.length() > 0) {
genLocale = defaultLocale;
  }


 
Try it with a different property name, I bet your problem goes away.

-- 
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/9a957894-b8ba-4641-aa17-b907cbf96f6e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: GWTCon 2015 keynote question

[James Nelson]

Hi Predrag;

There is not currently an online demo of the framework just yet,
but the prototype application being built with it is designed to make 
explaining complex ideas and processes as simple and as concise as possible,
and it will certainly contain tutorials on how the custom elements are 
defined and generated.

When that demo is ready, I will post about it here and in the G+ group, as 
well as pushing fresh jars to maven central.
I would set an ETA on that to mid-February; the demo project itself is 
actually higher priority than the framework,
but that is a discussion for another thread.

As for Thomas' guess, he would be right that it is a bit on the complex 
side internally,
though I am slimming it down to make each piece an independent, intelligent 
unit that is easy to read and reason about.

The ultimate goal is that you can define an entire UI component in a single 
file, and have that component run on any supported platform (currently GWT 
and desktop; Android up next);
where some people like a minimum of magic bits, I like things to be as 
declarative as possible, with all boilerplate generated (preferably before 
GWT even starts).
My heuristic is "can I do something at build time so when I write 
implementations, I am writing the minimum amount of code possible".

In most cases, the data model and the actual ui rendering is almost 
everything; the actual wiring of elements, injecting css, managing shadow 
dom, binding web components, etc is all generated.


The one Bad Part (tm) that I will admit to is that this currently relies on 
a hacked GWT compiler (I maintain a fork of GWT);
I've been steadily reducing the amount of magic I need from that fork so I 
can eventually deprecate it...
The primary use case being arbitrary magic method injection (making my own 
GWT.create-like methods anywhere needed, like adding reflection support).

Instead of relying on whole-world knowledge from GWT to do that code 
generation and method swapping,
I'm instead using javac plugins to do a "precompile phase" which generates 
the necessary support classes, and swaps in the magic methods.

Since generators themselves appear to be on the way out, I was hoping to 
offer something of a replacement for those who like generated 
implementations;
if I find the time, someday, I might even expose the gwt.ext.typeinfo AST 
classes, though I doubt it will ever actually become a priority, as I don't 
really use Gwt generators anymore.
Buuut, this is certainly a much lower priority goal; when J2CL is 
closer to going public, and people start missing their generators, I will 
likely polish it up and post about it then.

Because my javac generators run before the GWT compile, that means that, 
provided it plays nicely with incremental javac, it will also play nicely 
with incremental Gwtc.
By stripping all but standard compilation from GWT, it should become very 
fast; the only (obvious) problem there is how to invalidate a java type 
that depends on external resources...
Perhaps somebody here has some suggestions, but what I have been doing is 
emitting a @Generated({ "/path/to/resource", "abcHASHofFILE", ... }), 
containing all used source files,
and running a daemon process to monitor input files then forcibly recompile 
any dependents when those inputs change (I use a development server that 
runs javac or gwtc on demand).

It's a bit clunky, but it works.



Anyway,
I don't want to dangle something shiny and not deliver;
I'm hammering away at this demo every free minute,
but would be happy to discuss with anyone what features they think a good 
UI Templating system should offer.


My reference for the UI templating part the project was actually ReactJs... 
 I liked JSX, but felt like it was too ...rigid and opinionated;
also, I don't like how React throws away DOM elements, which makes it hard 
to integrate via standard HTML (yay custom elements / web components!).
The cross-platform aspect is due to the fact that my framework was born to 
do cross-platform service injection,
and adding UI generation is a natural evolution of that effort.


Once I get this demo finished, I'll likely upgrade to Elemental 2 
(currently using Elemental 1),
and some day, when it is released and I no longer need JSNI or GWT magic 
methods, J2CL.

In the meanwhile, I'd love to hear what other developers would want in 
terms of binding declarative UI to java classes.

My current implementation creates classes for UI templates, with references 
to internal elements stored as fields (using the ref="name" attribute),
generates data models (which have generated CRUD endpoints), internal data 
fields (with simple unary expression support; no binary, etc. yet),
and some rudimentary looping / conditional / compile time evaluation.
Adding compile time methods is as simple as defining java methods that take 
either primitives or AST arguments,
so end users can add their own utilities without having to touch the more 
complex services.

[gwt-contrib] Re: GWTCon 2015 keynote question

[James Nelson]

So, a little late to jump in, but figured I'd add my $0.02 to this 
conversation.

I've been hard at work building a future-oriented declarative UI DSL.

Specifically, I extended the Java 8 JavaCC parser to include xml, json and 
css expression syntax.

This allows creation of UI's like the following toy code:


  150 + 10 * $root.data.one) )
align = center
  >
   {
$one.setText("You clicked one " + $root.data.one++ + " times");
  } />

   {
$two.setText("You clicked two " + ++$root.data.two + " times");
  } />

  
  
  
  




It allows you to freely mix and match any form of AST you care about,
then a code generation subsystem allows you to define handled for any tag 
or attribute,
where you can turn any valid ast structure into whatever generated java 
syntax you want.

The really fun part?  It creates an interface, a base class and any number 
of implementations, with both GWT and JavaFX currently supported (Android 
support next; maybe iOS via J2ObjC some day).

For GWT, I am currently using Elemental 1 for low-level implementations, 
however, the abstractions are all designed to be completely orthogonal to 
low-level wiring.
Only the implementation classes know about GWT at all, so you can focus on 
business logic and correct abstractions, instead of making business logic 
dependent on UI implementation details.

The final bit I am working on before doing an official public release is 
the tag generator.
That is, a generator for the tag "define-tag", which will create not just 
the api, base and impl classes, but generate a code generator to then 
handle that tag in other UIs.
Best of all, the GWT implementation actually exports web components, so 
your defined "XApi declarative UI tag" actually becomes a web component 
bound to your java classes,
which can use DOM attributes as accessors  to primitives, and javascript 
for any kind of interop you want to do with the outside world.

Here is an example component I am using in my prototype:

t.allText().hasMatch(TextNode::isLink));
}
}
api = [
public String getTitle() {
return $model.getTitle();
}
,
public $Self setTitle(String text) {
$model.setTitle(text);
return this;
}
]
impl =
@Import({
"de.mocra.cy.shared.ast.WtiParser",
"de.mocra.cy.shared.css.HasWtiStyle",
"de.mocra.cy.shared.css.WtiStyle"
})
[
private HasWtiStyle resources;, // ugh;, semicolon comma on purpose. , 
is for json array parser
// Either make it a statement w/ 
semi-colon, or use (parens)
public HasWtiStyle getResources() {
return resources;
},
public WtiStyle getStyle() {
return resources.css();
},
public $Self ui() {
return this;
}
]

ui =


$model::title


// setting the model directly is the cue for the generator
// that this is going to be an ElementWithModel that has a 
.fromModel method.




/define-tag>


Finally, this framework is good for more than just UIs...  I also use it to 
generate all sorts of other repetitive tasks;
for example, TriFunction or QuadFunction, etc...  The java sdk functional 
interfaces are pretty sparse,
so I've taken to generating my own extrapolations of N-ary functional 
interfaces (by default scaling up to 5-in, 5-out, with potential to 
dynamically generate higher arities if needed for method references.

package xapi.fu.out;
@Generate(
in = {
,

},
out = {

`O$i`),
wrappedParams :
$range(1, $size, $i->`Out1`)
}
template =
@Import({
"xapi.fu.HasOutput",
"xapi.fu.Rethrowable",
"xapi.fu.Lambda"
})
public interface Out$size <$typeParams>
extends HasOutput, Rethrowable, Lambda {

 Immutable$size <$wrappedParams> outAll();

 @unfold(from = 1, to = $size, var = "n")
 default O$n out$n(){
 return out$nProvider().out1();
 }

 @unfold(from = 1, to = $size, var = "n")
 default Out1 out$nProvider(){
 return outAll().out$n();
 }

 @unfold(from = 1, to = $size, var = "n")
 default Out$size<$typeParams> read$n(In1 callback){
 callback.in(out$n());
 return this;
 }

 @unfold(from = 1, to = $size, var = 

Re: [gwt-contrib] Re: Elemental 2?

[James Nelson]

+1 for hacky prototype to play with.

Collide was built with hacky pre Elemental1, and it was rescuable,
and I may have a use case to upgrade it again to Elemental2 (plus a little 
other top secret magic).

https://github.com/cromwellian/gwt-sandbox was where I got the hacky pre 
java 8 version. 
Maybe a quick push and we can start the Elemental2 bake off.  v 0.0.1  :-)

>

-- 
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/bb909391-b591-44f4-be69-32d769871ff0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Incremental compiler refreshes triggered by IDE touching files

[James Nelson]

Ok.  It doesn't always happen to me, but I am using eclipse Luna on Ubuntu 
14.04.

I noticed it personally while testing magic method injection, but it has 
also happened at work with a standard 2.7 SDK.
What I noticed is when I have a lot of files open, even if I am editing 
another file in a project not included in GWT, it is marked stale.
I know this because I added a bunch of debugging logs while working on 
magic method injection, and noticed the timestamp updates.

A co-worker has also reported the same issue with running full builds on a 
unit cache.
So, it's not in SDM in particular, it's in MinimalRebuildCache (which looks 
only at timestamps).

Once you can get enough files open that eclipse decides to touch your GWT 
files when saving other files,
then a rebuild always happens.  Then I close eclipse, and it stops 
happening.

With my debug logging, and eclipse open, editing a file that is included, a 
bunch of other files were marked stale.
With eclipse closed, editing the same file, and only that file was marked 
stale.

I don't have a 100% reliable set of reproduction steps, but I have seen it 
on different machines using different builds = 2.7

-- 
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/c7521c9c-2f25-4683-b85a-b4399268c4c1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Incremental compiler refreshes triggered by IDE touching files

[James Nelson]

Oh, any my work machine is Windows, and one coworker who reported it is on 
mac.  
Both work builds are on plain 2.7

-- 
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/b134cab2-4449-426a-b8e0-c0fdf6a52365%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Incremental compiler refreshes triggered by IDE touching files

[James Nelson]

Whilst digging around trying to make some stuff go faster, I noticed 
something odd... I was getting a bunch of extra types getting marked stale 
at the beginning of a recompile, and at work, recompiles triggered even 
when no changes were made to Gwt-related files.

So, a little debugging and I noticed that we're computing the initial stale 
types using timestamps.  And, my IDE (yes, sigh, eclipse) is actually 
touching the files even when I'm not explicitly saving them.  This causes 
these types to look stale despite there being no changes.

When I close my IDE and manually edit a file via text editor, there are no 
longer extraneous files being marked stale.

It is understandable to use timestamps when recalculating stale types after 
a rebind, but for the initial staleness check in UnifyAst, I think paying a 
little extra for file hashes instead of time stamps might save a lot of 
extra time recompiling files that did not actually change.  If we want to 
save some wall time, we could calculate all the initial file hashes in a 
background thread on the initial compile (or store them as we load them), 
and then only look at the hashes if there is a timestamp difference.  This 
would let us use timestamps as a heuristic for checking hashes.

I'm not sure if IntelliJ has better respect for touching files than 
eclipse, but it seems like a pretty common use case for a file to get 
touched without changing. 

-- 
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/6a1af18b-94a2-4814-831a-19ba92b7e6eb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Jsni on String methods in GWT 2.7

[James Nelson]

I stand very much corrected. /hat tip/
I suppose I've already been using JsType so much it has begin to cloud my 
judgement.

Hm.  How ironic that the only methods unreachable to reflection-via-jsni 
would be private jsni methods? :-)

-- 
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/a2830640-ac38-44a6-863b-097433a2c4a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Jsni on String methods in GWT 2.7

[James Nelson]

I suppose I technically have access to the AST nodes...  If I *really *wanted 
to I could probably find a way, but that would be exceptionally nasty, so, 
no thanks...

-- 
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/e6e26b09-7650-47dd-a289-c0d5e6ee26ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: What constitutes an acceptable emulated String.format implementation?

[James Nelson]

I know that adding more magic methods is generally frowned upon,
but the advantage here is that a String literal can be made available at 
compile time, allowing the injection of a minimal-overhead replacement.
If, for any reason, the String is not a literal, we can emit a warning 
about the runtime library being included and just let it go to the runtime 
StringFormat tool.

Given how likely a formatting String is to be a constant, I think it would 
be worth it;
if anyone is interested in collaborating, I do have simple magic method 
injection running on my fork,
if we prototype it and it goes (provably) well, then perhaps we could 
submit a patch to include the new magic method in UnifyAst.

Should the team decide that we don't want any magic methods, then the other 
alternative would be a Java 8 compiler plugin;
I have a prototype which looks up calls to GWT.create and replaces them, so 
looking up String.format and emitting a super-sourced copy with a generated 
replacement should also be possible.
How to integrate that as a pre-build step is another question, but the 
important thing is that it is possible and we do have options for how we 
want to implement this.

-- 
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/f6ad18fa-c6d5-4180-9105-6659f420fc05%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Dropping IE8 support in useragent-less GWT

[James Nelson]

 Just to toss in another use case...
 
I develop a cross-platform java library that exposes generic apis that run 
on multiple platforms;
each module inherits the minimum possible dependencies, and all 
platform-specific code is isolated from shared APIs.

I never touch anything in User unless I specifically need to write an 
implementation that integrates with some other project,
and such dependencies never, ever make it into the shared modules.
Elemental or even just java emul is plenty to create a module of generic 
functionality,
and I'm very pleased that GWT is keeping its permutations where they belong.

With Elemental being built against webkit's hmtl5 IDLs, it can be the 
single permutations standards way (tm),
with c.g.g.user for all legacy code.

If you need to support ancient browsers, do the enterprise thing and bend 
over backwards to maintain support. 
If you just want to leverage java in a javascript world, then GWT does that 
too.

Win-win, I'd say. :)

-- 
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/bc7863a7-2f63-409c-a6f2-ab2e397e5354%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Changes in monthly GWT contributor hangout

[James Nelson]

I will be returning this month, and would like to discuss how best to support 
java 8 emulation.  Ray had sent a bullet point list of items, like having a 
separate super source folder for java 8 emulation and building a separate jar 
with those sources, but I would like to hear what the team finds acceptable 
before investing time modifying the build.  I can also get in touch with Ivan 
Markov to see how he is doing with sdbg (I've been out of the loop since 
working on java 8 and the launch of my own site).

-- 
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/d/optout.

Re: [gwt-contrib] JavaWriter API as replacement for SourceWriter family

[James Nelson]

 SourceWriter is not incompatible with APT, just like JavaWriter is not 
 incompatible with generators. Both take a PrintWriter where they write; 
 SourceWriter is string-based with only a few helpers for javadoc and 
 indent/outdent, whereas JavaWriter is more Java oriented with methods to 
 begin/end types, methods, control flow blocks, fields, etc.


 Not to shamelessly plug my own work or anything, but I do maintain a 
SourceBuilder library that contains piles of helper functions, the ability 
to add method or field buffers that effectively tear-off a position in the 
source writer, so you can build multiple methods at the same time; it uses 
all fluent interfaces, automatically imports classes (returning the 
shortest name possible that can be used in code [fully qualified if import 
name is already taken]), has fluent interfaces for all methods, and has 
simple support for jsni.

https://github.com/WeTheInternet/xapi/blob/master/dev/source/src/main/java/xapi/dev/source/
groupIdnet.wetheinter/groupId
artifactIdxapi-dev-source/artifactId
version0.4/version

It looks something like:

MethodBuffer valueProvider = beanCls
.createMethod(protected Object valueOf(String name, Object o)) // 
definition is lexed; it can be modified later if you desire
.setUseJsni(true)
.addAnnotation(UnsafeNativeLong.class)
.println(switch(name) {)
.indent()
.println(case 'this': return o;)
.println(case 'this.name()':)
.indentln(return 
o...@java.lang.Object::getClass()().@java.lang.Class::getName()(););

Or, here's a test with more features:

SourceBuilderObject b = new SourceBuilderObject(
  public static abstract class Test);
b.setPackage(xapi.test);
b.getClassBuffer()
  .createMethod(public T extends java.util.Date void 
Test(java.lang.String t) {)
  .indentln(System.out.println(\Hellow World\ + new 
java.sql.Date());)
  .createLocalClass(class InnerClass )
  .createMethod(void innerMethod())
  ;
// We discard java.lang imports
Assert.assertFalse(b.toString().contains(import java.lang.String;));
// We used java.util.Date as a fully qualified name first, so it should 
be imported
Assert.assertTrue(b.toString().contains(import java.util.Date;));
Assert.assertTrue(b.toString().contains(T extends Date));
// We used java.sql.Date as a fqcn after java.util.Date, so it must NOT 
be imported
Assert.assertFalse(b.toString().contains(import java.sql.Date;));

At the core, it's based on StringBuilder, and it takes the best of 
SourceWriter and JavaWriter, then adds a bunch of shiny on top.
It's mutable, supports the notion of ClassBuffer, MethodBuffer and 
FieldBuffer, with child writers scoped correctly, to make inner classes or 
even local classes that retain their place in the SourceBuilder stack.

-- 
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.

Re: [gwt-contrib] JavaWriter API as replacement for SourceWriter family

[James Nelson]

Is there anywhere to get a sneak preview on the discussions about the 
future of codegen?

Andres and I have both invested time in some extensions of ast-based 
codegen, and could really use some time and forewarning to adapt our 
strategy to stay future-friendly with out apis.

-- 
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.

Re: [gwt-contrib] JavaWriter API as replacement for SourceWriter family

[James Nelson]

 There is not much more that what is already discussed earlier in the list 
 . APT takes responsibility of codegen out of GWT compiler and get more 
 inline with the rest of the java world and works on GWT/Android/server. 
 That is basically what would you do if there was no TypeOracle nor 
 GWT.create. I think one could actually start experimenting with it today.
  


I have used APT in places, and to be honest, I've found javax.lang.model to 
be very clunky in comparison to Gwt Ast; the apis are very generic; for 
example, Element returns .getEnclosedElements(), which itself returns all 
enclosed Fields, Methods, Constructors and inner Types.  That said, one 
would imagine it to be possible to duplicate a lot of the utility provided 
in Gwt ast by creating a more verbose, specific api to wrap javax models. 
 Apt does include utilities like javax.lang.model.util.Elements and 
javax.lang.model.util.Types, which could be encapsulated to perform such 
functionality as finding subtypes.  Of course, the classpath for these 
utilities are unbounded, so gwt.xml inclusion/exclusion will essentially be 
ignored.  Of course, there is also the matter of gwt.xml properties as 
well, which I'm sure you guys have all considered as well.

 

 I actually already warned about this earlier. For any GWT.create proposal, 
 we should put into account moving into APT. That being said I think it is 
 still valuable for GWT to support some kind of magic-method replacement 
 mechanism.


Well, in order to implement any kind of magic-method replacement, we'll 
need a means to visit method bodies; at least to the extent of visiting 
method bodies.  But, without an actual Ast nodegraph, it will be quite 
difficult to trace down literal values; 
javax.lang.model.element.VariableElement does provide the means to lookup 
compile-time constants, but any sort of inlining to reduce to what should 
be a compile time constant would certainly fail (I currently do look up 
the node graph a little, but that's mostly for developer ease).

So, I guess, in terms of a viable path forward, would it be reasonable to 
say that either writing or finding an extension of APT capable of providing 
a more usable API would be one worthwhile endeavor?

For the matter of magic-method replacement, it will definitely be 
approximately impossible to do without something like JDT/Lombok to at 
least handle lexing and rewriting specific method invocations with 
different source .  I would be correct to assume that we're not planning to 
actually work off compiled bytecode, correct?  Is there anything on the 
table other than JDT, Java 8 compiler plugins or Lombok?   Can we depend on 
jjs ast + GWT.create being relatively stable and exposed for the 
foreseeable future?

Sorry to bombard you all with questions; I know there are no(t many) 
definitive answers at this time, but it would be nice to get a good 
direction on where is the best way to spend time and energy.

Of note, I've actually had my eye on a generic magic-method replacement 
mechanism for standard java that could be deployed as a maven plugin (or, 
if need be, a java 8 compiler plugin).  I'd like to avoid dependency on a 
version of java not yet released, but, really, so long as it works, and I 
can fallback to suboptimal runtime operation (similar to how 
ServerGwtBridge will work if you initialize correctly), then I'm really 
open to anything.  Given that APT and compiler plugins will be using the 
same Api, I can see the desire to move towards javax.lang.model now.

I think, for now, I'm going to play with java 8 compiler plugins and see if 
my prejudice against javax.lang.model is ill placed.
If you guys know of any other trees worth barking up, please do tell!

-- 
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.

Re: [gwt-contrib] JavaWriter API as replacement for SourceWriter family

[James Nelson]

An excellent read about the trick behind Lombok, and related ast-hacking 
utils:
http://notatube.blogspot.ca/2010/11/project-lombok-trick-explained.html

-- 
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: I am getting ClassCastException on my app production code, but not on dev mode.

[James Nelson]

Please post to http://stackoverflow.com to get support;
this group is for discussing project architecture and product development.

Also, the snippet of code you've sent really doesn't mean anything by 
itself.
Try running in superdevmode on chrome to get a more meaningful stacktrace.

On Sunday, February 9, 2014 5:25:36 AM UTC-5, Mohammad Al Quraian wrote:

 Hi,

 I am developing multiple apps with similar structure, they're working fine 
 except for 2. They give me the following error on production mode only:

 Uncaught java.lang.runtimeexception: java.lang.ClassCastException


 This is the compiled code that throws the exception:

 function 
 com_google_gwt_core_client_impl_Impl_entry__Lcom_google_gwt_core_client_JavaScriptObject_2Lcom_google_gwt_core_client_JavaScriptObject_2(jsFunction){
   return function(){
 try {
   return 
 com_google_gwt_core_client_impl_Impl_entry0__Ljava_lang_Object_2Ljava_lang_Object_2Ljava_lang_Object_2Ljava_lang_Object_2(jsFunction,
  
 this, arguments);
 }
  catch (e) {
   throw e;
 }
   }
   ;

 I am using GWT 2.5.1, any idea what could be the problem?

 Thanks


-- 
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: Quarterly Hangouts On Air

[James Nelson]

A reddit-style AMA would be really cool; so long as we give enough warning 
and promo,
(like posting the event in the G+ community a month ahead of time) I'm sure 
it would be a hit.

The questions in the moderator would probably all get asked;
though seeing some of them come up in the gwt-team meetings would be cool 
too.

An actual hangout over a single time slot generally leaves a lot of people 
unable to come,
so, maybe we'll see if we can keep attracting a lot of people to the 
community meetings,
and maybe we'll get a greater audience to steering committee meetings.

The only reason I was not viewing the public committee meetings was 
visibility;
my gwt-contrib emails were getting filtered with hundreds of other group 
emails,
so I didn't really keep up (have since create a filter specifically for 
Gwt).

I am going to email Bhaskar to see if I can get plugged in on the meeting 
tomorrow,
and I bet if we post it on G+, we'll see greater developer interest.

-- 
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] Quarterly Hangouts On Air

[James Nelson]

Hi all,

I am just wondering if it would be possible to setup a quarterly QA 
hangout-on-air with steering committee members taking questions from the 
public, and presenting on ideas that are in the works for GWT.

It would be similar to the panel held at GWT.create, except we could 
collect up the questions via Google Moderator over the coming months, to 
give panel members time to discuss and decide on answers.

If possible, I would like to get a few RSVPs before mentioning it at the 
community hangout;
we could schedule the first QA panel for the end of March, and post the 
moderator tomorrow to get people started on the questions.

Thanks,
James

-- 
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.

Re: [gwt-contrib] Quarterly Hangouts On Air

[James Nelson]

Sure, no sense in making a new one when there's an existing set of 
questions.

I am, however, not going to mention anything unless the steering panel 
agrees that they would like to go ahead with the idea.

Thus, I thought to ask here, and see if there was any interest. :)

On Sunday, January 26, 2014 6:40:07 PM UTC-5, Boris Brudnoy wrote:

 Hi James,

 This is similar in spirit to my earlier 
 suggestionhttps://mail.google.com/mail/u/0/?ui=2shva=1#starred/142ffd9b639bfor
  the committee members to (eventually) address the 
 Moderator questions asked at 
 GWT.Createhttps://www.google.com/moderator/#16/e=21396f. 
 There are some good questions there. Perhaps, should your idea catch on, 
 for the first QA we could add more questions to that Moderator instead of 
 setting up a new one?

 Boris

 BORIS BRUDNOY
 Java/GWT Web Software Developer 
 (LinkedInhttp://ca.linkedin.com/in/borisbrudnoy
 , Careers 2.0 http://careers.stackoverflow.com/brudnoy)
  

 On Sun, Jan 26, 2014 at 3:41 PM, James Nelson 
 ja...@wetheinter.netjavascript:
  wrote:

 Hi all,

 I am just wondering if it would be possible to setup a quarterly QA 
 hangout-on-air with steering committee members taking questions from the 
 public, and presenting on ideas that are in the works for GWT.

 It would be similar to the panel held at GWT.create, except we could 
 collect up the questions via Google Moderator over the coming months, to 
 give panel members time to discuss and decide on answers.

 If possible, I would like to get a few RSVPs before mentioning it at the 
 community hangout;
 we could schedule the first QA panel for the end of March, and post the 
 moderator tomorrow to get people started on the questions.

 Thanks,
 James

 -- 
 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.comjavascript:
 .
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
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: Initial support for @GwtCreate (code-gen methods)

[James Nelson]

 Thanks! I think this proposal is the most conservative way to enhance 
 GWT.create(). A more radical approach would be to forget GWT.create() and 
 imitate what scala macros do, as was suggested by Gotktug:

   @Macro(SumGenerator.class)
   int sum(int arg0, int arg1) {
 return 0; // we will never be here
   }

   // Rebind space
   class SumGenerator {

 public ExprInteger sum(GeneratorContext ctx, TreeLogger logger, 
 ArgInteger arg0, ArgInteger arg1) {
   if(arg0.isLiteral()  arg1.isLiteral) {
 Integer result = arg0.getValue() + arg1.getValue();
 return ctx.compile(return  + result.toString();
} 
return ctx.compile(return %s + %s, arg0, arg1); 
 }
   }


I definitely like the API this offers.

I do maintain a hack on UnifyAst that allows manually creating magic 
methods;
https://github.com/WeTheInternet/xapi/tree/master/gwt/gwt-method-inject
It's a little ugly in the xml, since I didn't think it wise to create a new 
gwt.xml property for something that will likely never make it into master.

The example generator API w/ ArgType could be extrapolated from the magic 
method injector linked to above, using the literal finder from the other 
code review I posted.

I'm not sure if it could look exactly like the snippet posted (I just 
return JExpression to match GWT.create behavior),
but it does allow defining arbitrary magic methods for experimentation w/ 
extensions to the compiler.

The big problem, of course, is dev mode / jvms, which do not perform magic 
method injection.
Those platforms would require bytecode enhancement, or (as I've been 
doing), specifying a method body which is fully functional in a jvm 
sans-generators.


The only hard part of the scala-esque macros would be ctx.compile(...); 
I've had to either manually create AST nodes (which then lack valid 
SourceInfo), or generate classes so I can then get compiled jjs ast nodes 
from UnifyAst (make sure you call StandardGeneratorContext.finish() before 
attempting this).
I guess it would be possible to automate all of that behind the scenes,
or maybe it would be easy for someone with deeper knowledge than I about 
CompilationUnitBuilder (or wherever strings would be lexed into ast nodes).

For now, however, I think the scala macro idea is a bit too ambitious.




As for passing multiple class lits to a generator, I definitely see where 
it would be useful to have more than one class in a generator,
although UIBinder already achieves this using generic type parameters (but 
requires manually defining the interface, of course).

This would, unfortunately, likely change the Generator interface contract 
and thus break existing code (maybe fine for GWT 3.0, but definitely no 
sooner).
There is also a problem for dev mode, which I'll get into a few paragraphs 
down.


As for the object-instead-of-class details I posted above,
What do you think about:
T T GWT.construct(Class cls, Object ... params)?

It would look and feel exactly like GWT.create,
except it would support constructors with arguments (and would only be 
usable through an annotated factory method, to provide classlits for param 
types).

This would add a new feature that cannot currently be achieved, plus 
promote immutability (more final, less .setValue()).

As such, I think I'll take a stab at it using the aforelinked 
magic-method-inject module when I get some free time (of which I am in 
unfortunately very short supply).
If the experiment goes well, and I can post a working prototype, I'll be 
sure to tag you in the pull request.

The only gotcha I foresee would be dev mode (which I am not terribly 
familiar with modifying); 
about the only way I can think of the get the annotation with class lits in 
the jvm would be to use reflection to look up the call stack and grab the 
enclosing method (ick,
I really don't like seeing comments like // Do not modify the call order 
because this code depends on stack depth == n).

Speaking of which...  getting multiple class params to work in dev mode 
will face the same problem; how to safely (and preferably quickly) extract 
the method annotations within the jvm.


Anyway, they're both fun ideas to play with, and although I'm not holding 
my breath on getting either of them into master any time soon (or ever),
I still like a good challenge, and I think something like GWT.construct() 
could be a lot of fun to work on.

If you have any ideas or suggestions, do let me know!
 

 This last proposal requires a hard work to be done, and a totally new 
 generator API. Before to start with something like this, I prefer to 
 explore the code-gen compiler plugin for javac 8 mentioned by Ray in the 
 other thread. We should stay standard and portable as possible.


For posterity's sake, could you drop those links off here (or are you 
referring to the ones Ray posted in the G+ community? The phrase javac 8 
doesn't ring any bells for me).

Thanks,
James

-- 

[gwt-contrib] Re: Initial support for @GwtCreate (code-gen methods)

[James Nelson]

 For posterity's sake, could you drop those links off here (or are you 
 referring to the ones Ray posted in the G+ community? The phrase javac 8 
 doesn't ring any bells for me).


Nevermind.  I just browsed the group and saw the thread.  My bad. 

-- 
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.

Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)

[James Nelson]

re: Heiko Braun


 it means having an optional compilation path that does not recompile the 
 entire world (as the current monolithic compile path does) and instead 
 tries to recompile just files (or or modules) that have changed.

 it is exploratory work for me right now as there are very many issues 
 standing in its way.

 if/when it is done and ready it should make a big impact on SuperDev mode 
 refresh time by reducing compile time (when compiles are run 
 non-monolithically)


I've long felt like highly modular projects could greatly benefit from 
producing gwtar files so that unchanged code does not require recompiling.
I've thought about using a maven plugin to add .gwtar to my jars, though 
this would not be a portable solution for all GWT developers.

Any portable solution using gwtar would be to create one per module (using 
a flag to enable support while still experimental), or one per java package 
(maybe not a good idea given the size of some projects).

Given that the compiler already knows to remove invalidated units, this 
does seem like a feasible option.
Producing .gwtars could also be done periodically for the whole project at 
the developers whim, perhaps through a flag to a standard full compile?

-- 
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.

Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)

[James Nelson]

 So as a result, in the best possible world the maximum impact it can have 
 on compile time, is ~50%. In practice it has a little less than that 
 because reading and deserializing these GWT Java ASTs from disk takes some 
 (smaller) amount of time and because in large modular projects there's a 
 tendency for duplicate copies of the AST for the same type to accumulate in 
 multiple GWTAR files (thus resulting in wasted duplicate deserialization 
 time).


I did think of the duplicates in GWTAR, and that it might potentially cause 
problems if a type is updated in one GWTAR but not another.

 

 Unlike GWTAR files the incremental compilation approach i'm working on 
 makes/will make 90+% of the compile time split by module (the only time 
 left in the monlithic phase should be a small percentage of generators and 
 the final linking).


I can't wait to see it; when you are ready for testers, I would be glad to 
help out.
 

 I don't want to discourage you from using GWTAR files, since they do have 
 positive impact. But I'm just saying that I'm not putting work into making 
 them easier to use or building easier build system integration for them, 
 since their maximum impact is limited.


Excellent.  One other point is that the GWTAR speedup would help out on 
clean compiles, and not just recompiles.
Obviously recompiles are where the real gold is at, in terms of development 
time,
but anything that cuts down on CI hours at my work would definitely be much 
appreciated.

@Johannes - Your approach sounds like it has potential, and I would be 
glad to contribute to anything you are working on in that direction.
Even if it won't help much or at all in the new compiler, we're all still 
using the old compiler, and anything I can do to drop our 
quarter-million/year CI bill would be time well spent.
 

-- 
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.

Re: [gwt-contrib] Google team meeting notes for August 7 (and earlier)

[James Nelson]

 I may need to revisit some of that responsibility though, since the 
 current GWT Eclipse plugin owns/manages the GWT compile triggering process. 
 I'm toying with the idea of implementing this iterative compilation 
 triggering responsibility in Maven and (since GWT shouldn't try to act like 
 a build system) then integrating this into the GWT Eclipse plugin? I 
 haven't thought all the way through this part and haven't implemented any 
 of this part yet, so would appreciate suggestions.


In my experience with eclipse plugins, the m2eclipse plugin is actually 
more user friendly to perform tasks with than the actual eclipse build 
process.
Anything and everything that does work in maven can work with m2eclipse.

The only gotcha is that not everyone is on the maven bandwagon.  
Still, it would be possible to setup a hidden shadow project based solely 
on source dependencies and .gwt.xml modules.
Of course, requiring m2eclipse for the gwt plugin may be a little 
intrusive, but it could prevent duplication of labor (reuse in eclipse, and 
probably intelliJ as well).

As for incremental recompiles, maven out-of-the-box does not have good 
support for this (yet).
At work, we use a custom plugin that computes unique hashes of files to 
detect changes; every snapshot is compiled and deployed to a repo, so the 
plugin can use the existing jar if it is found, or compile and deploy a new 
one if needed.
For gwt compiles, it would make sense to use a local-repo in /target or 
gwt-unitCache to do something similar; obviously the computing of these 
hashes would add a little overhead, 
but given that hashing a file is certainly faster than recompiling, 
visiting and translating the file, it would still be a win.

I'd heard that maven 3 has extra support for something similar to this, but 
I have yet to see a production use case for it (and I'm pretty sure it 
depends on nexus setup, which is clearly way more overhead than necessary).

If you had a spec for what you want a maven / eclipse plugin to do, I do 
have experience with both, and would be glad to help.


Also, ant tends to have much better support for incremental builds using 
timestamps, which is fine for local development;
we prefer the hash approach because it allows a dependency built by 
developer A to be reused by developer B,
but if we're storing all this locally, timestamps would likely be the best 
of both worlds.

-- 
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: Initial support for @GwtCreate (code-gen methods)

[James Nelson]

I like it!

I've got a few comments / ideas, but overall, I'm glad to see more work 
being done to empower core GWT functionality.

 

 Note that the @GwtCreate class parameters aren't replaced by 
 GwtCreateFactory as was originally suggested by Ray Cromwell. This provides 
 access to actual parameters.


It would be possible to do a full replacement if the factory also gave 
access to the class field, and any code in the method block accessing the 
class could be re-routed through the factory.
Though, I see no good reason why to do the extra work this way, I figured 
I'd mention it in case someone else has a use case for it.
 

* Upcoming improvements:

   1) Support for explicit generators

 @GwtCreate(generator = FooGenerator.class)


Did you see my pull request with some (very) basic support for this?
https://gwt-review.googlesource.com/#/c/4000/

 

 We should forbid assignation between parameters that differs in 
 @GwtCreate signature

   Foo createFoo(@GwtCreate(generator = FooGen.class) final Class? 
 extends Foo) {...}


Agreed.  Final isn't necessary to trace values, but it does ensure users 
don't get weird behavior.


  2) Multiple parameters for GWT.create() by means of @GwtCreate.Param

   U, O UiBinderU, O createBinder(
 @GwtCreate(generator = UiBinGen.class) final ClassU uiType, 
 @GwtCreate.Param final ClassO ownerType) {


Is the intention here to just send more classes to the generator,
or to actually send parameters to the constructor of the rebound object 
being instantiated?

  Foo createFoo(
@GwtCreate final Class? extends Foo fooType,
@GwtCreate.Param final Class? arg1,
@GwtCreate.Param final Class? arg2) {  
return GWT.create(fooType, arg1, arg2);
  }

Sending classes is no good, because the constructor needs the values.

Personally, I think the best solution is to add the parameters to 
@GwtCreate;

  Foo createFoo(
@GwtCreate({String.class, int.class})
final Class? extends Foo fooType,
String arg1, int arg2) {  
return GWT.create(fooType, arg1, arg2);
  }

Class values in annotations must be class literals, so that makes that easy.

It also means we don't care about the order of extra parameters sent to the 
method,
nor are we forced to get these values from the method parameters (or even 
declare GWT.create params as params in method);
the invocation of GWT.create(cls, params) would simply supply the 
JExpressions to pass along to constructors.
(Have to pull out the initializers from the JNewArray made by the generics, 
but that's simple).

I assume we would be changing GWT.create to be create(Class? c, Object 
... params);
the compiler could bail if params.length  0 anywhere that's not in a 
method (method w/ parameter) annotated with @GwtCreate.

Then, add a JType[] and JExpression[] to JGwtCreate to be able to find the 
right constructor and have values to send it 
(not sure if unboxing would work without a tweak, but that's no biggie).


The only hard-ish part would be updating ResolveRebinds to pass along the 
list of JExpressions correctly.


Do you have any work started in this area, cos I'd be glad to give it a 
shot / send over a pull request.
 

To allow mixed multiple code-gen parameters, we would bind main 
parameters by name


   F extends Foo, B extends Bar
   void mixedMultiple(
   @GwtCreate final ClassF fooType, 
   @GwtCreate.Param(fooType) final Class? fooArg,
   @GwtCreate final ClassB barType, 
   @GwtCreate.Param(barType) final Class? barArg)


I really don't like this much typing to wire stuff up.
Putting the params in the @GwtCreate would make this much cleaner:

F extends Foo, B extends Bar B create(
@GwtCreate({String.class}) final ClassF fooType,
@GwtCreate({Foo.class}) final ClassB barType) {
F foo = GWT.create(fooType, some string);
return GWT.create(barType, foo); // params can come from anywhere
  }
 

   3) Support for GWT.create(this.getClass()) ? not exactly, but...

 Explicits generators can eliminate the issue of the unique generator 
 per class hierarchy. An aditional boolean parameter for @GwtCreate would 
 mitigate the code size issue

   abstract class UiBinderComposite extends UiBinderComposite {

 public UiBinderComposite() {
   UiBinderWidget, UiBinderComposite binder = 
 createBinder(getClass());
 }

 private static UiBinderWidget, UiBinderComposite
 createBinder(@GwtCreate(
 // The explicit generator knows when to stop the code 
 generation
 generator = UiBinderCompositeGenerator.class,

 // this.getClass() is disallowed by default.
 allowsThisClass = true) 
 final Class? extends UiBinderComposite type) {

   return GWT.create(type);
 }
   }


I am unsure how 

[gwt-contrib] Change in gwt[master]: Adds support for lower case encoding names to String

[James Nelson]

James Nelson has posted comments on this change.

Change subject: Adds support for lower case encoding names to String
..


Patch Set 2:

(1 comment)

lgtm;

made a nit for production mode performance (using native js regex), though  
I'm not sure it's worth it.



File user/super/com/google/gwt/emul/java/lang/String.java
Line 309: if (CHARSET_UTF8.equalsIgnoreCase(charset)) {
I wonder if we might see better performance using native methods w/ js  
regex.


native boolean isUtf8(String charset)
/*-[
return (charset||'').match(/utf-8/i)
]-*/;


--
To view, visit https://gwt-review.googlesource.com/3000
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: Ie9532ba1e7e6e863093727e354f7f3174229c2ab
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Honza Rameš rame...@gmail.com
Gerrit-Reviewer: Honza Rameš rame...@gmail.com
Gerrit-Reviewer: James Nelson ja...@wetheinter.net
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: Yes

--
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] Change in gwt[master]: Adds support for lower case encoding names to String

[James Nelson]

James Nelson has posted comments on this change.

Change subject: Adds support for lower case encoding names to String
..


Patch Set 2: Code-Review+1

--
To view, visit https://gwt-review.googlesource.com/3000
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: Ie9532ba1e7e6e863093727e354f7f3174229c2ab
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Honza Rameš rame...@gmail.com
Gerrit-Reviewer: Honza Rameš rame...@gmail.com
Gerrit-Reviewer: James Nelson ja...@wetheinter.net
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: No

--
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] Change in gwt[master]: Adds support for lower case encoding names to String

[James Nelson]

James Nelson has posted comments on this change.

Change subject: Adds support for lower case encoding names to String
..


Patch Set 2:

Aye, my tests on the regex show it way slower, even with cached regex  
matcher.  equalsIgnoreCase is the better solution.


So, my bad there.  Next time I'll test before I suggest ;)

--
To view, visit https://gwt-review.googlesource.com/3000
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: Ie9532ba1e7e6e863093727e354f7f3174229c2ab
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Honza Rameš rame...@gmail.com
Gerrit-Reviewer: Goktug Gokdogan gok...@google.com
Gerrit-Reviewer: Honza Rameš rame...@gmail.com
Gerrit-Reviewer: James Nelson ja...@wetheinter.net
Gerrit-Reviewer: John A. Tamplin j...@jaet.org
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: No

--
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] Change in gwt[master]: Remove dependency from GWT-JUnit on deRPC

[James Nelson]

James Nelson has posted comments on this change.

Change subject: Remove dependency from GWT-JUnit on deRPC
..


Patch Set 2:

RPCSuite is adding a number of deRPC test suites at the bottom of the  
test.  The StringIndexOutOfBoundsException tends to happen when a deRPC  
servlet receives a payload from a normal RemoteService (and could likely  
happen with any other combination of deRPC and normal RPC, as they expect  
different serialization format with regard to Xsrf tokens).


Moving or deleting the deRPC test suites should allow the normal tests to  
succeed.  When you look at them, you'll see that the deRPC tests all extend  
the normal rpc tests anyway.  Which ones, in particular, are failing?


--
To view, visit https://gwt-review.googlesource.com/1290
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I74c9d2e339187c2a47ccea4b0082c3a59ffe5ae4
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Thomas Broyer t.bro...@gmail.com
Gerrit-Reviewer: Goktug Gokdogan gok...@google.com
Gerrit-Reviewer: James Nelson ja...@wetheinter.net
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: No

--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Remove dependency from GWT-JUnit on deRPC

[James Nelson]

James Nelson has posted comments on this change.

Change subject: Remove dependency from GWT-JUnit on deRPC
..


Patch Set 2:

Sorry to spam, but the fix would be to trace the test classes extending  
HybridServiceServlet and move them to RemoteServiceServlet as well.


JUnitHostImpl is fixed, but the test servlets are still deRPC, thus  
resulting in String index oob.


--
To view, visit https://gwt-review.googlesource.com/1290
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I74c9d2e339187c2a47ccea4b0082c3a59ffe5ae4
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Thomas Broyer t.bro...@gmail.com
Gerrit-Reviewer: Goktug Gokdogan gok...@google.com
Gerrit-Reviewer: James Nelson ja...@wetheinter.net
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: No

--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Remove dependency from GWT-JUnit on deRPC

[James Nelson]

James Nelson has posted comments on this change.

Change subject: Remove dependency from GWT-JUnit on deRPC
..


Patch Set 2:

The tests that were commented out simply extend the other tests that run  
through a normal RemoteServiceServlet.  The only difference is they use a  
different .gwt.xml module that loads up extensions of HybridServiceServlet  
which extends deRPCs RpcServlet.


If legacy support is needed, than a JUnitHostDeRPCImpl that still extends  
HybridServiceServlet should be used instead.  Given that it's deprecated  
and being phased out though, this change should likely be made only in the  
projects that require it.


Additionally, it might save users trouble debugging if the StringIndexOOB  
is caught, and wrapped in a message that says You are using the deprecated  
deRPC RpcServlet instead of the preferred RemoteServiceServlet..


The StringIndexOOB is reliably thrown when using a RemoteService interface  
on a deRPC servlet (unless the payload contains '~'); deRPC scans for a  
separator char of ~, which is not a special char in standard rpc.


It's actually rather confusing, since both servlets call an  
RPC.decodeRequest() command, but from two different RPC classes.   
c.g.g.rpc.server.SimplePayloadDecoder is where the OOB happens, and is  
where the message to switch from RpcServlet to RemoteServiceServlet should  
likely be placed.


--
To view, visit https://gwt-review.googlesource.com/1290
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I74c9d2e339187c2a47ccea4b0082c3a59ffe5ae4
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Thomas Broyer t.bro...@gmail.com
Gerrit-Reviewer: Goktug Gokdogan gok...@google.com
Gerrit-Reviewer: James Nelson ja...@wetheinter.net
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: No

--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Temporarily disable deRPC tests.

[James Nelson]

James Nelson has posted comments on this change.

Change subject: Temporarily disable deRPC tests.
..


Patch Set 2: Code-Review+1

Looks good, but after checking out the tests that are disabled, I've  
noticed the only difference is the module xml is setting  
gwt.rpc.hijackLegacyInterface to true so the legacy remote service hijacks  
the generator to emit deRPC implementations (which appears to not work if  
JUnitHostImpl is not a deRPC as well).


Unless we are planning to support the legacy deRPC system, we may want to  
consider deleting the com.google.gwt.rpc.RPCSuite module entirely and  
making the test cases extend RemoteServiceServlet instead of  
HybridServiceServlet.  If we are not supporting Hybrid / deRPC, we probably  
shouldn't leave test servlets that suggests we do support it.


The only servlets other than the ones commented out that extend  
HybridServiceServlet are from a test for a bug that was fixed seven years  
ago (in the package test).

https://code.google.com/p/google-web-toolkit/issues/detail?id=9

--
To view, visit https://gwt-review.googlesource.com/2733
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I6f439cd60d7f08df2c192ecdc5c6312e6aca1f50
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Matthew Dempsky mdemp...@google.com
Gerrit-Reviewer: James Nelson ja...@wetheinter.net
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: No

--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Including the module name in the magic sourceURL comment in ...

[James Nelson]

James Nelson has posted comments on this change.

Change subject: Including the module name in the magic sourceURL comment in  
code generated by the iframe linker. This gives a bit more context in the  
browser debugger, and is especially important when including multiple GWT  
applications on a page, since otherwise they wi

..


Patch Set 3: Code-Review+1

--
To view, visit https://gwt-review.googlesource.com/2630
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I4044b777c29b058584efd756a7987244d9f7a158
Gerrit-PatchSet: 3
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Erik Kuefler ekuef...@google.com
Gerrit-Reviewer: James Nelson ja...@wetheinter.net
Gerrit-Reviewer: Matthew Dempsky mdemp...@gwtproject.org
Gerrit-HasComments: No

--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Add callbacks to Super Dev Mode to find out when a compile s...

[James Nelson]

James Nelson has posted comments on this change.

Change subject: Add callbacks to Super Dev Mode to find out when a compile  
starts and finishes, and an alternate main() that can be called after  
parsing options.

..


Patch Set 1: Code-Review+1

(1 comment)


File dev/codeserver/java/com/google/gwt/dev/codeserver/CompileDir.java
Line 32: public class CompileDir {
YES!

I will finally be able to delete my CompileDirAccessor :-)


--
To view, visit https://gwt-review.googlesource.com/2540
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I2a27a07d2c8219d496613b1c1c88380c6dc3d032
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Brian Slesinsky skybr...@google.com
Gerrit-Reviewer: James Nelson ja...@wetheinter.net
Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com
Gerrit-HasComments: Yes

--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Prevent dev mode breakage when lots of jso classes are used.

[James Nelson]

James Nelson has posted comments on this change.

Change subject: Prevent dev mode breakage when lots of jso classes are used.
..


Patch Set 3:

Yes, this patch will not be able to fix the actual underlying issue; the  
best it could do is mask the problem with  0x, which would just lead  
to indeterminism.


if (dispId  0xfff  0) throw new Error(You've got a lot of JSOs there,  
shouldn't you be using super dev mode?);


The part that is actually breaking (in class Jsni) is actually just looking  
for the classId; it gets the merged int and then fails when extracting the  
clsId.  A check for jsos / JavaScriptObject$ beforehand could bypass the  
overflow.  Thing is, it failed on PotentialElement, and not  
JavaScriptObject$.  PotentialElement's DispatchClassInfo was filled with  
methods from JSO$ (80,000+ on skeleton project).


--
To view, visit https://gwt-review.googlesource.com/2210
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I0c703d592556c500e338f95469b2db13f8024627
Gerrit-PatchSet: 3
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: James Nelson ja...@wetheinter.net
Gerrit-Reviewer: Brian Slesinsky skybr...@google.com
Gerrit-Reviewer: James Nelson ja...@wetheinter.net
Gerrit-Reviewer: John Ahlroos j...@vaadin.com
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: No

--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Prevent dev mode breakage when lots of jso classes are used.

[James Nelson]

James Nelson has posted comments on this change.

Change subject: Prevent dev mode breakage when lots of jso classes are used.
..


Patch Set 3: Code-Review-1

(3 comments)

This patch doesn't actually fix the underlying issue; the code I uploaded  
had errors, but even after fixing them and passing the related test,  
inheriting elemental still causes JavaScriptObject$ to swell to over 80,000  
members and overflow the integer used to hold class+memberId.



File dev/core/src/com/google/gwt/dev/shell/CompilingClassLoader.java
Line 343:   return (classId  16) | memberId;
Yes, this is the _actual_ issue; though JavaScriptObject$ is already up to  
80,000 items, so it's conceivable that 17 won't be enough for any  
jsni-heavy libraries that take elemental as well.


There's a couple of places I've seen already that use (id  0x) to  
differentiate between class and member id...


Since this is dev mode, couldn't we just upgrade to long and give memberId  
and classId each 25 bits?  So long as we keep the value under 2^53 (max  
floating point in js), it should be safe to pass them into js as doubles,  
pull them out as long, and avoid overflow completely.




File dev/core/src/com/google/gwt/dev/shell/DispatchClassInfo.java
Line 41:   private HashMapInteger, Member memberByMemberId;
Ya, ArrayList is preferable, this review was cobbled together from a  
different patch, and I screwed it up. :-/



Line 85:   int id = memberById.indexOf(m);
This method is only called once per DispatchClassInfo object, during  
lazyInitTargetMembers(); we should, rightly so, make the check against the  
the name-to-int map (and use the array list as originally designed).


Also, embarassingly enough, this code in fact, does not compile.  I can  
upload a fixed copy that will pass DispatchClassInfoTest, but will still  
die as soon as Elemental is inherited.


The real problem isn't anything to do with the collections used here, but  
rather it is in the use of a single integer to contain both class id and  
member id; as soon as we pull in elemental,  
com.google.gwt.core.client.JavaScriptObject$ has 80,000+ members in it (all  
jso methods), so when we create a dispId of
(clsId  16 | memberId), the memberId overflows into classId, causing  
indexOOB and indeterminism galore.


The class that blows up most regularly is PotentialElement, and its  
dispatch map is full of elemental methods.  It can be seen reliably by a)  
inheriting elemental.Elemental, then b) setting a breakpoint on line 177 of  
c.g.g.dev.shell.Jsni (at:

member = dispatchInfo.getClassInfoByDispId(dispId).getMember(dispId);


You will have to continue about ten times before PotentialElement shows up,  
but when it does, you can trace through and see how packing two 16 bit  
integers together causes the overflow (expecting clsId=10, getting 11).


Since it's unlikely (I guess) that we can change the use of int dispId to  
long dispId, the only workable alternative is to make  
DispatchClassInfoOracle return classId and memberId separately, or to put  
in special workarounds for members of JavaScriptObject$ (as no other object  
should have more than 0xfff members).



--
To view, visit https://gwt-review.googlesource.com/2210
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I0c703d592556c500e338f95469b2db13f8024627
Gerrit-PatchSet: 3
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: James Nelson ja...@wetheinter.net
Gerrit-Reviewer: Brian Slesinsky skybr...@google.com
Gerrit-Reviewer: James Nelson ja...@wetheinter.net
Gerrit-Reviewer: John Ahlroos j...@vaadin.com
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: Yes

--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Implemented handling of GwtIncompatible annotations.

[James Nelson]

James Nelson has posted comments on this change.

Change subject: Implemented handling of GwtIncompatible annotations.
..


Patch Set 8:

This feature is so awesome, it's a shame it might have to wait for  
2.6.0...  My project manager's reaction was we've been waiting for this  
for years!.


Any hope for a 2.5.2 release with this and anything that didn't quite make  
it in 2.5.1?  (Sorry to bother you here; it's just it's a big win I'd like  
to land sooner rather than later; we're doing lots of cross platform work  
at our shop).


Thanks for this; I'll be using it in trunk on my own projects asap. :)

--
To view, visit https://gwt-review.googlesource.com/2320
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I0f995d107b9e24fb7afb8aca95ab99b35f561216
Gerrit-PatchSet: 8
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Roberto Lublinerman rlu...@google.com
Gerrit-Reviewer: Brian Slesinsky skybr...@google.com
Gerrit-Reviewer: James Nelson ja...@wetheinter.net
Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com
Gerrit-Reviewer: Roberto Lublinerman rlu...@google.com
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: No

--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Re: gwt rebranding

[James Nelson]

Here is an extremely crude mockup of an idea I had...
For those talking about how it is pronounced Gwit, but still spelled GWT,
I suggest some play on words using the T on the G.


https://lh4.googleusercontent.com/-Zb4YtUAo39k/UULrfkz_5MI/Ans/a8LSWrgh1UM/s1600/gwt.png

Also, I hope it's very obvious that I'm a programmer and not a designer...
Just thought I'd throw out the idea for anyone else playing with the idea.

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

Re: [gwt-contrib] Re: gwt rebranding

[James Nelson]

Thanks @ Rob for notifying branding experts.

The consensus from most of the steering committee is that they like the 
logo as well,
and I for one, pretty much agree.
Going way out there on a new logo would lose all built up brand identity 
and is not likely wise.

I only posted that messed up example because I thought of the play on G+T = 
I, 
but it can only work if it looks clean, and I really don't think there is a 
way to do so.

If anything, an updated logo should look like an upgrade, rather than a 
rebrand;
keep the red toolbox idea, and perhaps spell it out in full, GWT.
Too much detail won't scale down well.

I do know a typography expert I can ask about some good looking fonts and 
ways to apply them to a toolbox...

If anyone has any comments or suggestions, please feel free to criticize as 
constructively as possible. :)

On Friday, March 15, 2013 4:04:28 AM UTC-6, GV wrote:

 Hi,

 Very messed up. Letters without order - only knowing people will recognize 
 what it is about.

 I like very much PostgreSQL or MySQL logos - recognizable animal (or other 
 thing) with clearly written name.

 I looked for animals whose names start from G:

 http://wiki.answers.com/Q/What_are_some_animals_that_begin_with_the_letter_G

 I like very much Goat ;)



 On Fri, Mar 15, 2013 at 11:38 AM, James Nelson 
 ja...@wetheinter.netjavascript:
  wrote:

 Here is an extremely crude mockup of an idea I had...
 For those talking about how it is pronounced Gwit, but still spelled GWT,
 I suggest some play on words using the T on the G.



 https://lh4.googleusercontent.com/-Zb4YtUAo39k/UULrfkz_5MI/Ans/a8LSWrgh1UM/s1600/gwt.png

 Also, I hope it's very obvious that I'm a programmer and not a designer...
 Just thought I'd throw out the idea for anyone else playing with the idea.
  
 -- 
 -- 
 http://groups.google.com/group/Google-Web-Toolkit-Contributors
 --- 
 You received this message because you are subscribed to the Google Groups 
 Google Web Toolkit Contributors group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to 
 google-web-toolkit-contributors+unsubscr...@googlegroups.comjavascript:
 .
 For more options, visit https://groups.google.com/groups/opt_out.
  
  




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

[gwt-contrib] Change in gwt[master]: add Class.getSimpleName to gwt emulation

[James Nelson]

James Nelson has posted comments on this change.

Change subject: add Class.getSimpleName to gwt emulation
..


Patch Set 1:

If we're going to include simple name, how about throwing in Package as  
well; when obfuscation is on, package can be  and simpleName = name =  
obfuscated name.  With obfuscation off, we have to include the package  
string and simple name, so might as well make them both accessible.


Note: If we do add Package, we'll also have to update the  
IsolatedAppClassLoader in gwt-dev mode, as it sadly strips package  
information.  In my reflection service, gwt-dev needs this ugly bit of code  
to get a package from a class:
 return  
Thread.currentThread().getContextClassLoader().loadClass(o.getClass().getName()).getPackage();


--
To view, visit https://gwt-review.googlesource.com/2220
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I7d4c9c34209f43fdfbf255d0d7ce8ac4bd002390
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Daniel Kurka kurka.dan...@gmail.com
Gerrit-Reviewer: Brian Slesinsky skybr...@google.com
Gerrit-Reviewer: James Nelson ja...@wetheinter.net
Gerrit-Reviewer: John A. Tamplin j...@jaet.org
Gerrit-Reviewer: Ray Cromwell cromwell...@google.com
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: No

--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Prevent dev mode breakage when lots of jso classes are used.

[James Nelson]

James Nelson has uploaded a new change for review.

  https://gwt-review.googlesource.com/2210


Change subject: Prevent dev mode breakage when lots of jso classes are used.
..

Prevent dev mode breakage when lots of jso classes are used.

Elemental introduces a lot of native classes that can cause dev mode to
swell and break.  Fixes issue 7481, as well as an unfiled bug whereby
jsni calls on Class objects cause a dev mode security exception when
trying to set accessibility on Class constructor.

Rietveld: http://gwt-code-reviews.appspot.com/1801804/
Change-Id: I0c703d592556c500e338f95469b2db13f8024627
---
M dev/core/src/com/google/gwt/dev/shell/CompilingClassLoader.java
M dev/core/src/com/google/gwt/dev/shell/DispatchClassInfo.java
2 files changed, 24 insertions(+), 15 deletions(-)



diff --git  
a/dev/core/src/com/google/gwt/dev/shell/CompilingClassLoader.java  
b/dev/core/src/com/google/gwt/dev/shell/CompilingClassLoader.java

index dd13008..03fd97e 100644
--- a/dev/core/src/com/google/gwt/dev/shell/CompilingClassLoader.java
+++ b/dev/core/src/com/google/gwt/dev/shell/CompilingClassLoader.java
@@ -339,6 +339,7 @@
  * @return dispatch identifier for the given class and member ids
  */
 private int synthesizeDispId(int classId, int memberId) {
+  assert (memberId = 0x);
   return (classId  16) | memberId;
 }
   }
diff --git a/dev/core/src/com/google/gwt/dev/shell/DispatchClassInfo.java  
b/dev/core/src/com/google/gwt/dev/shell/DispatchClassInfo.java

index 4ab5eb5..65318a9 100644
--- a/dev/core/src/com/google/gwt/dev/shell/DispatchClassInfo.java
+++ b/dev/core/src/com/google/gwt/dev/shell/DispatchClassInfo.java
@@ -38,7 +38,9 @@

   private final int clsId;

-  private ArrayListMember memberById;
+  private HashMapInteger, Member memberByMemberId;
+
+  private HashMapMember, Integer memberIdByMember;

   private HashMapString, Integer memberIdByName;

@@ -54,17 +56,15 @@
   public Member getMember(int id) {
 lazyInitTargetMembers();
 id = 0x;
-return memberById.get(id);
+return memberByMemberId.get(id);
   }

   public int getMemberId(String mangledMemberName) {
 lazyInitTargetMembers();
-
 Integer id = memberIdByName.get(mangledMemberName);
 if (id == null) {
   return -1;
 }
-
 return id.intValue();
   }

@@ -82,9 +82,14 @@

   private void addMemberIfUnique(String name, ListMember membersForName)  
{

 if (membersForName.size() == 1) {
-  memberById.add(membersForName.get(0));
-  memberIdByName.put(
-  StringInterner.get().intern(name), memberById.size() - 1);
+  int id = memberById.indexOf(m);
+  if (id == -1) {
+id = memberById.size();
+memberById.add(m);
+  }
+  memberIdByName.put(StringInterner.get().intern(name), id);
+  memberIdByMember.put(m, id);
+  memberByMemberId.put(id, m);
 }
   }

@@ -185,7 +190,7 @@
 sb.append());

 String mangledName = StringInterner.get().intern(sb.toString());
-
+
 return mangledName;
   }

@@ -228,18 +233,21 @@
   }

   private void lazyInitTargetMembers() {
-if (memberById == null) {
-  memberById = new ArrayListMember();
-  memberById.add(null); // 0 is reserved; it's magic on Win32
-  memberIdByName = new HashMapString, Integer();
+if (memberIdByMember == null) {
+  // Start w/ capacity 2^15,
+  // as elemental Browser class loads many unused classes in dev mode
+  memberByMemberId = new HashMapInteger, Member(32767);
+  memberIdByMember = new HashMapMember, Integer(32767);
+  memberIdByName = new HashMapString, Integer(32767);

+  // We send cls != Class.class to findMostDerived,
+  // so jsni refs to methods on Class don't try to make Class  
constructor accessible
   LinkedHashMapString, LinkedHashMapString, Member members =  
findMostDerivedMembers(

-  cls, true);
+  cls, cls != Class.class);
   for (EntryString, LinkedHashMapString, Member entry :  
members.entrySet()) {

 String name = entry.getKey();

-ListMember membersForName = new ArrayListMember(
-entry.getValue().values());
+ListMember membersForName = new  
ArrayListMember(entry.getValue().values());

 addMemberIfUnique(name, membersForName); // backward compatibility
 addMemberIfUnique(name, filterOutSyntheticMembers(membersForName));
   }

--
To view, visit https://gwt-review.googlesource.com/2210
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: I0c703d592556c500e338f95469b2db13f8024627
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: James Nelson ja...@wetheinter.net

--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group

[gwt-contrib] Change in gwt[master]: Prevent dev mode breakage when lots of jso classes are used.

[James Nelson]

James Nelson has posted comments on this change.

Change subject: Prevent dev mode breakage when lots of jso classes are used.
..


Patch Set 1:

(1 comment)

Not sure if it helps to move from rietveld to here, but I moved it anyway.   
I cherry picked from comments on original, and added a fix I needed for  
jsni refs on Class objects in dev mode as well.



File dev/core/src/com/google/gwt/dev/shell/DispatchClassInfo.java
Line 41:   private HashMapInteger, Member memberByMemberId;
The way the memberByMemberId map is used, it could probably just be an  
ArrayList, and reduce key object allocations / operations.



--
To view, visit https://gwt-review.googlesource.com/2210
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I0c703d592556c500e338f95469b2db13f8024627
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: James Nelson ja...@wetheinter.net
Gerrit-Reviewer: James Nelson ja...@wetheinter.net
Gerrit-HasComments: Yes

--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Prevent dev mode breakage when lots of jso classes are used.

[James Nelson]

James Nelson has uploaded a new patch set (#2).

Change subject: Prevent dev mode breakage when lots of jso classes are used.
..

Prevent dev mode breakage when lots of jso classes are used.

Elemental introduces a lot of native classes that can cause dev mode to
swell and break.  Fixes issue 7481, as well as an unfiled bug whereby
jsni calls on Class objects cause a dev mode security exception when
trying to set accessibility on Class constructor.

Rietveld: http://gwt-code-reviews.appspot.com/1801804/
Change-Id: I0c703d592556c500e338f95469b2db13f8024627
Author:  John Ahlroos j...@vaadin.com
---
M dev/core/src/com/google/gwt/dev/shell/CompilingClassLoader.java
M dev/core/src/com/google/gwt/dev/shell/DispatchClassInfo.java
2 files changed, 24 insertions(+), 15 deletions(-)


--
To view, visit https://gwt-review.googlesource.com/2210
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: I0c703d592556c500e338f95469b2db13f8024627
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: James Nelson ja...@wetheinter.net
Gerrit-Reviewer: James Nelson ja...@wetheinter.net
Gerrit-Reviewer: John Ahlroos j...@vaadin.com
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com

--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Prevent dev mode breakage when lots of jso classes are used.

[James Nelson]

James Nelson has posted comments on this change.

Change subject: Prevent dev mode breakage when lots of jso classes are used.
..


Patch Set 2:

I rebased on master, but couldn't switch username to give john proper  
credit 'cos I don't have auth for that.  He will have to push a commit to  
change it properly; I added props in commit message instead.


The change I made is based on top this one, and it just replaces a  
hardcoded true with clazz != Class.class to avoid trying reflection on  
Class constructor (detailed in rietveld).  I can open a separate issue  
rebased over this one, but it's a pretty minor tweak.


--
To view, visit https://gwt-review.googlesource.com/2210
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I0c703d592556c500e338f95469b2db13f8024627
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: James Nelson ja...@wetheinter.net
Gerrit-Reviewer: James Nelson ja...@wetheinter.net
Gerrit-Reviewer: John Ahlroos j...@vaadin.com
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: No

--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Prevent dev mode breakage when lots of jso classes are used.

[James Nelson]

James Nelson has posted comments on this change.

Change subject: Prevent dev mode breakage when lots of jso classes are used.
..


Patch Set 2:

(1 comment)


File dev/core/src/com/google/gwt/dev/shell/DispatchClassInfo.java
Line 41:   private HashMapInteger, Member memberByMemberId;
This can probably be an ArrayListMember instead.


--
To view, visit https://gwt-review.googlesource.com/2210
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I0c703d592556c500e338f95469b2db13f8024627
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: James Nelson ja...@wetheinter.net
Gerrit-Reviewer: James Nelson ja...@wetheinter.net
Gerrit-Reviewer: John Ahlroos j...@vaadin.com
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: Yes

--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Prevent dev mode breakage when lots of jso classes are used.

[James Nelson]

James Nelson has posted comments on this change.

Change subject: Prevent dev mode breakage when lots of jso classes are used.
..


Patch Set 2:

(2 comments)

Marked points in code that may need to change / be checked against reitveld  
copy.  If John wants to overwrite owner with a new commit, he'll know why I  
made the given changes.



File dev/core/src/com/google/gwt/dev/shell/DispatchClassInfo.java
Line 238:   // as elemental Browser class loads many unused classes in  
dev mode
This code comment addresses a comment on rietveld about the arbitrarily  
large size.  We may want to trim this down.



Line 246:   cls, cls != Class.class);
This is the mentioned small tweak; the boolean value sent to  
findMostDerivedMembers is what determines if constructors are to be  
indexed.  The normal exception handling doesn't catch the SecurityException  
which happens if dev mode tries to set Classinit() to accessible.



--
To view, visit https://gwt-review.googlesource.com/2210
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I0c703d592556c500e338f95469b2db13f8024627
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: James Nelson ja...@wetheinter.net
Gerrit-Reviewer: James Nelson ja...@wetheinter.net
Gerrit-Reviewer: John Ahlroos j...@vaadin.com
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: Yes

--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Fixes TypeError in keys() for JsMapFromStringTo in dev mode.

[James Nelson]

James Nelson has posted comments on this change.

Change subject: Fixes TypeError in keys() for JsMapFromStringTo in dev mode.
..


Patch Set 1:

This needs to be rebased on top of master; it was submitted without running  
git clean -df after a different patch.


The fix is simple and functional, however.

--
To view, visit https://gwt-review.googlesource.com/1680
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I0b5d0c2943c94c1119ae423dfbda6c932045e0b9
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: James Nelson ja...@wetheinter.net
Gerrit-Reviewer: James Nelson ja...@wetheinter.net
Gerrit-Reviewer: Ray Cromwell cromwell...@google.com
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: No

--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Change in gwt[master]: Fix an infinite loop in RPC deserialization due to type vari...

[James Nelson]

James Nelson has posted comments on this change.

Change subject: Fix an infinite loop in RPC deserialization due to type  
variable cycles.

..


Patch Set 3: Code-Review+1

(4 comments)


File user/src/com/google/gwt/user/server/rpc/impl/SerializabilityUtil.java
Line 255:   }
If seen were a SetType, we could call !seen.add() instead of .contains()  
followed by add() later.  If it's not contained, it's getting added anyway,  
so it likely costs less to do one extra add than many extra contains()



Line 262:   }
The optimal solution would detect when a type defined on the class is  
reused in interfaces or fields, so they would be the same instance, and  
always resolve correctly.


As it is, when the types represent the same erased type (which they must,  
at least in the setup from the original issue), they will be functionally  
equivalent (except in maps and == checks, which is why this cycle detection  
was failing).


When an interface generic references the class generic, they are two  
different Type variable instances, but the same actual type.


Perhaps it could be solved with an equals() method that  
checks .getGenericDeclaration() or .getBounds() for equivalence.  I could  
test .getGenericDeclaration() to see if it maps to the source of the type  
we are trying to resolve...




File user/test/com/google/gwt/user/server/rpc/RPCTypeCheckTest.java
Line 2475: assertEquals(hello, ((TypeVariableCycle.PtrPtr)  
deserializedArg).get());
If this test reproduces the error correctly, mine actually didn't (despite  
being setup the same as the test case from the issue); as such, my test  
case should be deleted as this one makes it obsolete.




File  
user/test/com/google/gwt/user/server/rpc/examples/TypeVariableCycle.java

Line 78: public BasePtrC ptr;
I wonder if we shouldn't also test with different bounds, like ? extends C  
or ? super C as well;



--
To view, visit https://gwt-review.googlesource.com/1410
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I88c2774622d22b982346d1ffe5cf12f5d3c96d92
Gerrit-PatchSet: 3
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: James Nelson ja...@wetheinter.net
Gerrit-Reviewer: Brian Slesinsky skybr...@google.com
Gerrit-Reviewer: Goktug Gokdogan gok...@google.com
Gerrit-Reviewer: James Nelson ja...@wetheinter.net
Gerrit-Reviewer: John A. Tamplin j...@jaet.org
Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com
Gerrit-Reviewer: Roberto Lublinerman rlu...@google.com
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: Yes

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

[gwt-contrib] Change in gwt[master]: Fix an infinite loop in RPC deserialization due to type vari...

[James Nelson]

James Nelson has posted comments on this change.

Change subject: Fix an infinite loop in RPC deserialization due to type  
variable cycles.

..


Patch Set 4: Code-Review+1

--
To view, visit https://gwt-review.googlesource.com/1410
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I88c2774622d22b982346d1ffe5cf12f5d3c96d92
Gerrit-PatchSet: 4
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: James Nelson ja...@wetheinter.net
Gerrit-Reviewer: Brian Slesinsky skybr...@google.com
Gerrit-Reviewer: Goktug Gokdogan gok...@google.com
Gerrit-Reviewer: James Nelson ja...@wetheinter.net
Gerrit-Reviewer: John A. Tamplin j...@jaet.org
Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com
Gerrit-Reviewer: Roberto Lublinerman rlu...@google.com
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: No

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

Re: [gwt-contrib] Packaging issue: org.json and RequestFactory

[James Nelson]

 I wouldn't be opposed to having differing rules for the GWT SDK 
 package downloadable at code.google.com and the Maven artifacts. 
 AFAIK, the original idea of bundling them into gwt-user.jar (and 
 gwt-dev.jar) was to make things simpler for users (just put gwt-dev 
 and gwt-user in the classpath).  

For everyone using artifacts from The Central Repository (Maven, 
 Ivy, Gradle, etc.), bundled dependencies hurt more than they help. 


For unfamiliar users, having everything bundled up into a single massive 
jar does reduce barrier to entry.
For anyone with a remotely complex build, being able to pick and choose 
dependencies can be of vital importance.
Aggressive bundling and excessive repackaging can lead to major bloat and 
potential classpath-order problems,
but just adding one jar is the simplest way to get started.

So, this suggests that gwt-user could be made a bloated super-jar, with 
validation and json et al. builtin by jarring in maven.
Build this jar from gwt-core, validation, json, elemental, etc. artifacts, 
but also export these artifacts independently, including a sparse 
gwt-core.jar.
Anyone who doesn't want the bloated omni-jar can take the sparse-jar and 
declare dependencies manually, then export only what they need to the 
server,
while everyone else can just carry on like normal.

In maven, what's in gwt-user now would become gwt-core, and replace 
gwt-user with a pom stub that just bundles up the omni gwt-user.jar.
gwt-core would be a kernel module representing c.g.g.core.Core + all the 
.gwt.xml and interfaces / utilities needed to build the gwt environment;
the maven build for core could still suck in all the required dependencies 
to run with packaging pom, and just export a jar/gwtar in release stage.

So, gwt-user.jar and gwt-core.jar would be mutually exclusive {emit warning 
that classpath is setup inefficiently}.
If you take gwt-core, you must also take all other jars you actually need, 
or deal with classpath manually.
If you take gwt-user, don't take any of the other jars; everything is right 
there.

For IDE / GPE, let it be known that gwt-user is the deprecated way to get 
up and running quickly,
and gwt-core + jars_you_need is the advanced way to get up to max 
performance.

It may be more work to maintain, and gwt-user.jar updates can only be 
issued with a stable set of dependencies bundled,
but at least the component projects and artifacts can be updated 
independently in maven central, and then by hand in user classpath;
that way, if there is an update to request factory or elemental or 
widgetFrameworkXYZ, the sub-modules can release updates without waiting on 
a version release.

For anyone exporting third party libraries, they can just mimic the 
gwt-user pom to create their own omni-jar, and instruct clients to remove 
everything but gwt-server/dev. 

 

 +1 
 (though it'd be even better to ditch org.json and use the upcoming 
 JSON lib; BTW, is it the one from PlayN?) 


+1 more.  Some example syntax I saw somewhere suggests it's very PlayN like;
 

 I'll try to submit a patch to have it fixed in 2.5 but we must first 
  settle on the appropriate way to do it (both for the GWT SDK and for 
 Maven 
  artifacts), and I'd also like your feedback on what would be the 
 appropriate 
  workaround while waiting for 2.5. 


For maven, gwt-user 2.4 cannot be changed, but a gwt-core 2.4 can be added 
with packaging pom, and dependencies declared as needed.
For IDE users, a snapshot release with gwt-core and bundled jars, and maybe 
a pom.xml / generateProject.sh to do mvn eclipse:eclipse to setup classpath?

That or just a README with setup instructions / warnings.

 Whatever we do, we're going to have to make sure that we update GPE so 
 that 
  it knows to add the appropriate dependent jars to the classpath. 

 I don't know for the AppEngine connected Android project (or 
 whatever its exact name), but a standard GWT project currently is 
 missing javax.validation (and of course org.json). 

 
I bring along javax.validation et. al in an eclipse user library, so 
they're available to dev mode, but never on server classpath.

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