from:"james"

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


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

Re: Problem compiling GWT code with Java9

Also, the reason gwt.xml files aren't loading sanely has to do with how 
resources are handled in java 9. 

You are going to have to either declare your source modules (with the 
gwt.xml) as `open` (no documentation for this, I found it trolling JCP 
forums),
or you can open your module to your gwt module (I built this with an 
unspeakable hack for exploration purposes) with --add-opens VM args.


If you dig into classloaders, you will discover that they will allow access 
to .class files from non-opened modules, but all other resources are 
effectively hidden unless explicitly opened.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Java 9

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: Problem compiling GWT code with Java9

Hi.

Per this thread:
https://plus.google.com/+JamesNelsonX/posts/gBfpBDnwV9V

I have actually dove into Java 9 support, and cleared all the roadblocks 
once (before the JCP pushback force the module system to get more last 
minute changes).

The main issue was not language support (easy upgrade from eclipse jdt), or 
a tiny change for try-with-resources (allows effectively final variable 
references, instead of only local variable declarations)...
The biggest problem was the changes to the classloading system.

Specifically, they no longer use URLClassLoader for system classloaders, 
meaning that any attempts to "rip out the classpath" will not work any 
longer.

I managed to hack together a working compile where I check if java 9 
classloaders are in use, and if so, use reflection (with requires 
--add-opens for using reflection on the classloader, plus opening the 
source module so that the gwt code can see external resources), to get 
access to those URLs.

What I did is only one way to fix; we could also add classpath declarations 
to gwt (I use an annotation system that can reference maven modules for my 
own compiles, so I could actually get classpath without looking inside 
classloader).  There might also be less terrible hacks we can use once the 
module APIs are cemented in place.



If you really want to play with this RFN, I can push a build of my gwt fork 
to maven central for you to try out.  I don't really have a snapshot repo, 
or time to respond to bugfixes atm (though I am considering opening a gwt 
support shop this fall, and will "do it right" at that time).  If you are 
comfortable doing local installs to maven just to assess possibilities (or 
if you maintain your own nexus repo), I could just send you jars directly 
(though, that is generally a bit sketchy, imho).

Let me know; I won't have time to do a release this weekend as it is my 
wife's birthday, but I can fit it in if you'd like (and the comments in the 
G+ post aren't helpful enough).

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
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?

2017-05-24 Thread 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.

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

2017-04-06 Thread James Horsley

Wonderful news. Thanks!

On Thu, Apr 6, 2017 at 2:47 AM David Yu  wrote:

> On Thu, Apr 6, 2017 at 5:42 AM, 'Julien Dramaix' via GWT Contributors <
> google-web-toolkit-contributors@googlegroups.com> wrote:
>
>
> The beta version of Elemental2 using the JsInterop specification has been
> released on Sonatype today and is available on Maven central.
>
> Better late than never I guess :-)
>
>
> This release introduces the concept of union types (which are heavily used
> in JavaScript) and many more improvements. More information about union
> types can be found in this document
> 
> .
>
>
> We also split Elemental into smaller jar files:
>
>
> Jar file
>
> artifact-id
>
> GWT module
>
> elemental2-core.jar
> 
>
> elemental2-core
>
> elemental2.core.Core
>
> elemental2-promise.jar
> 
>
> elemental2-promise
>
> elemental2.promise.Promise
>
> elemental2-dom.jar
> 
>
> elemental2-dom
>
> elemental2.dom.Dom
>
> elemental2-svg.jar
> 
>
> elemental2-svg
>
> elemental2.svg.Svg
>
> elemental2-webgl.jar
> 
>
> elemental2-webgl
>
> elemental2.webgl.WebGl
>
> elemental2-media.jar
> 
>
> elemental2-media
>
> elemental2.media.Media
>
> elemental2-indexeddb.jar
> 
>
> elemental2-indexeddb
>
> elemental2.indexeddb.IndexedDb
>
> elemental2-webstorage.jar
> 
>
> elemental2-webstorage
>
> elemental2.webstorage.WebStorage
>
>
>
> You can try them by downloading the jar files or adding Maven dependencies:
>
>
> 
>
>  com.google.elemental2
>
>  ${artifact-id}
>
>  1.0.0-beta-1
>
> 
>
>
> Then inherit the right gwt module in your gwt.xml file.
>
>
> This beta version works only with the latest HEAD_SNAPSHOT release of GWT
> 
> .
>
>
> We’ve also released a beta version of JsInterop.base. This library
> contains base classes and utilities that provide access to JavaScript
> language constructs that are not available in pure Java.
>
>
> You can try it by downloading the jar file
> 
> or use the following Maven dependency:
>
>
> 
>
>  com.google.jsinterop
>
>  base
>
>  1.0.0-beta-1
>
> 
>
>
> Don’t hesitate to report any bugs, issues, concerns you have on this
> mailing list.
>
>
> Important note: They are beta releases and future updates (up until the
> final release) may break code!
>
>
> -Julien
>
>
> --
>
> Julien Dramaix |  Software Engineer |  dram...@google.com |  650-750-6053
> <(650)%20750-6053>
>
> --
> 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/CABXeq2QsTarhDKbYmz0y1SOrjpuFNdoNmAnvAYKacO1f4rLcLg%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> When the cat is away, the mouse is alone.
> - David Yu
>
> --
> 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/CAOkdovKQn1wo%2BR2jrZ3iGrh4ko199_bt6%3DUC-Xd_HYUc%2B65-Yw%40mail.gmail.com
>

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

2017-04-05 Thread 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

2017-01-31 Thread 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

2017-01-31 Thread 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

2017-01-27 Thread 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

2017-01-26 Thread 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 =

GWT Logging

2016-09-15 Thread James Galliford

Hello,

I've recently been having some native app crashes with my company's app on 
iOS devices. It seems to be a memory allocation issue, given the crash log 
says:

Exception Type: EXC_BAD_ACCESS (SIGSEGV) 
Exception Subtype: KERN_INVALID_ADDRESS at 0xbbadbeef 

I was doing some testing, and I found that we do a lot of logging to the 
console, which is great when we're using chrome or a chromium based desktop 
app that we have to test with, but I was wondering if this would be 
persisted on an iPad running a native app which runs our GWT app by default 
or where I would be able to check this setting, as I was not the one who 
set this up. Our app has a synchonisation process which can upload and 
download a relatively large amount of data, and all of this is logged as it 
happens, with the exception of raw data for images. I am wondering whether 
this, in combination with the images we are occasionally sending, is enough 
to put us over the limit that iOS allows individual apps.

I am sure that this is not an issue with the native app. This is a 
relatively recent issue, while the native app has been running without 
changes for a long time, and it isn't an issue with a new version of iOS on 
the device either.

Have any of you seen this error happen in your own apps and was there an 
issue that you found that might be of some help to me trying to diagnose my 
own issue? I'd appreciate any help or answers that can be offered.

Thanks,

James

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Emulating CompletableFuture with Promise

2016-09-09 Thread James Horsley

This is brilliant. I would *love *to see this in GWT proper. Maybe even a
separate library temporarily since it won't make the 2.8.0 release train?

On Fri, Sep 9, 2016 at 2:41 PM Andrei Korzhevskii 
wrote:

> In this case I wanted 'new Promise', not 'Promise.resolve'. Thanks for
> spotting that out! I've updated my branch.
>
>
> On Tuesday, September 6, 2016 at 10:09:28 PM UTC+3, Ian Preston wrote:
>
>> For another hint, I think you don't want the "new" before
>> "Promise.resolve" on line 88 of impl/JsPromise :-)
>> What the best way for me to report bugs to you? A PR?
>>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Problem with 2.8.0 rc1 SDM

Updating gson to 2.6.x fixed it for me

On Thursday, August 11, 2016 at 10:04:44 PM UTC+1, Alberto Mancini wrote:
>
> Hello,
> in the attempt of porting an internal project from beta1 to rc1 we faced 
> an issue i do not understand how to debug. 
>
> The project uses errai but my feeling is that the problem is not related 
> to it because similar projects with errai work without problems. 
>
> Essentially SDM fails during the first compilation and the problem seems 
> in the generation of the source maps. 
>
> The relevant error log follows.
>
> [INFO] GET /recompile/it.e.u.Application
> [INFO]Job it.e.u.Application_1_0
> [INFO]   starting job: it.e.u.Application_1_0
> [INFO]   binding: user.agent=safari
> [INFO]   Compiling module it.e.u.Application
> ...
>
> [INFO]  Unification traversed 54946 fields and methods and 5256 
> types. 5210 are considered part of the current module and 5210 had all of 
> their fields and methods traversed.
> [INFO]  Compiling 1 permutation
> [INFO] Compiling permutation 0...
> [INFO] Linking per-type JS with 5190 new/changed types.
> [INFO] Source Maps Enabled
> [INFO]  Compile of permutations succeeded
> [INFO]  Compilation succeeded -- 35.850s
> [INFO]   Linking into 
> /var/folders/63/qxvnlkdn7yq2n689wbryx_vwrfzqfp/T/gwt-codeserver-2706361954965741673.tmp/it.e.u.Application/compile-2/war/it.e.u.Application;
>  Writing extras to 
> /var/folders/63/qxvnlkdn7yq2n689wbryx_vwrfzqfp/T/gwt-codeserver-2706361954965741673.tmp/it.e.u.Application/compile-2/extras/it.e.u.Application*[INFO]
>   [WARN] Can't write source map 
> CCA06A04193EDF5B35BDE836DF1FABBE_sourceMap0.json
> [INFO] java.lang.NullPointerException*
> [INFO]at 
> com.google.gwt.thirdparty.debugging.sourcemap.SourceMapConsumerV3.parse(SourceMapConsumerV3.java:101)
> [INFO]at 
> com.google.gwt.thirdparty.debugging.sourcemap.SourceMapConsumerV3.parse(SourceMapConsumerV3.java:88)
> [INFO]at 
> com.google.gwt.thirdparty.debugging.sourcemap.SourceMapConsumerV3.parse(SourceMapConsumerV3.java:78)
> [INFO]at 
> com.google.gwt.thirdparty.debugging.sourcemap.SourceMapGeneratorV3.mergeMapSection(SourceMapGeneratorV3.java:311)
> [INFO]at 
> com.google.gwt.core.linker.SymbolMapsLinker.link(SymbolMapsLinker.java:316)
> [INFO]at 
> com.google.gwt.core.ext.linker.impl.StandardLinkerContext.invokeLinkForOnePermutation(StandardLinkerContext.java:384)
> [INFO]at com.google.gwt.dev.Link.finishPermutation(Link.java:483)
> [INFO]at 
> com.google.gwt.dev.Link.doSimulatedShardingLink(Link.java:445)
> [INFO]at com.google.gwt.dev.Link.link(Link.java:178)
> [INFO]at com.google.gwt.dev.Compiler.compile(Compiler.java:244)
> [INFO]at 
> com.google.gwt.dev.codeserver.Recompiler.doCompile(Recompiler.java:362)
> [INFO]at 
> com.google.gwt.dev.codeserver.Recompiler.compile(Recompiler.java:175)
> [INFO]at 
> com.google.gwt.dev.codeserver.Recompiler.recompile(Recompiler.java:134)
> [INFO]at 
> com.google.gwt.dev.codeserver.Outbox.recompile(Outbox.java:135)
> [INFO]at 
> com.google.gwt.dev.codeserver.JobRunner.recompile(JobRunner.java:113)
> [INFO]at 
> com.google.gwt.dev.codeserver.JobRunner.access$000(JobRunner.java:37)
> [INFO]at 
> com.google.gwt.dev.codeserver.JobRunner$2.run(JobRunner.java:90)
> [INFO]at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [INFO]at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [INFO]at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [INFO]at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [INFO]at java.lang.Thread.run(Thread.java:745)
> [INFO]  Invoking Linker Export CompilationResult symbol maps
> [INFO] [ERROR] Failed to link
> [INFO] java.lang.NullPointerException
> [INFO]at java.util.TreeMap.put(TreeMap.java:563)
> [INFO]at java.util.TreeSet.add(TreeSet.java:255)
> [INFO]at 
> com.google.gwt.thirdparty.guava.common.collect.ForwardingCollection.add(ForwardingCollection.java:84)
> [INFO]at 
> com.google.gwt.core.ext.linker.TypeIndexedSet.add(TypeIndexedSet.java:101)
> [INFO]at 
> com.google.gwt.core.ext.linker.ArtifactSet.add(ArtifactSet.java:42)
> [INFO]at 
> com.google.gwt.core.linker.SymbolMapsLinker.link(SymbolMapsLinker.java:330)
> [INFO]at 
> com.google.gwt.core.ext.linker.impl.StandardLinkerContext.invokeLinkForOnePermutation(StandardLinkerContext.java:384)
> [INFO]at com.google.gwt.dev.Link.finishPermutation(Link.java:483)
> [INFO]at 
> com.google.gwt.dev.Link.doSimulatedShardingLink(Link.java:445)
> [INFO]at com.google.gwt.dev.Link.link(Link.java:178)
> [INFO]at com.google.gwt.dev.Compiler.compile(Compiler.java:244)
> [INFO]

Re: Problem with 2.8.0 rc1 SDM

Ah, just realized this was discussed in more detail 
at https://groups.google.com/forum/#!topic/google-web-toolkit/-c4RR6oLr2o 
I'll check my gson dep and report back

On Thursday, August 25, 2016 at 11:28:58 PM UTC+1, James Horsley wrote:
>
> Meant to say that I'm seeing the same error after switching from beta-2 to 
> rc2
>
> On Thu, Aug 25, 2016 at 11:15 PM James Horsley <james.hors...@gmail.com> 
> wrote:
>
>> Doesn't the CodeServer need the gwt-dev.jar though?
>>
>>
>> On Tuesday, August 23, 2016 at 3:45:03 PM UTC+1, viviana zimbone wrote:
>>>
>>> If you have a maven dependency for gwt-dev, removing it shoudl fix the 
>>> issue :)
>>>
>>> Il giorno martedì 16 agosto 2016 11:03:03 UTC+2, Alberto Mancini ha 
>>> scritto:
>>>>
>>>> Unfortunately removing the temporary files does not helps. 
>>>> Today we try to investigate further and eventually we will open an 
>>>> issue. 
>>>>
>>>> Thanks,
>>>>A. 
>>>>
>>>> On Sun, Aug 14, 2016 at 12:52 AM Andrei Korzhevskii <
>>>> a.korz...@gmail.com> wrote:
>>>>
>>>>> Reading the stacktrace, I think the problem is in 
>>>>> https://github.com/gwtproject/gwt/blob/master/dev/core/src/com/google/gwt/core/linker/SymbolMapsLinker.java#L282
>>>>> ,
>>>>> looks like disk cache returns null there.
>>>>>
>>>>> Did you try to remove folder /var/folders/63/qxvnlkdn7yq2n689wbryx_
>>>>> vwrfzqfp/T/gwt-codeserver-2706361954965741673.tmp
>>>>> and run compile again?
>>>>>
>>>>>
>>>>> On Friday, August 12, 2016 at 12:04:44 AM UTC+3, Alberto Mancini wrote:
>>>>>>
>>>>>> Hello,
>>>>>> in the attempt of porting an internal project from beta1 to rc1 we faced 
>>>>>> an issue i do not understand how to debug. 
>>>>>>
>>>>>> The project uses errai but my feeling is that the problem is not 
>>>>>> related to it because similar projects with errai work without problems. 
>>>>>>
>>>>>> Essentially SDM fails during the first compilation and the problem 
>>>>>> seems in the generation of the source maps. 
>>>>>>
>>>>>> The relevant error log follows.
>>>>>>
>>>>>> [INFO] GET /recompile/it.e.u.Application
>>>>>> [INFO]Job it.e.u.Application_1_0
>>>>>> [INFO]   starting job: it.e.u.Application_1_0
>>>>>> [INFO]   binding: user.agent=safari
>>>>>> [INFO]   Compiling module it.e.u.Application
>>>>>> ...
>>>>>>
>>>>>> [INFO]  Unification traversed 54946 fields and methods and 5256 
>>>>>> types. 5210 are considered part of the current module and 5210 had all 
>>>>>> of their fields and methods traversed.
>>>>>> [INFO]  Compiling 1 permutation
>>>>>> [INFO] Compiling permutation 0...
>>>>>> [INFO] Linking per-type JS with 5190 new/changed types.
>>>>>> [INFO] Source Maps Enabled
>>>>>> [INFO]  Compile of permutations succeeded
>>>>>> [INFO]  Compilation succeeded -- 35.850s
>>>>>> [INFO]   Linking into 
>>>>>> /var/folders/63/qxvnlkdn7yq2n689wbryx_vwrfzqfp/T/gwt-codeserver-2706361954965741673.tmp/it.e.u.Application/compile-2/war/it.e.u.Application;
>>>>>>  Writing extras to 
>>>>>> /var/folders/63/qxvnlkdn7yq2n689wbryx_vwrfzqfp/T/gwt-codeserver-2706361954965741673.tmp/it.e.u.Application/compile-2/extras/it.e.u.Application*[INFO]
>>>>>>   [WARN] Can't write source map 
>>>>>> CCA06A04193EDF5B35BDE836DF1FABBE_sourceMap0.json
>>>>>> [INFO] java.lang.NullPointerException*
>>>>>> [INFO]   at 
>>>>>> com.google.gwt.thirdparty.debugging.sourcemap.SourceMapConsumerV3.parse(SourceMapConsumerV3.java:101)
>>>>>> [INFO]   at 
>>>>>> com.google.gwt.thirdparty.debugging.sourcemap.SourceMapConsumerV3.parse(SourceMapConsumerV3.java:88)
>>>>>> [INFO]   at 
>>>>>> com.google.gwt.thirdparty.debugging.sourcemap.SourceMapConsumerV3.parse(SourceMapConsumerV3.java:78)
>>>>>> [INFO]   at 
>>>>>> com.google.gwt.thirdparty.debugging.sourcem

Re: Problem with 2.8.0 rc1 SDM

Meant to say that I'm seeing the same error after switching from beta-2 to
rc2

On Thu, Aug 25, 2016 at 11:15 PM James Horsley <james.hors...@gmail.com>
wrote:

> Doesn't the CodeServer need the gwt-dev.jar though?
>
>
> On Tuesday, August 23, 2016 at 3:45:03 PM UTC+1, viviana zimbone wrote:
>>
>> If you have a maven dependency for gwt-dev, removing it shoudl fix the
>> issue :)
>>
>> Il giorno martedì 16 agosto 2016 11:03:03 UTC+2, Alberto Mancini ha
>> scritto:
>>>
>>> Unfortunately removing the temporary files does not helps.
>>> Today we try to investigate further and eventually we will open an
>>> issue.
>>>
>>> Thanks,
>>>A.
>>>
>>> On Sun, Aug 14, 2016 at 12:52 AM Andrei Korzhevskii <a.korz...@gmail.com>
>>> wrote:
>>>
>>>> Reading the stacktrace, I think the problem is in
>>>> https://github.com/gwtproject/gwt/blob/master/dev/core/src/com/google/gwt/core/linker/SymbolMapsLinker.java#L282
>>>> ,
>>>> looks like disk cache returns null there.
>>>>
>>>> Did you try to remove folder /var/folders/63/qxvnlkdn7yq2n689wbryx_
>>>> vwrfzqfp/T/gwt-codeserver-2706361954965741673.tmp
>>>> and run compile again?
>>>>
>>>>
>>>> On Friday, August 12, 2016 at 12:04:44 AM UTC+3, Alberto Mancini wrote:
>>>>>
>>>>> Hello,
>>>>> in the attempt of porting an internal project from beta1 to rc1 we faced
>>>>> an issue i do not understand how to debug.
>>>>>
>>>>> The project uses errai but my feeling is that the problem is not
>>>>> related to it because similar projects with errai work without problems.
>>>>>
>>>>> Essentially SDM fails during the first compilation and the problem
>>>>> seems in the generation of the source maps.
>>>>>
>>>>> The relevant error log follows.
>>>>>
>>>>> [INFO] GET /recompile/it.e.u.Application
>>>>> [INFO]Job it.e.u.Application_1_0
>>>>> [INFO]   starting job: it.e.u.Application_1_0
>>>>> [INFO]   binding: user.agent=safari
>>>>> [INFO]   Compiling module it.e.u.Application
>>>>> ...
>>>>>
>>>>> [INFO]  Unification traversed 54946 fields and methods and 5256 
>>>>> types. 5210 are considered part of the current module and 5210 had all of 
>>>>> their fields and methods traversed.
>>>>> [INFO]  Compiling 1 permutation
>>>>> [INFO] Compiling permutation 0...
>>>>> [INFO] Linking per-type JS with 5190 new/changed types.
>>>>> [INFO] Source Maps Enabled
>>>>> [INFO]  Compile of permutations succeeded
>>>>> [INFO]  Compilation succeeded -- 35.850s
>>>>> [INFO]   Linking into 
>>>>> /var/folders/63/qxvnlkdn7yq2n689wbryx_vwrfzqfp/T/gwt-codeserver-2706361954965741673.tmp/it.e.u.Application/compile-2/war/it.e.u.Application;
>>>>>  Writing extras to 
>>>>> /var/folders/63/qxvnlkdn7yq2n689wbryx_vwrfzqfp/T/gwt-codeserver-2706361954965741673.tmp/it.e.u.Application/compile-2/extras/it.e.u.Application*[INFO]
>>>>>   [WARN] Can't write source map 
>>>>> CCA06A04193EDF5B35BDE836DF1FABBE_sourceMap0.json
>>>>> [INFO] java.lang.NullPointerException*
>>>>> [INFO]at 
>>>>> com.google.gwt.thirdparty.debugging.sourcemap.SourceMapConsumerV3.parse(SourceMapConsumerV3.java:101)
>>>>> [INFO]at 
>>>>> com.google.gwt.thirdparty.debugging.sourcemap.SourceMapConsumerV3.parse(SourceMapConsumerV3.java:88)
>>>>> [INFO]at 
>>>>> com.google.gwt.thirdparty.debugging.sourcemap.SourceMapConsumerV3.parse(SourceMapConsumerV3.java:78)
>>>>> [INFO]at 
>>>>> com.google.gwt.thirdparty.debugging.sourcemap.SourceMapGeneratorV3.mergeMapSection(SourceMapGeneratorV3.java:311)
>>>>> [INFO]at 
>>>>> com.google.gwt.core.linker.SymbolMapsLinker.link(SymbolMapsLinker.java:316)
>>>>> [INFO]at 
>>>>> com.google.gwt.core.ext.linker.impl.StandardLinkerContext.invokeLinkForOnePermutation(StandardLinkerContext.java:384)
>>>>> [INFO]at com.google.gwt.dev.Link.finishPermutation(Link.java:483)
>>>>> [INFO]at 
>>>>> com.google.gwt.dev.Link.doSimulatedShardingLink(Link.java:

Re: Problem with 2.8.0 rc1 SDM

Doesn't the CodeServer need the gwt-dev.jar though?

On Tuesday, August 23, 2016 at 3:45:03 PM UTC+1, viviana zimbone wrote:
>
> If you have a maven dependency for gwt-dev, removing it shoudl fix the 
> issue :)
>
> Il giorno martedì 16 agosto 2016 11:03:03 UTC+2, Alberto Mancini ha 
> scritto:
>>
>> Unfortunately removing the temporary files does not helps. 
>> Today we try to investigate further and eventually we will open an issue. 
>>
>> Thanks,
>>A. 
>>
>> On Sun, Aug 14, 2016 at 12:52 AM Andrei Korzhevskii  
>> wrote:
>>
>>> Reading the stacktrace, I think the problem is in 
>>> https://github.com/gwtproject/gwt/blob/master/dev/core/src/com/google/gwt/core/linker/SymbolMapsLinker.java#L282
>>> ,
>>> looks like disk cache returns null there.
>>>
>>> Did you try to remove folder /var/folders/63/qxvnlkdn7yq2n689wbryx_
>>> vwrfzqfp/T/gwt-codeserver-2706361954965741673.tmp
>>> and run compile again?
>>>
>>>
>>> On Friday, August 12, 2016 at 12:04:44 AM UTC+3, Alberto Mancini wrote:

 Hello,
 in the attempt of porting an internal project from beta1 to rc1 we faced 
 an issue i do not understand how to debug. 

 The project uses errai but my feeling is that the problem is not 
 related to it because similar projects with errai work without problems. 

 Essentially SDM fails during the first compilation and the problem 
 seems in the generation of the source maps. 

 The relevant error log follows.

 [INFO] GET /recompile/it.e.u.Application
 [INFO]Job it.e.u.Application_1_0
 [INFO]   starting job: it.e.u.Application_1_0
 [INFO]   binding: user.agent=safari
 [INFO]   Compiling module it.e.u.Application
 ...

 [INFO]  Unification traversed 54946 fields and methods and 5256 
 types. 5210 are considered part of the current module and 5210 had all of 
 their fields and methods traversed.
 [INFO]  Compiling 1 permutation
 [INFO] Compiling permutation 0...
 [INFO] Linking per-type JS with 5190 new/changed types.
 [INFO] Source Maps Enabled
 [INFO]  Compile of permutations succeeded
 [INFO]  Compilation succeeded -- 35.850s
 [INFO]   Linking into 
 /var/folders/63/qxvnlkdn7yq2n689wbryx_vwrfzqfp/T/gwt-codeserver-2706361954965741673.tmp/it.e.u.Application/compile-2/war/it.e.u.Application;
  Writing extras to 
 /var/folders/63/qxvnlkdn7yq2n689wbryx_vwrfzqfp/T/gwt-codeserver-2706361954965741673.tmp/it.e.u.Application/compile-2/extras/it.e.u.Application*[INFO]
   [WARN] Can't write source map 
 CCA06A04193EDF5B35BDE836DF1FABBE_sourceMap0.json
 [INFO] java.lang.NullPointerException*
 [INFO] at 
 com.google.gwt.thirdparty.debugging.sourcemap.SourceMapConsumerV3.parse(SourceMapConsumerV3.java:101)
 [INFO] at 
 com.google.gwt.thirdparty.debugging.sourcemap.SourceMapConsumerV3.parse(SourceMapConsumerV3.java:88)
 [INFO] at 
 com.google.gwt.thirdparty.debugging.sourcemap.SourceMapConsumerV3.parse(SourceMapConsumerV3.java:78)
 [INFO] at 
 com.google.gwt.thirdparty.debugging.sourcemap.SourceMapGeneratorV3.mergeMapSection(SourceMapGeneratorV3.java:311)
 [INFO] at 
 com.google.gwt.core.linker.SymbolMapsLinker.link(SymbolMapsLinker.java:316)
 [INFO] at 
 com.google.gwt.core.ext.linker.impl.StandardLinkerContext.invokeLinkForOnePermutation(StandardLinkerContext.java:384)
 [INFO] at com.google.gwt.dev.Link.finishPermutation(Link.java:483)
 [INFO] at 
 com.google.gwt.dev.Link.doSimulatedShardingLink(Link.java:445)
 [INFO] at com.google.gwt.dev.Link.link(Link.java:178)
 [INFO] at com.google.gwt.dev.Compiler.compile(Compiler.java:244)
 [INFO] at 
 com.google.gwt.dev.codeserver.Recompiler.doCompile(Recompiler.java:362)
 [INFO] at 
 com.google.gwt.dev.codeserver.Recompiler.compile(Recompiler.java:175)
 [INFO] at 
 com.google.gwt.dev.codeserver.Recompiler.recompile(Recompiler.java:134)
 [INFO] at 
 com.google.gwt.dev.codeserver.Outbox.recompile(Outbox.java:135)
 [INFO] at 
 com.google.gwt.dev.codeserver.JobRunner.recompile(JobRunner.java:113)
 [INFO] at 
 com.google.gwt.dev.codeserver.JobRunner.access$000(JobRunner.java:37)
 [INFO] at 
 com.google.gwt.dev.codeserver.JobRunner$2.run(JobRunner.java:90)
 [INFO] at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
 [INFO] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
 [INFO] at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
 [INFO] at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
 [INFO] at java.lang.Thread.run(Thread.java:745)
 [INFO]  Invoking Linker Export

Re: GWT 2.8.0 RC2 is here!

2016-08-22 Thread James Horsley

I saw there were some commits to master after RC2 was cut. Are there plans
to cut an RC3 or just roll those commits into the GA?

On Fri, Aug 19, 2016 at 5:31 PM Alexander Polunochev 
wrote:

> Hi Daniel,
>
> Link to download SDK on the official page still points to RC1.
> http://www.gwtproject.org/download.html
>
>
>
> On Thursday, August 11, 2016 at 6:25:18 PM UTC-7, Daniel Kurka wrote:
>>
>> Hi all,
>>
>> I just build the GWT 2.8.0 RC2 and pushed it to maven central. The
>> complete SDK is also available from here .
>>
>> Please start testing and let us know if you run into any trouble and file
>> bugs .
>>
>> We are planing to release this as GWT 2.8.0 if we do not here about any
>> serious issues within the next two weeks. The release notes for RC
>> 2
>>  will
>> be made available shortly after this notice, in the mean time you can take
>> a look at the github repository
>> 
>> .
>>
>> Daniel,
>> on behalf of the GWT team
>>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Experimental release of Elemental2

2016-08-19 Thread James Horsley

Sounds great. Thanks!

On Fri, Aug 19, 2016 at 4:27 PM Julien Dramaix <julien.dram...@gmail.com>
wrote:

> elemental2 is generated from closure extern files.
>
> The open source version of the generator should have a support for
> converting d.ts file to java. We don't know yet when the generator will be
> open sourced.
>
> On Fri, Aug 19, 2016 at 4:12 PM James Horsley <james.hors...@gmail.com>
> wrote:
>
>> I remember hearing that elemental2 was being generated from TypeScript
>> definitions. If that's true, is there any chance we could get a look at the
>> generator code too?
>>
>>
>> On Thursday, June 30, 2016 at 1:23:51 AM UTC+1, Julien Dramaix wrote:
>>>
>>> A new experimental version of Elemental2 using the new JsInterop
>>> specification has been pushed on Sonatype today.
>>>
>>> You can try it by downloading the jar file
>>> <https://oss.sonatype.org/service/local/repositories/google-releases/content/com/google/gwt/elemental2-experimental/16-06-30/elemental2-experimental-16-06-30.jar>
>>> or adding this following maven dependency:
>>>
>>> 
>>>
>>>  com.google.gwt
>>>
>>>  elemental2-experimental
>>>
>>>  16-06-30
>>>
>>> 
>>>
>>> Then, inherits the elemental2 module:
>>>
>>> 
>>>
>>> This experimental version works only with the last 2.8-snapshot release
>>> of GWT.
>>>
>>> The goal of this release is to get feedback so don’t hesitate to report
>>> any bugs, issues, concerns you have on this mailing list.
>>>
>>>
>>> Important note: This is an experimental release and without doubt the
>>> future updates until the final release are going to break code!
>>>
>>> - Julien
>>>
>>> --
>> 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/cd662014-000e-4823-8eab-0acb469c574c%40googlegroups.com
>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/cd662014-000e-4823-8eab-0acb469c574c%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D6y-xP%3DUU-LzPBXj68KPycBT6hdep%3DFehbh8QbPvb_vJQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D6y-xP%3DUU-LzPBXj68KPycBT6hdep%3DFehbh8QbPvb_vJQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

[gwt-contrib] Re: Experimental release of Elemental2

2016-08-19 Thread James Horsley

I remember hearing that elemental2 was being generated from TypeScript 
definitions. If that's true, is there any chance we could get a look at the 
generator code too?

On Thursday, June 30, 2016 at 1:23:51 AM UTC+1, Julien Dramaix wrote:
>
> A new experimental version of Elemental2 using the new JsInterop 
> specification has been pushed on Sonatype today.
>
> You can try it by downloading the jar file 
> 
>  
> or adding this following maven dependency:
>
> 
>
>  com.google.gwt
>
>  elemental2-experimental
>
>  16-06-30
>
> 
>
> Then, inherits the elemental2 module:
>
> 
>
> This experimental version works only with the last 2.8-snapshot release of 
> GWT.
>
> The goal of this release is to get feedback so don’t hesitate to report 
> any bugs, issues, concerns you have on this mailing list.
>
>
> Important note: This is an experimental release and without doubt the 
> future updates until the final release are going to break code!  
>
> - Julien
>
>

-- 
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/cd662014-000e-4823-8eab-0acb469c574c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ui Binder Alternatives

2016-07-26 Thread James Horsley

Something like Elemento + Elemental 2 seems like a great lightweight choice
in the future.

FWIW I agree with Paul that UiBinder plus some top layer of the widget API
(UIObject, Widget, etc.) will get ported over to work with GWT 3.0 by the
community. There's no reason it can't work with Java APT + JsInterop, just
needs the tech investment. I think this will be a huge help for many teams
doing a gradual upgrade.

On Tue, Jul 26, 2016 at 7:43 AM zakaria amine 
wrote:

> Elemento project sounds like an intersting alternative:
> https://github.com/hal/elemento
>
>
> Le dimanche 24 juillet 2016 03:40:02 UTC+2, N Troncoso a écrit :
>>
>> With GWT 3.0, Widgets and UI Binder is losing support. Even besides that,
>> I'm not a huge fan of UI Binder. I'd really just prefer to use vanilla
>> HTML. With that said, I've been searching for other options and I've only
>> found that alternatives are very limited. Even more so, examples of how to
>> integrate alternatives into GWT are basically non-existent. So, my question
>> is, what can I use instead of Widgets and UI Binder and where can I find
>> examples/tutorials/documentation on how to use them in GWT.
>>
>> I found Errai  as one option. But, this
>> seems to be an entire framework, rather than just a template system.
>>
>> Any insight would be greatly appreciated. Thanks
>>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Experimental release of Elemental2

2016-06-30 Thread James Horsley

This is brilliant. Thanks for sharing the experimental version!!!

On Thu, Jun 30, 2016 at 1:23 AM 'Julien Dramaix' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

> A new experimental version of Elemental2 using the new JsInterop
> specification has been pushed on Sonatype today.
>
> You can try it by downloading the jar file
> 
> or adding this following maven dependency:
>
> 
>
>  com.google.gwt
>
>  elemental2-experimental
>
>  16-06-30
>
> 
>
> Then, inherits the elemental2 module:
>
> 
>
> This experimental version works only with the last 2.8-snapshot release of
> GWT.
>
> The goal of this release is to get feedback so don’t hesitate to report
> any bugs, issues, concerns you have on this mailing list.
>
>
> Important note: This is an experimental release and without doubt the
> future updates until the final release are going to break code!
>
> - Julien
>
> --
> 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/CABXeq2Q%3DuH8beWj4tiG28tycASsJxK8mnxxNPZnEykUeTcMWXw%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: GWT React

2016-04-14 Thread James Horsley

Great work Paul. Thanks for sharing.

On Thu, Apr 14, 2016 at 1:57 PM Paul Stockley  wrote:

> I plan on doing this. I have a couple of things I need to prove out then I
> will start working on setting up the Github projects. I will post a preview
> to my google drive in a couple of weeks so you can take a look while I work
> on setting up the projects on Github.
>
>
> On Thursday, April 14, 2016 at 1:35:06 AM UTC-4, Debasish Padhy wrote:
>>
>> Hi Paul,
>>
>> Is there a possibility of you sharing the codebase over github and put a
>> license to it ? I have been working extensively with JsInterOp / TypeScript
>> cross usage and find your  POC interesting and would love to contribute if
>> its with an open license.
>>
>> thanks,
>> Debasish
>>
>> On Thursday, April 7, 2016 at 6:48:27 PM UTC+5:30, Paul Stockley wrote:
>>>
>>> Sorry,
>>>   I was just updating it to include samples for Redux that I just got
>>> working. The new link is
>>> https://drive.google.com/folderview?id=0Bxp8vLBG2ol3ZERCc3lHUEhKU2M=sharing
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "GWT Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

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

2016-03-22 Thread James Northrup

+1 for hacky prototype to play with.  this is the top search result for 
'gwt elemental2'  +4 months since last post 


On Monday, November 30, 2015 at 10:42:23 PM UTC-8, James Nelson wrote:
>
> +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/8937f964-2f16-43a7-bb14-42c7f943d5d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Is anybody of you guys using GWT with Lombok?

2016-03-19 Thread James Horsley

I haven't used Lombok due to similar reasons as Jens described but have had
really great success with annotation processing libraries like Immutables (
http://immutables.github.io/), AutoValue, etc. I've even started writing my
own annotation processors to help reduce boilerplate.

On Wed, Mar 16, 2016 at 12:37 PM Jens  wrote:

> If its just for value classes and factories you better use Google's
> AutoValue / AutoFactory projects which are based on annotation processing
> instead of hacking the Java compiler as Lombok does.
>
> Personally I would never use Lombok. As it adds code during compilation,
> that code is invisible to tools that work on Java source. IMHO Lombok is
> fragile and can break easily with any JDK update, you can also see this in
> the changelog as it contains quite some "Bugfix: X breaks starting with JDK
> Y". The reason is that Lombok relies on the com.sun.tools.javac package
> which is considered a private API.
>
> So I would generally advice using annotation processors instead.
>
> -- J.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Trying to use JsInterop to work with React

2016-03-19 Thread James Horsley

Paul, brilliant news. Look forward to hopefully taking a look at your code
if you're able to share.

On Fri, Mar 18, 2016 at 4:15 PM Paul Stockley  wrote:

> Success! With some javascript hacking I have managed to get it working. I
> can access state and props and set state as a result of an onClick event. I
> think it might be possible to get react fully working. Below is my somewhat
> contrived solution
>
>
> --
> 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/2af4ca30-e14c-477f-aad4-b3d4b2d7a27b%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [gwt-contrib] Trying to use JsInterop to work with React

2016-03-13 Thread James Horsley

Paul, any chance you're thinking of releasing your code on github or
something? I think an open sourced ReactJs-GWT jsinterop wrapper would be
something a number of people might be interested in using and contributing
to.

On Sun, Mar 13, 2016 at 9:45 PM Paul Stockley  wrote:

> I did think about the ES6 class approach. However, The createElement
> method would need to take the class as a parameter (not an instance). How
> would I do that?
>
>
>
> On Sunday, March 13, 2016 at 5:32:19 PM UTC-4, Goktug Gokdogan wrote:
>
>> See examples on how ES6 classes work with React. Those examples should
>> apply to @JsTypes as well.
>>
> On Sun, Mar 13, 2016 at 2:12 PM, Colin Alworth  wrote:
>>
> Yikes, that's rather opinionated. I don't personally work with React, but
>>> I guess I'm surprised that it can't handle actual inheritance (or even
>>> defining a prototype and attaching it to a constructor).
>>>
>>> Based on what you have there and the details described at
>>> https://facebook.github.io/react/docs/top-level-api.html, I'd suspect
>>> that they actually want the equivalent of the class object itself, not an
>>> instance of it (the line between them is blury in JS already).
>>>
>>> > One thing that makes components different than standard prototypal
>>> classes is that you don't need to call new on them. They are convenience
>>> wrappers that construct backing instances (via new) for you.
>>>
>>> This seems to imply that you can't be guaranteed that your constructors
>>> will actually be called, but also reinforces the idea that they don't want
>>> you to pass in a class instance, just the methods that should be called on
>>> the eventually-created instances. More details from
>>> https://facebook.github.io/react/docs/component-specs.html seem to say
>>> that you are actually expected to pass in just a bag of properties, one of
>>> which will be that `render` function, which can trust that a `this` will be
>>> specified to provide `props` and `state`.
>>>
>>> If there is a hook that lets you define your own constructor or factory
>>> method, that would be good to have to correctly do the GWT object wiring
>>> (perhaps some jsinterop expert can pipe up here as to what will be lost
>>> without that being called). Otherwise, some jsni or JsObject-building code
>>> that copies references to functions over to the a map-like object would be
>>> ideal. A JsProperty-annotated field may be enough to convince the compiler
>>> to generate correct code inside your function to access those properties,
>>> but I would be less sure about non-static helper methods still being around
>>> in the generated component.
>>>
>>
>>> On Sun, Mar 13, 2016 at 3:35 PM Paul Stockley 
>>> wrote:
>>>
 We have started using React (using ES6 and FlowTypes) which is quite
 nice. However, we have a large GWT application that we want to start
 embedding React within. This makes perfect sense for migrating away from
 Widgets to a more modern approach. So I decided I would try and define a
 Java Api for React. After a couple of hours I got a really hacky prototype
 basically working. The code looks like

 private ClassicComponentClass customComponent;


 public void onModuleLoad() {

 customComponent = React.createClass(new CustomComponent());

 HTMLProps props = Props.newHTML();
 props.setDefaultValue("Test");

 DOMElement div =
 React.createElement("div", props,
 React.createElement("div", null),
 React.createElement(customComponent, null),
 React.createElement("div", null, "An example")
 );

 ReactDOM.render(div, Document.get().getElementById("mainCont"));
 }


 @JsType(namespace = JsPackage.GLOBAL, name="CustomComponent")
 public class CustomComponent {

 @JsMethod
 public ReactElement render() {
 return React.createElement("div", null, "It works");
 }
 }



 This works fine for intrinsic React components. The problem is defining 
 custom components. The React.createClass function needs to take a plain 
 javascript object with certain methods defined (render, lifecyle methods 
 etc). If I pass a Java object marked as JsType, this doesn't work because 
 the render method needs to be defined on the top level object. The code 
 puts it on a different prototype which doesn't work because React does the 
 following:



   for (var name in spec) {
 if (!spec.hasOwnProperty(name)) {  --Isn't true for render
   continue;
 }


 Is there some way to achieve what I want with JsInterop?  I tried 
 extending another base class marked with isNative=true. However, this 
 results in a runtime error when trying to construct an object of that type.

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

2015-11-30 Thread 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: What is j2cl?

2015-11-27 Thread James Nelson

Ok.

So, I have Map, how do I map that to 
goog.structs.Map?

The closure objects do not behave 100% the same as the java objects, and if 
you expect your code to do the same thing on every platform (very common, 
reasonable expectation), then you can't pick an emulation library that is 
functionally different.

For maps with string keys maybe then you could use closure Map, but the 
emulated java Maps all have optimizations for String that just make them 
behave like a javascript dictionary.
Or things like Iterators; how are you going to map a java iterator such 
that it will just work, without having to change any code?  Emulation, 
maybe?

Sooo, I still don't see any path to actually removing the emulation code.

Unless you can get a perfect 1:1 mapping to java apis, people are going to 
use a java type, and not get java behavior.  That would be Very Bad (tm).

There are plenty of options for making your own Map or Set type that itself 
maps to closure and can have slightly different behavior,
and it would be on you to proactively choose this map/list/set type 
yourself.

I actually don't use java.util collections and prefer my own abstraction 
which can supply an optimized api for whatever platform you are on (I 
specialize in cross platform; I maintain a library called xapi);
even though I also maintain a fork of Gwt where I could just mod the 
java.util classes to "work better for javascript", I would not do such a 
thing, because whenever I ask for an ArrayList or a LinkedHashSet, I want 
exactly the behavior those classes claim to expose.

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

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

2015-11-22 Thread James Horsley

When both Elemental2 and JsInterop are released I think that the community
will start to innovate on this front and new libraries will pop up on
github to address these needs; "if you build it, they will come" and all
that.

I know I'm very much looking forward to Elemental2 + Jsinterop as a
platform to build on.

On Sun, Nov 22, 2015 at 6:45 AM 'Ray Cromwell' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

> There could be a separate Json library build with JsInterop. Some of the
> decisions I made in the design of the original Elemental JSON were made
> specifically because of DevMode support and GWT optimization internals.
> Given the unboxing of Double and Boolean, and the elimination of DevMode,
> the library can be much simpler now and still have a JVM implementation to
> be portable.
>
> On Sat, Nov 21, 2015 at 10:28 PM, 'Goktug Gokdogan' via GWT Contributors <
> google-web-toolkit-contributors@googlegroups.com> wrote:
>
>> Elemental2 will be just an auto-generated thin wrapper around the browser
>> APIs. Unlike Elemental1, it will not provide a cross platform JSON
>> implementation.
>>
>> I don't think you need to report compatibility bugs for Elemental1 unless
>> a maintainer steps up and shows interest.
>>
>> On Sat, Nov 21, 2015 at 1:42 PM, Erik Kuefler  wrote:
>>
>>> What's the current thinking regarding JSON in Elemental 2? That part has
>>> always been a bit different from the DOM libraries, and I know there was
>>> talk a long time back about splitting it out. I've been using Elemental
>>> JSON extensively in my projects just to have a JSON library that works in
>>> GWT and in JVM, but I've found it to be extremely buggy (mostly in terms of
>>> behavior differences between jvm, optimized gwt, and draft mode gwt). Are
>>> these bugs worth reporting? Is it all being reworked for Elemental 2?
>>>
>>> On Friday, November 20, 2015 at 12:36:22 PM UTC-8, Ray Cromwell wrote:

 Another thing to consider is that J2CL was developed as a 'bake off',
 in which multiple prototypes and designs were discussed/looked at (compile
 from Java with JDT, compile from bytecode, compile using Javac APIs,
 writing parser by hand, etc) It would have been a bit premature to release
 any of them as they were all known ahead of time to be throwaways.

 I have a hacky Elemental2 prototype (which is not the official one that
 Julien is working on), if you want to take it and play around.



 On Fri, Nov 20, 2015 at 10:30 AM, 'Goktug Gokdogan' via GWT
 Contributors  wrote:

> No worries :)
>
> On Fri, Nov 20, 2015 at 10:27 AM, Stephen Haberman <
> stephen@gmail.com> wrote:
>
>> Hi Goktug,
>>
>> That's all true, thanks for providing a counter data point. You're
>> right, the JsInterop design docs/etc. were all out in the open from day 
>> 1,
>> which I thought was pretty exiting.
>>
>> I definitely can't take any credit for providing useful feedback, but
>> I enjoyed seeing the thoughts and process from the community.
>>
>> So, apologies for the sweeping statement.
>>
>> - Stephen
>>
>>
>>
>> On Fri, Nov 20, 2015 at 11:58 AM, 'Goktug Gokdogan' via GWT
>> Contributors 
>> wrote:
>>
>>> Singular is not a Google project and not being developed internally.
>>> It is Daniel's personal project and as fas as I know it is already in 
>>> the
>>> open source.
>>>
>>> We don't have anything to share for Elemental yet. We are talking
>>> with other teams, thinking about alternatives etc. Also when we 
>>> release, it
>>> will not be part of GWT-SDK so there is going be extra work to move the
>>> development outside; which doesn't make sense at this stage.
>>>
>>> The big things we recently developed for GWT, JsInterop and
>>> SuperDevMode and they were all open source from day one.
>>>
>>> On Fri, Nov 20, 2015 at 5:34 AM, Stephen Haberman <
>>> stephen@gmail.com> wrote:
>>>
 > Meanwhile I will revive my own generator project.

 I'll take the opportunity to hop on a soapbox, but the "closed
 source/eventually open source" model is a curious trend that I think 
 I've
 only seen in the GWT community (are their other examples?)...

 Musing, it probably stems from Google setting the example with GWT
 itself, where historically a lot happened internally before being 
 mirrored
 externally, but it happens a bit for non-Google-GWT projects as well, 
 like
 the repackaging of GPE, which was closed during initial development
 (although the result is great, and I really appreciate it), Singular, 
 which
 is still closed during initial

Re: What is j2cl?

2015-11-18 Thread James Nelson

Marko, even is the closure libs were extended to look like java Map/Set, 
that does not replace the need to emulate Map/Set.

Gwt already has its own versions of HashMap and ilk, and even if they could 
compile them directly to closure types,
we would STILL need to use the java.util.* apis, because the whole point of 
a java transpiler is that you can use all the core types across all your 
environments.

Consider the typical cross platform project... web, android, ios (via 
j2objc, etc).
If you want to share code between them, you use types they all have (Map, 
Set, List, etc).
If you have platform specific code, you can use a js map or whatever you 
have.

On Saturday, October 24, 2015 at 9:48:06 AM UTC-7, Marko wrote:
>
> Thank you Thomas for this answer! This is great!
>
> Replacing JRE emulation with Closure Library (java.util.HashMap => 
> goog.structs.Map, java.util.Set => goog.structs.Set, etc.) would eliminate 
> the need for JRE emulation and protect us in case Oracle wins in court. I 
> guess that in this case Closure Library will need to be extended with some 
> methods and classes in order to provide functionality which is present 
> today in JRE emulation library. But this can also be done later (j2cl v2.0).
>
> Marko
>
> On Saturday, October 24, 2015 at 12:31:40 AM UTC+2, Thomas Broyer wrote:
>>
>>
>>
>> On Saturday, October 24, 2015 at 12:14:17 AM UTC+2, Marko wrote:
>>>
>>> I see the term "j2cl" comming up in several threads connected with GWT 
>>> 3.0. What does it mean?
>>>
>>> I speculate that this is a "Java-to-Closure-Library" transpiler, which 
>>> would be GREAT, because you wouldn't depend on JRE emulation library 
>>> anymore and GWT 3.0 would be safe from "Oracle copyright lawsuit nonsense". 
>>> Additionally you could integrate JavaScript Closure Library code with Java 
>>> code transpiled to Closure Library and it would use the exactly same class 
>>> library... I guess also that Google would profit from such a transpiler in 
>>> Google Inbox and other similar projects...
>>>
>>> I hope I am not speculating too much into the Google's trade secrets and 
>>> that this post will not be deleted because of this... :-)
>>>
>>
>> You're almost right (Googlers will correct me if I'm wrong).
>>
>> j2cl stands for Java-to-CLosure. It's not much about the Closure Library 
>> but rather the Closure Compiler. It's a transpiler from Java to 
>> Closure-annotated ES6 (there are a couple videos about this from the GWT 
>> Meetup earlier this year: 
>> https://www.youtube.com/playlist?list=PL1yReUCGwGvrqscLu1EAyYRPrr0ceEHLE 
>> ), type annotations will help the Closure Compiler prune unused code to 
>> further optimize the produced JS.
>>
>> But it won't free us from the JRE emulation library.
>>
>

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

[gwt-contrib] Re: Steering Committee Meeting Notes (8/19)

2015-08-22 Thread James Horsley

Thanks!

On 21 August 2015 at 17:48, 'Bhaskar Janakiraman' via GWT Steering 
gwt-steer...@googlegroups.com wrote:

 See:

 https://docs.google.com/document/d/14HaNSGd8-_1VOAQIKWGd4lKmcRQLciL2ISPhE18yOQ4/edit?usp=sharing

 Bhaskar

 --
 You received this message because you are subscribed to the Google Groups
 GWT Steering group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to gwt-steering+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


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

Re: GWT release prioritization

2015-08-10 Thread James Horsley

Any chance someone from the steering committee could comment on this?

On 3 August 2015 at 09:37, maticpetek maticpe...@gmail.com wrote:

 1+


 On Friday, July 31, 2015 at 11:39:00 AM UTC+2, James Horsley wrote:

 Firstly, I am very much looking forward to the next generation j2cl
 compiler for GWT and think the new compiler vision is great. That said, I
 think the community would benefit greatly with the steering committee
 placing a higher priority on closing out on the 2.8 release. I know that
 the current 2.8 is considered usable for production but 2.8 isn't feature
 complete and organizations can be very hesitant to use non-GA versions of
 libraries. In particular it would be a big win to have a done version of
 JsInterop v1 and clear guidance on using the current version of elemental.

 I, and I'm sure the rest of the GWT community, would greatly appreciate a
 clearer view on current release expectations and prioritization; is there
 anything you guys can share on that front?

 Again, really appreciate the recent work and love the plans for GWT 3.0.

 Cheers,
 James

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


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

GWT release prioritization

2015-07-31 Thread James Horsley

Firstly, I am very much looking forward to the next generation j2cl
compiler for GWT and think the new compiler vision is great. That said, I
think the community would benefit greatly with the steering committee
placing a higher priority on closing out on the 2.8 release. I know that
the current 2.8 is considered usable for production but 2.8 isn't feature
complete and organizations can be very hesitant to use non-GA versions of
libraries. In particular it would be a big win to have a done version of
JsInterop v1 and clear guidance on using the current version of elemental.

I, and I'm sure the rest of the GWT community, would greatly appreciate a
clearer view on current release expectations and prioritization; is there
anything you guys can share on that front?

Again, really appreciate the recent work and love the plans for GWT 3.0.

Cheers,
James

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

Re: Research on Elemental

2015-07-02 Thread James Horsley

Is it recommended to use the current elemental API even though it's not
based on JsInterop yet? For example, if I use the current elemental API,
can I expect that Elemental 2.0 should be a fairly easy transition?

On Sun, Jun 21, 2015 at 5:14 PM Lukas Glowania lukas.glowa...@gmail.com
wrote:

 Great resource! Thanks a lot.

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


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

Re: Important videos from GWT Meet-up 2015

2015-06-21 Thread James Horsley

Thanks Thomas.

Good point on getting started experimenting before the compiler is made
available. I've been building a few of libraries using APT for code
generation recently, making use of the wonderful google  square libraries
like auto and javapoet. I think it'd be pretty straightforward to build an
annotation processor for a few existing libraries e.g. i18n. However, I'm
really hoping to make use of GWT compiler level solutions to overcome some
current APT challenges; in particular, invoking the processor when non-java
files are changed such as ui.xml files. Daniel mentioned in his talk that
there might be a general solution for this which would be pretty awesome to
use.

I was probably too specific in asking for early access to the compiler.
Early access to elemental 2.0 and jsinterop 2.0 would be really helpful to
try and figure out how to port JSNI/JSO code over to jsinterop.

In general my experience with GWT + APT for my own libraries has been
really good, so I'm quite positive about the plans for GWT 3.0. Hopefully,
with a clear migration story, the community will be able to smooth any
rough edges that the core GWT team can't take on.



On Sun, Jun 21, 2015 at 11:18 AM Thomas Broyer t.bro...@gmail.com wrote:



 On Sunday, June 21, 2015 at 11:17:50 AM UTC+2, James Horsley wrote:

 Also worth noting that, outside of GWT-RPC, I think that many of the
 current major GWT features (widgets, uibinder, etc.) could be ported by the
 community such that only minor code changes are necessary. I would even
 hazard a guess that companies like Vaadin might be interested in supporting
 or at least contributing to a 3.0 based port things like the widget library.


 I'd rather bet on Sencha for widgets.
 (note: I have absolutely no information about whether this will happen and
 who would make it happen)


 As I've said in other emails though, I think the migration/transition
 story from 2.8 - 3.0 needs work and open communication. Based on what's in
 the videos from the meetup, I don't think it has to be as radical of a
 change as is feared. To make it smoother, hopefully there will be early
 access to the compiler API such that the community can start thinking about
 building 3.0 versions of libraries we want available.


 You don't need access to the new compiler for that, you can start
 experimenting right now: given that the idea is that the GWT.create() magic
 will be removed and things would have to be generated upfront using JavaC
 and annotation processors, that means the generated code has no GWT magic
 (besides possibly JSNI, which would have to eventually change to JsInterop
 or JSNI 2.0) and can still be compiled using the current compiler (or
 2.8.0-SNAPSHOT if you need System.getProperty(user.agent)).
 Disclaimer: I haven't yet tried it though.
 Note that if you'd like to start experimenting with annotation processors,
 I highly suggest you use auto-common's BasicAnnotationProcessor and other
 utilities: https://github.com/google/auto/tree/master/common

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


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

Re: Important videos from GWT Meet-up 2015

2015-06-21 Thread James Horsley

Also worth noting that, outside of GWT-RPC, I think that many of the
current major GWT features (widgets, uibinder, etc.) could be ported by the
community such that only minor code changes are necessary. I would even
hazard a guess that companies like Vaadin might be interested in supporting
or at least contributing to a 3.0 based port things like the widget library.

As I've said in other emails though, I think the migration/transition story
from 2.8 - 3.0 needs work and open communication. Based on what's in the
videos from the meetup, I don't think it has to be as radical of a change
as is feared. To make it smoother, hopefully there will be early access to
the compiler API such that the community can start thinking about building
3.0 versions of libraries we want available.

On Sun, Jun 21, 2015 at 3:19 AM David jim.p...@gmail.com wrote:

 When is GWT 3 available?


 On Sunday, June 21, 2015 at 6:38:50 AM UTC+8, Paul Robinson wrote:

 I suspect most people here just haven't quite realised the magnitude of
 what's planned. The plans are quite reasonable for anybody that can start
 from scratch (which doesn't include me). Anybody invested in GWT will have
 a problem. That includes Google, although there are no obvious plans for a
 migration path.

 It might mean GWT forks, although I can't see anybody new to GWT adopting
 GWT 2.8 once 3.0 is out, and the current plans will put people off adopting
 GWT now.

 Paul

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


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

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

2015-06-15 Thread James Horsley

Thanks Daniel.

It's great that the steering committee are discussing the topic this early 
in the process; in particular, in the context of how GWT dev's can help 
themselves to be future proof (e.g. your Modernizing GWT talk).

I completely understand how certain GWT generator based libraries that 
require global knowledge don't fit with APT (e.g. GWT-RPC maybe needing the 
transportable types explicitly listed). But, at a glance, it seems like 
other high adoption libraries like UiBinder and the widget library (maybe 
even just some top level pieces?) can be retrofitted and released as 
separate projects to work with the transpiler. 

Hopefully we can leverage the opinions and contributions of the GWT 
community to determine what are essential libraries to carry forward and 
implement plans to make this happen. A few big helping points here would be:

1) Clearly documented ways to future proof new development. What to use, 
what to avoid, examples, etc.
2) Early access to the transpiler when you have a basic API settled, so 
that we can start working on converting our favourite libraries that the 
steering committee don't have time for.
3) Access to Singular. This gives people a future proof view layer to work 
with and I think it will boost confidence/morale for those concerned about 
the 3.0 transition.

Cheers,
James

On Sunday, June 14, 2015 at 8:02:11 PM UTC+1, Daniel Kurka wrote:

 Hi all,

 thanks for sharing your views in this discussion.

 Let me add a little background:

 Currently we the GWT team have decided to work on a new fast transpiler 
 from Java to Closure (our internal enhanced version of JavaScript). This 
 makes sense for a lot of reasons that I won't go into detail on, but here 
 are a few:

 - Our cross platform applications really want a faster and better 
 integration with closure.
 - GWT and closure share a lot of work (optimizations) and this is a good 
 way to not reinvent the wheel constantly

 So at some point we will open source this new compiler which will have 
 some compatibility with the old compiler, but it will not support 
 everything that GWT used to support.
 It is not up to Google to decide if this should be GWT 3.0, but it is up 
 to the steering committee to decide (this is what the steering committee is 
 for).
 However this new compiler works out, Google has tons of GWT applications 
 that would need to move from GWT 2.8 to whatever this new effort is, so 
 coming up with a common feature set and a migration plan is on our work 
 list, but we will focus on that once we actually have a new compiler.

 However we already know that applications that only use a certain feature 
 set (which might grow, as people put in more work), should be fine on both 
 compilers (we should discuss this after the 2.8 release). We only talked 
 about this so early in the process to give the community the ability to 
 provide feedback on our efforts, but don't panic, nothing is set in stone 
 and we (the steering committee) need your input on this.

 -Daniel



 On Sun, Jun 14, 2015 at 4:51 PM Alain Ekambi jazzma...@gmail.com 
 javascript: wrote:

 Also think of people who use GWT for non web based project. 
 We use GWT  for example to create native mobile apps with Titanium. And 
 our customers love the  UI Binder support.

 Dropping UI Binder means we wont be able to support new version of GWT. 

 Such a bad move.

 On 14 June 2015 at 16:22, Travis Schmidt travis@gmail.com 
 javascript: wrote:

 I have the same concerns as the last comment.  We are a java shop and 
 use enterprise java for our back-end.  We have been using GWT for the last 
 9 years to write thin front ends for our applications.  Basically GWT RPC 
 and UiBinder are 99% of the code we deploy.  If I need to replace those 
 with Polymer, Angular and some JSON XHR, then I don't see much need to use 
 GWT going forward.  Am I mistaken or just misunderstanding something?

 On Sun, Jun 14, 2015 at 4:31 AM David david...@gmail.com javascript: 
 wrote:

 I'm excited that you guys are planning a radical change (really). I 
 hope it becomes more clear on what we should be using to future proof our 
 apps. 
 I hope we will get some usable preview of Singular (if that is really 
 going to be a replacement).

 Somehow I am not totally concerned that we will need some major 
 rewrites, it will be hard sell to management and it might mean that we 
 need 
 to look to different directions as well.

 But I am afraid that if GWT is no longer offering a complete solution 
 like it does now (including a UI library, RPC support, i18n, UI binding, 
 ... etc) that a lot of the advantage will be lost for me.

 As for naming, well it seems that non of the three letters still apply 
 to the direction GWT is about to take.
 1) no longer in Google hands (or so they clame)
 2) Web not the main concern since the cross compiler is more to share 
 code between web/android/ios apps.
 3) Toolkit ... it sounds more like a transpiler to me

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

2015-06-13 Thread James Horsley

I think that there's enough branding/momentum/etc. behind the GWT name that
to be taken seriously it should stick with the GWT name, even if possibly
adjusted slightly like Jens's suggestions.

I'm fully behind the direction the compiler is taking and I believe that
the vision put forward in the videos from the GWT meetup is a great one
that will resonate well with developers. My big concern is that the
migration story and timing isn't great right now.

New projects that are starting with GWT 2.8 are somewhat in limbo right
now. I think that things are okay for the business logic and presenter side
of things, but deciding what to do for the view layer is tricky.

JsInterop doesn't feel complete enough to easily use with libraries like
React for the view layer. I've played around with doing this but it seems
very painful without some of the JsInterop 2.0 features (per
https://goo.gl/sKsBGX) in particular the functionality from the Js class to
easily call JS and create JS collections. As such, the best choice seems to
be UiBinder with HTML+CSS and my own minimal JsInterop interfaces for DOM
types. But even that's not future proof under the current plans to not
support UiBinder. If Singular was available it would probably bridge the
gap, but it's not available so we're left picking from choices that aren't
planned to be in GWT 3.0.

An official JsInterop version of elemental would also be a big help to
prevent everyone from creating their own version and having to migrate
later.

I would recommend a doc/page/etc. be started which clearly lists things
that are definitely going to be in GWT 3.0, those that are under
consideration, and those that definitely won't. Also, give trivial examples
future proof setups that dev's can follow to make the 3.0 transition easier.

Cheers,
James

On 13 June 2015 at 14:44, Jens jens.nehlme...@gmail.com wrote:

I kind of agree not calling it GWT 3.0. I would not name it completely
different, maybe something along the lines of GWT X1, GWT RST (abbr. of
reset) or GWT Next. I am pretty sure we could come up with something more
distinct to indicate that this release is a lot different and a reboot of
GWT.

I also think that without drop-in replacements for widget code, UiBinder
and GWT-RPC a lot of apps will not migrate to the new GWT because it is
simply not cost effective. The GWT surveys shows that the majority of apps
depend on these features. Maybe with the help of Singular it is possible to
incrementally rewrite your UI until its compatible with GWT 3.0 but you
still need to rewrite a lot.

I think at the end it boils down to if you want to use the new compiler or
if you are fine with the current SDM development speed of the 2.8 release.
Because all the rest of GWT 3.0 can also be used with GWT 2.8.

-- J.

--
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/76cb0c63-a981-4b54-95bf-ebbd8f773311%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/76cb0c63-a981-4b54-95bf-ebbd8f773311%40googlegroups.com?utm_medium=emailutm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

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

Re: Important videos from GWT Meet-up 2015

2015-06-12 Thread James Horsley

Someone in the video commented that there needs to be a very clear
messaging around how to best protect/future proof yourself. The
Modernizing GWT video was obviously a step in that direction but I'd love
to see something more concrete e.g. if UiBinder won't be supported, what
should we be using?

I had a specific question regarding the recommendation to use Elemental. My
understanding was that Elemental 2.0 was going to be released with GWT 3.0.
Is it safe to use Elemental in it's current state or will there be
significant enough changes that we should wait?

On 12 June 2015 at 15:29, jchimene jchim...@gmail.com wrote:

 Thanks for the link .

 To those who've generously uploaded the videos: any possibility of also
 uploading the slides? The technical presentations are pretty much useless
 w/o the slides.

 TIA,
 jec


 On Friday, June 12, 2015 at 2:21:49 AM UTC-7, Phineas Gage wrote:

 I thought I'd share this link to a series of important videos from the
 recent GWT Meet-up 2015, which was posted on G+ and in the GWT Contributors
 group:

 https://www.youtube.com/playlist?list=PL1yReUCGwGvrqscLu1EAyYRPrr0ceEHLE

 *Summary:*

 For anyone who wasn't already aware, there are seismic changes coming for
 GWT. Basically, gwt-user and everything in it will be gradually mothballed,
 so widgets, GWT-RPC, UiBinder, CssResource, etc. While we're at it, the GWT
 compiler will probably go too. If the plan stays as presented, everything
 is going, sooner or later. It looks as though a much simpler and faster
 Java to JS transpiler is proposed, maybe under a different project name,
 with optimizations handled by Closure. I welcome corrections if I've got
 something wrong here.

 *Editorial:*

 Having used GWT for a number of years, I think this is a massive but
 needed change. It looks like a great direction, that maybe could have been
 taken even sooner. But personally, I now can't see using GWT for new
 projects until it appears in its new form. We're in a kind of purgatory now
 where anything you write in GWT may not be easy to maintain, but the new
 vision is currently just a hope for the future.

 As for myself, since I've got a project in its early stages, I'll
 probably be porting everything I have to JavaScript, until I can count on a
 stable Java to JS transpiler. At that point, I can decide to move some of
 the code back to Java, if it's not too painful and the benefits to doing so
 are clear. At the same time, even with years of Java experience, I have to
 ask myself, why Java? If it's a better language that compiles to JavaScript
 that we want, there are many: Dart is coming along, and there are more
 options than there were before. It's speculation to say what an open source
 Swift will mean, but the external forces affecting these options can play
 themselves out while JavaScript will likely continue to be stable for years
 to come.

 So rather than drag it out, I'd like to see these changes happen ASAP. As
 it's sometimes said, if you find yourself in a hole, stop digging. I
 believe that if a stable and fast Java to JS transpiler were released, the
 community would chip in to help complete JRE emulation or other needed
 projects, and I'm glad to hear that much of the GWT team is being diverted
 to compiler work.

 Thanks to the GWT team for sharing these plans with the community!

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


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

Default/Defender Method Support in JsInterop

2015-04-30 Thread James Horsley

Is support for defender/default methods planned to be support for JsInterop
in GWT 2.8? The change to add general GWT support (
https://gwt-review.googlesource.com/#/c/10330/) called out that JsInterop
support would follow in a subsequent patch but I wasn't sure if it's
targeted for 2.8 or not.

Cheers,
James

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

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

2015-04-23 Thread 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

2015-04-23 Thread 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.

Re: SuperDevMode Running With GWT 2.6.1 (ant/Command Line)

2015-04-20 Thread James Bearden

No, I didn't run accross that nugget and I wish I had. The biggest issues I 
had were A) coming up with an ant target to run CodeServer and B) figuring 
out these basic concepts:

 * SuperDevMode completely replaces DevMode.
 * Unlike DevMode, SuperDevMode has nothing to do with actually 
launching/running your application.
 * There is nothing special you need to do when launching your application 
(seperately).

That last bit had me baffled the longest because with my setup I had to use 
a URL different from the default to get DevMode working, and that took me a 
while to figure out at the time. So with SuperDevMode it took me a LONG 
time to try just running my server and pointing my web browser at it 
without any funky parameters like you do with DevMode.

James

On Sunday, April 19, 2015 at 3:31:53 AM UTC-5, Thomas Broyer wrote:

 Did you stumble on https://stackoverflow.com/a/18333050/116472 during 
 your research? If you did, was there something missing there?
 I might create a new question on SO and copy/paste that answer as a 
 community wiki; or maybe copy/paste that to my blog, to make it easier to 
 find (given that it's not the accepted answer for that question)

 On Sunday, April 19, 2015 at 2:55:35 AM UTC+2, James Bearden wrote:

 Hello,

 I upgraded from GWT 2.6.1 to GWT 2.7 and immediately starting getting 
 reports of my app not launching after being loaded. I was unable to 
 reproduce the issue, so I went back to using GWT 2.6.1 for now. I will try 
 again with 2.7.1 maybe. However, in the mean time, I got REALLY attached to 
 SuperDevMode, or rather not having to manage stale and a fresh versions of 
 my browser. So I really wanted to get SuperDevMode working with GWT 2.6.1. 
 Unfortunately I seem to be one of the few people that prefer not use an IDE 
 to develop, so most of the examples of how to do what I want have been less 
 than helpful. To make things even more interesting, I am using JSON to talk 
 to a Perl server instead of the standard server. I just got it working, so 
 I wanted to share the wealth.

 First edit your project.gwt.xml file and add:

   add-linker name=xsiframe/

 Second, edit your build.xml file and add something like:

   target name=sdm depends=javac description=starts the 
 superdevmode
 java fork=true failonerror=true 
 classname=com.google.gwt.dev.codeserver.CodeServer
   classpath
 pathelement location=src/
 path refid=project.class.path/
 pathelement location=${gwt.sdk}/gwt-codeserver.jar/
 pathelement location=${gwt.sdk}/validation-api-1.0.0.GA.jar /
 pathelement 
 location=${gwt.sdk}/validation-api-1.0.0.GA-sources.jar /
   /classpath
   arg value=-src/
   arg value=${basedir}/src/
   arg value=com.myproject.Project/
 /java
   /target

 Third, assuming everything works right, when you ant the sdm target it 
 will provide a URL. If you go to that URL it will give you a bookmarkable 
 URL to start SuperDevMode and another one to stop it. Yes, you really need 
 to at least add the Dev Mode On bookmark. After you do that then you can 
 close the tab and probably never visit it again.

 Fourth, and this was the hardest part for me to figure out from the 
 information given, is you need to go to the same base URL to run your 
 application that regular DevMode uses. In other words, omit the gwt.codesvr 
 parameter.  In my case that is http://localhost:3000/app/index.htm;, 
 but it will definitely be different for you unless you are running a 
 development Mojolicious server. Your app should load, and then you click 
 your Dev Mode On bookmark to recompile and reload. It's a little clunky 
 having to click the button to recompile, but it's a whole lot better than 
 running an old version of a browser.

 James



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

SuperDevMode Running With GWT 2.6.1 (ant/Command Line)

2015-04-18 Thread James Bearden

Hello,

I upgraded from GWT 2.6.1 to GWT 2.7 and immediately starting getting 
reports of my app not launching after being loaded. I was unable to 
reproduce the issue, so I went back to using GWT 2.6.1 for now. I will try 
again with 2.7.1 maybe. However, in the mean time, I got REALLY attached to 
SuperDevMode, or rather not having to manage stale and a fresh versions of 
my browser. So I really wanted to get SuperDevMode working with GWT 2.6.1. 
Unfortunately I seem to be one of the few people that prefer not use an IDE 
to develop, so most of the examples of how to do what I want have been less 
than helpful. To make things even more interesting, I am using JSON to talk 
to a Perl server instead of the standard server. I just got it working, so 
I wanted to share the wealth.

First edit your project.gwt.xml file and add:

  add-linker name=xsiframe/

Second, edit your build.xml file and add something like:

  target name=sdm depends=javac description=starts the superdevmode
java fork=true failonerror=true 
classname=com.google.gwt.dev.codeserver.CodeServer
  classpath
pathelement location=src/
path refid=project.class.path/
pathelement location=${gwt.sdk}/gwt-codeserver.jar/
pathelement location=${gwt.sdk}/validation-api-1.0.0.GA.jar /
pathelement 
location=${gwt.sdk}/validation-api-1.0.0.GA-sources.jar /
  /classpath
  arg value=-src/
  arg value=${basedir}/src/
  arg value=com.myproject.Project/
/java
  /target

Third, assuming everything works right, when you ant the sdm target it will 
provide a URL. If you go to that URL it will give you a bookmarkable URL to 
start SuperDevMode and another one to stop it. Yes, you really need to at 
least add the Dev Mode On bookmark. After you do that then you can close 
the tab and probably never visit it again.

Fourth, and this was the hardest part for me to figure out from the 
information given, is you need to go to the same base URL to run your 
application that regular DevMode uses. In other words, omit the gwt.codesvr 
parameter.  In my case that is http://localhost:3000/app/index.htm;, but 
it will definitely be different for you unless you are running a 
development Mojolicious server. Your app should load, and then you click 
your Dev Mode On bookmark to recompile and reload. It's a little clunky 
having to click the button to recompile, but it's a whole lot better than 
running an old version of a browser.

James

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

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

2015-04-15 Thread 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: Issues with sourceLevel in latest 2.8.0-snapshot

2015-04-08 Thread James Horsley

Thanks. I had been trying various combinations of value and line
without success. Digging further it turned out that the snapshot jars were
working but the ones that weren't working were ones I'd built from source.
I eventually got the latest source working, but, unfortunately I didn't do
a good job isolating the changes so am not 100% which fixed it and have
spent enough time on it that I'm just going to roll forward :) Things I
changed included how I passed in sourceLevel using arg value and arg
line, also to switch from building GWT/master using buildonly to dist-dev.

If I go back to isolate the change that's making it work I'll report back
to this thread.

Thanks for your help.

Cheers,
James

On Tue, Apr 7, 2015 at 8:51 PM Jens jens.nehlme...@gmail.com wrote:


 Thanks. I'm using ant with some custom build targets and passing in
 sourceLevel using arg line=-sourceLevel 1.8 /.


 I think you must use arg value=-sourceLevel 1.8 /

 When using line it means you have two parameters -sourceLevel and
 1.8.

 -- J.


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


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

Issues with sourceLevel in latest 2.8.0-snapshot

2015-04-07 Thread James Horsley

I was using an older version of the 2.8.0-snapshot jars just fine, but
after pulling in the latest versions from sonatype I've started getting the
error Lambda expressions are allowed only at source level 1.8 or above.
Adding -sourceLevel 1.8 doesn't appear to fix this. I'm having the same
issue whether I'm running DevMode, CodeServer, or Compiler.

I only have JDK 8 installed on my laptop but confirmed that JDK 8 is being
used just in case there.

Anyone else seeing this?

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

Re: Issues with sourceLevel in latest 2.8.0-snapshot

2015-04-07 Thread James Horsley

Thanks. I'm using ant with some custom build targets and passing in
sourceLevel using arg line=-sourceLevel 1.8 /.

I've looked into it a bit already but I'm still thinking the issue is most
likely something wonky in my build.xml but wanted to check here in case
others were having the same problem

I'll do some additional verification and report back.

Cheers,
James

On Tue, Apr 7, 2015 at 8:01 PM Jens jens.nehlme...@gmail.com wrote:

 I have a custom build from 3rd April which only adds some Java 8 API
 emulation patches and it works without issues when using -sourceLevel 1.8 .

 Maybe you are not passing the parameter correctly? How do you launch
 DevMode/CodeServer/Compiler?

 -- J.

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


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

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

2015-04-02 Thread 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

2015-04-02 Thread 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 2.70 and emulated compiler stack mode

2015-02-28 Thread James Bearden

Whoops, to be clear, it was working up to and including GWT 2.6.1, but has 
stopped working in GWT 2.7.0.

James

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

GWT 2.70 and emulated compiler stack mode

2015-02-26 Thread James Bearden

Hello,

My client application talks via JSON to a non-Java based server, and up 
until GWT 2.6.1 I was using the emulated compiler stack mode feature to 
generate a stack trace when the client had an exception and then submitted 
it via a JSON request to be logged on the server. Thankfully it doesn't 
happen very often, but when it does it is incredibly useful to have that 
stack trace. Unfortunately that feature doesn't appear to be working with 
GWT 2.7.1. Can anybody offer any advice as to how I can get it working, or 
what a viable alternative might be?


In my gwt.xml I had the following:

  set-property name=compiler.stackMode value=emulated /
  set-configuration-property 
name=compiler.emulatedStack.recordLineNumbers value=true/
  set-configuration-property name=compiler.emulatedStack.recordFileNames 
value=true/


TIA,

James

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

GWT 2.7 Window Close Handle Bug?

2015-02-24 Thread James Bearden

Hello,

Since I upgraded to GWT 2.7 my window close handler has stopped working. 
Before I submitted a bug report I wanted to see if anybody else was having 
this issue and to verify that nothing has changed and I was still doing it 
right. My code is:


import com.google.gwt.core.client.EntryPoint;
import com.google.gwt.event.logical.shared.CloseEvent;
import com.google.gwt.event.logical.shared.CloseHandler;
import com.google.gwt.user.client.Window;

public class MyClass implements EntryPoint {
  public void onModuleLoad() {
 
  Session session = new Session();

 ...

   Window.addWindowClosingHandler(new Window.ClosingHandler() {
@Override public void onWindowClosing(Window.ClosingEvent event) {
  session.reset();
}
  });

Window.addCloseHandler(new CloseHandlerWindow() {
@Override public void onClose(CloseEventWindow event) {
  session.reset();
}
  });
}

I have tried and failed to do the above using JSNI, so bonus points if 
anybody can give me an example on how to do it that way as a backup. I 
REALLY need to get this working again because the users never use the 
logout button and close the browser instead. If I can't resolve the issue 
soon I'm going to have to downgrade to GWT 2.6.

James

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

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

2015-02-12 Thread 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 2.7 manifest support

2015-01-04 Thread James Nelson

Curious: What are the cache headers set on the .nocache.js file?  Expires, 
Cache-Control, etc?

You are expected to tell your web server to set non-caching headers for 
that file, so if your browser is caching it at all, I would say you need to 
modify your webserver cache policy.

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

Re: GWT 2.7 manifest support

2015-01-04 Thread James Nelson

Oh, wait, sorry, I see you're dealing w/ offline support.  

I will politely bow out and wish you luck in diagnosing the problem.

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

Re: GWT 2.7.0 is here

2014-12-04 Thread James Wendel

I wanted to say thank you to the entire GWT team for this release. 
 Incremental compiling for SDM has made it where we can use it at my 
company and it's seems great in my initial testing on it.  Being able to 
reload a page instantly when there are no changes (or only a few seconds to 
reload when there are changes) is awesome.  I really appreciate the work 
the GWT team has done.

Thanks,
-James

On Thursday, November 20, 2014 4:59:06 AM UTC-6, Daniel Kurka wrote:

 Today we are excited to announce the GWT 2.7.0 release.  Thanks to 
 everyone who contributed to this release, especially our non-Google open 
 source contributors.

 One major feature of this release is a new super fast compilation path in 
 Super Dev mode that replaces the old dev mode.
 For a run-down of all changes since GWT 2.6.1, read the release notes 
 http://www.gwtproject.org/release-notes.html#Release_Notes_2_7_0.

 The release is available for download here 
 http://www.gwtproject.org/download.html or on maven central.

 If you find any issues with this release, please file a bug in our issue 
 tracker.

 Daniel,
 on behalf of the GWT team at Google



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

Re: [gwt-contrib] Re: GWT 2.7 release plan

2014-10-09 Thread James Horsley

+1 for John's patch 9450 https://gwt-review.googlesource.com/#/c/9450/ (
sorry to devolve the thread into +1's )

On 9 October 2014 14:04, Thomas Broyer t.bro...@gmail.com wrote:

On Thursday, October 9, 2014 10:43:38 PM UTC+2, Roberto Lublinerman wrote:

I think we will better exclude the following three patches from the
release 425e0bb 2b2d81c 920ba90

I will either revert them or fix them with a better alternative. Java
RegExp implementation is really rough around the edges

If Daniel creates a branch for 2.7 maybe we could revert them on the
branch only? (given that the next GWT version will probably require Java 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/e8edbfcc-9ba3-46b4-854a-ee9c66471c51%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/e8edbfcc-9ba3-46b4-854a-ee9c66471c51%40googlegroups.com?utm_medium=emailutm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

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

Re: master/3.0.0 js interop ready to play with?

2014-10-01 Thread James Horsley

I'm also interested in Cristian's second question about using callback 
functions. Is this supposed to just work with the current master or is 
Cristian's EventListenerFactory workaround the best bet for now?

Cheers,
James

On Monday, August 11, 2014 7:17:32 PM UTC+1, Cristian Rinaldi wrote:

 I was playing with JsInterop and perform several examples 
DataTables Plugin of JQuery (import) 
Polymer (Path Observer, Object Observer), etc...

 Here my exmaples:
https://github.com/csrinaldi/samples-of-gwt/tree/master/gwt-playground

 But I 2 question about JsInterop:

 The first question with JsInterop is about the import methodology, when I 
 define a interface that maps with a JS core Element, by example: Object or 
 JSON, I not sure the best form for maps the static method of the Object, by 
 example Object.observe(...), or JSON.stringify().

 My understanding of JsInterop is that one defines an interface, which is 
 implemented by the compiler. 
 And the allocation for now is through a factory in JSNI, talking to 
 correlate Object for example, for Polymer ObjectObserver:

 public static native T extends JsObject ObjectObserverT 
 createObjectObserver(T obj)/*-{
  return new $wnd.ObjectObserver(obj);
 }-*/;


 But the asignations is a instance of Object, and the observe() method is a 
 static method.

 How to is the best form of map this case?

 The second question is about function callback passed to the Javascript 
 method

 button.addEventListener(click, function(event){
 console.log(event);
 });

 The way I found to the compiler to generate things correctly was:

 button.addEventListener(click, EventListenerFactory.createEventListener(
 new EventListenerJsObject() {
  @Override
  public void onEvent(JsObject event) {
//TODO
  }
 }));

 where:

 public class EventListenerFactory {
 public static native gwt_sample.EventListener createEventListener(
 EventListener listener)/*-{
  return function(evt){
  listener.onEvent(evt);
  }
  }-*/;
 }

 and:

 @JsType
 public interface EventListenerE extends JsObject {
 void onEvent(E event);
 }

 Thanks!!


 El lunes, 11 de agosto de 2014 09:03:00 UTC-3, salk31 escribió:

 Thanks. I have great hopes for this stuff ;)




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

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

2014-07-23 Thread 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.

Re: Can't Set App Engine SDK - Eclipse Plugin

2014-07-14 Thread James Nelson

ZOMG...  4 years later, and this is still the right fix!!


 then remember make sure that all maven jars are at bottom in order 
 and export tab. 



This was BEYOND frustrating (just lost over a day on this),
and all it took was putting maven on the bottom.

Sigh,
thank you so much. 

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

Re: GWT 2.7.0 Release Date

2014-05-28 Thread James Horsley

Is there any word as to whether Java 8 language/syntax support will be
included in 2.7?


On 28 May 2014 18:51, confile michael.gorsk...@googlemail.com wrote:

 Great thank you!


 Am Mittwoch, 28. Mai 2014 19:17:22 UTC+2 schrieb Jens:

 Build GWT from source if you want to play around with it. You need to:

 1.) mkdir gwt  cd gwt
 2.) git clone https://gwt.googlesource.com/gwt trunk
 3.) svn checkout http://google-web-toolkit.googlecode.com/svn/tools tools
 4.) cd trunk  ant dist-dev

 This builds GWT without samples and you can then find it in
 trunk/build/dist/gwt-0.0.0.zip. Unzip it to a location of your choice
 and then add the GWT SDK to Eclipse in the Eclipse settings.

 Release is targeted around Google IO 2014 which is at the end of June.
 But personally I would expect it to be released mid/end July.

 -- J.

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


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

Re: [gwt-contrib] Re: who discusses the next features and adopts feature requests?

2014-05-21 Thread James Horsley

Are there any best practices for open source projects to make integrating
back into main GWT easier in the future e.g. license, code style, etc.? If
so, it may be worth documenting them somewhere so that projects which are
set up with the hope to integrate into GWT if successful can follow those
guidelines.

On 21 May 2014 22:00, John A. Tamplin j...@jaet.org wrote:

A more general answer is that in any community project, whoever cares
about a feature the most is the one that designs it, convinces others it is
worth including, and implements it. Just because something has a lot of
votes doesn't automatically mean it will get built -- someone has to be
interested enough to make it happen. This was the case even when it was a
Google project, but is especially true now that it is fully owned by the
community.

--
John A. Tamplin

--
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/CAM5k6X-MhbBfYZG7nHHWhG%3DOPhBBU3Cc6FaBV5q374vjV9f0Vg%40mail.gmail.comhttps://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM5k6X-MhbBfYZG7nHHWhG%3DOPhBBU3Cc6FaBV5q374vjV9f0Vg%40mail.gmail.com?utm_medium=emailutm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

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

Re: March 12 minutes

2014-05-14 Thread James Horsley

(Replied to google-web-toolkit@googlegroups.com)

Thanks Colin. Out of interest, would it be likely for java 8 syntax to be
supported in a 2.7 release with the Google I/O target date? FWIW I'd
personally be delighted to have a 2.7 release for June with incremental
compilation as the big ticket item but I am of course looking forward to
using java 8 syntax ASAP :)


On 14 May 2014 17:36, Colin Alworth niloc...@gmail.com wrote:

 Sorry for the delay in sending this out, it was approved by the members
 who were present, but I forgot to mail it out here:


 GWT Steering Committee call March 12, 2014

 Present

 Artur Signell

 Christian Goudreau

 Christian Sadilek

 Daniel Kurka

 Bhaskar Janakiraman

 Thomas Broyer

 Colin Alworth (taking notes)

 New Maintainers

 Manuel Carrasco Moñino nominated for RequestFactory, AutoBeans, I18n, and
 helping with Jenkins builds, approved

 John Tamplin nominated for I18n, approved

 GWT 2.6.1 release

 Thomas, Daniel, Bhaskar brought up various issues that have been fixed and
 should be shipped: e.g. super dev mode fixes for windows, jetty/classloader
 issues for dev mode, ie11 history encoding issues. Others that still need
 to be merged will go into a release checklist, which should also help us
 avoid release issues as in 2.6.0.

 Super Dev Mode Improvements

 Next GWT version will be 2.7, released around I/O, adding modular
 compilation (to improve Super Dev Mode performance). Other features may
 also be included, or may wait for a later GWT 3 release. Moving up this
 target date and making it a smaller release will get better Super Dev Mode
 out to users right away, rather than delaying until other new features are
 ready to go. IE6 and 7 support, disabled in GWT 2.6, will be removed in
 this release.

 --
 You received this message because you are subscribed to the Google Groups
 GWT Steering group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to gwt-steering+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


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

[gwt-contrib] Changes in monthly GWT contributor hangout

2014-04-18 Thread 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: Chrome Canary 36 not showing sourcemaps

2014-04-16 Thread James Horsley

FWIW I have the same problem with Firefox hanging while using 100% CPU with
SDM


On 16 April 2014 05:41, Stefano Ciccarelli sciccare...@gmail.com wrote:

 Chrome 35 too. I ha dato switch back to chrome 34.
 On Firefox suorce maps are showing, but our project is so big that Firefox
 became unusable.


 Il mercoledì 16 aprile 2014, Thad Humphries thad.humphr...@gmail.com ha
 scritto:

 I'm trying to use the device emulator in Chrome Canary (v. 36.0.1941.0)
 to test various mobile devices. I'd like to debug my mobile code with SDM's
 sourcemaps, but they are not there, unlike on Chrome 34 where sourcemaps are
 at localhost:9876/sourcemaps/mymodule. Is there a flag I need to add to get
 sourcemaps, the way I must add --touch-events to test touch events?

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



 --
 Nel mondo esistono 10 categorie di persone, quelle che capiscono il
 binario e quelle che non lo capiscono.

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


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

Re: Development Mode will not be supported in Firefox 27+

2014-03-27 Thread James Wendel

My company got screwed by using GXT2 with gxt-uibinder library that broke with 
GWT 2.5 due to compiler changes. We've been stuck on GWT 2.4 for that reason as 
we had 100+ .ui.xml files to convert to pure java. We finally did the work, but 
it was definitely a painful lesson. 

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

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

2014-02-28 Thread 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

2014-02-27 Thread 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

2014-02-27 Thread 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

2014-02-27 Thread 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.

2014-02-11 Thread 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.

Compile time with a large project

We have a fairly large single GWT project that we feel has out-grown itself 
at this point.  It's setup in a way where we could split it out into a 
collection of smaller projects (though this is not a simple task).  What 
I'm looking to find out: does compile time of large GWT projects scale 
linearly with the size of the project?  Meaning, if we do split the project 
up into a bunch of smaller chunks, would we really save much during the 
compile process?

We're running GWT 2.4.0 with a collection of various libraries (GXT2.2.5, 
GXT3.0.6, GWTP, and other goodies).

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

Re: Compile time with a large project

On our build machine (which isn't the fastest thing in the world), it takes 
40 minutes to run javac + build 18 permutations.  Running the compileReport 
on it, tie Full code size is just under 5MB.

And yes, multiple apps, each having their own html host pages.  I was 
thinking that splitting them out would reduce the global optimization work 
done by the GWT compiler.


On Wednesday, February 5, 2014 12:37:09 PM UTC-6, Jens wrote:

 I assume with multiple projects you mean multiple apps each having its own 
 html host page? I don't think you will gain a lot because at the end you 
 have to compile the same amount of source files regardless if its one big 
 project or 10 smaller projects.

 If your app takes really that long to compile, I would first go for 
 distributed compilation so you can compile your permutations in parallel on 
 multiple hosts.

 https://code.google.com/p/google-web-toolkit/wiki/DistributedBuilds

 -- J.


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

Re: Compile time with a large project

To add.  the permutation-0.js generated by the compileReport is 640MB. 
 And using cloc http://cloc.sourceforge.net/, we are at 200k lines of 
code for java+xml (for uiBinder).

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

Re: Compile time with a large project