Re: Any issues running in detailed (or pretty) style in production?
> Have you tried working your way into the symbolMaps? No, because I just figured the obfuscated code wasn't worth trying to deobfuscate, but apparently symbolMaps is the key. Kirill provded the details so I plan to refer to that. Thanks for the time! -- 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: Any issues running in detailed (or pretty) style in production?
Great, thanks so much for this information, I'll study it and run some tests, but I'm sure it will create some great leads. Cheers! -- 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 2.8.1 release
This is a programmatic mapping from closure externs
https://github.com/google/closure-compiler/tree/master/contrib/externs so,
at the end if it changes it will change the same in every place, so fixing
it should not be very difficult. Anyways, this super awesome project is
going to expose a user-friendly and type safe API (manual work) over raw
elemental2 https://github.com/hal/elemento (code example here
https://github.com/ibaca/rxtodo-gwt/blob/master/src/main/java/todo/client/ApplicationElement.java#L53),
IMO pretty promising! RxGWT will be using elemento typed events to make it
also Rx typed events just over elemental2!
Code example here, this is always nice...
root = li().data(ITEM, item.id).css("completed", item.completed)
.add(div().css("view")
.add(toggle =
input(checkbox).css("toggle").checked(item.completed).asElement())
.add(msg = label().textContent(item.text).asElement())
.add(destroy = button().css("destroy").asElement()))
.add(summary = input(text).css("edit").asElement())
.asElement();
bind(toggle, change, ev -> {
root.classList.toggle("completed", toggle.checked);
repository.complete(item, toggle.checked);
application.update();
});
All these fields are typed so, root is a HTMLLiElement, toggle is a
HTMLInputElement or ev in the bind method is an InputEvent.
On Wed, Jun 7, 2017 at 10:14 PM Vassilis Virvilis wrote:
> thanks for the clarification.
>
> Maybe a sufficiently strong wording in the compatibility guarantees is
> enough.
>
> Something like this: We will try really hard to not rename all methods and
> move all packages around in the next week commits. However we may introduce
> incompatible changes as we are evolving the API. So no you can't use
> __this__ in __production__.
>
> Or maybe this a bad idea that will lead to a new KDE4 fiasco.
>
> Who knows?
>
> Vassilis
>
>
> On Wed, Jun 7, 2017 at 10:14 PM, Daniel Kurka
> wrote:
>
>> There is some reasoning behind us not broadly announcing elemental2 and
>> the jsinteorp generator:
>> They are both still beta software in the sense that we know there are
>> existing problems, but we already want feedback on them.
>> There are still no guarantees on APIs / compat but if you are brave and
>> want to be part of evolving them and turning them into a finished and
>> polished product, you can do that.
>>
>> We will announce them broadly once we consider them ready for general use
>> and have a compatibility guarantee in place.
>>
>> On Wed, Jun 7, 2017 at 11:48 AM Vassilis Virvilis
>> wrote:
>>
>>> Ah yes that explains it. It was j2cl that I remembered.
>>>
>>> Thanks for the clarification.
>>>
>>> Vassilis
>>>
>>> On Wed, Jun 7, 2017 at 9:40 PM, Colin Alworth
>>> wrote:
>>>
I think you may be misremembering - the jars were released to maven as
experimental last summer, then as beta in April, and only after that were
they on github.
J2CL is not expected to be dropped until it is "ready", but as with
elemental2, this isn't going to mean "bugfree" but more like "complete
enough to be reviewed and used".
On Wednesday, June 7, 2017 at 1:10:37 PM UTC-5, Vassilis Virvilis wrote:
>
> Looks like they are also here in source form
>
> https://github.com/google/elemental2
> https://github.com/google/jsinterop-generator
>
> I thought google didn't want to release them before they were "ready".
> So either they changed their mind, or they feel it is ready or I don't
> remember correctly :-)
>
> Vassilis
>
> On Wed, Jun 7, 2017 at 7:17 PM, Colin Alworth
> wrote:
>
>> The groupId has changed - using the mvnrepository site, try
>> https://mvnrepository.com/artifact/com.google.elemental2 to see all
>> of the jars now available.
>>
>>
>> On Wednesday, June 7, 2017 at 11:14:33 AM UTC-5, Bruno Salmon wrote:
>>>
>>>
>>>
Additionally, this supports the recent beta release of
jsinterop.base and elemental2, available from Maven Central.
>>> Where can we find that elemental2 beta release (I can see only the
>>> June 2016 version on that page
>>>
>>> )?
>>>
>>> Thanks for all your amazing work.
>>>
>> --
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 compiling GWT code with Java9
can you please share your library and i can try with that. On Thursday, June 8, 2017 at 1:18:56 AM UTC+5:30, James Nelson wrote: > > 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: Any issues running in detailed (or pretty) style in production?
On Wednesday, June 7, 2017 at 9:39:55 PM UTC+2, rjcarr wrote: > > I've been using GWT for years and years but recently my customers have a > problem that I can't reproduce, and they're remote so I can't just go check > it out in person. > > They're getting an unresponsive script error, and the browser will tell > them where it is, but the code is obfuscated. > Have you tried working your way into the symbolMaps? (that's how the StacktraceDeobfuscator works fwiw) -- 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
On Thursday, June 8, 2017 at 12:13:35 AM UTC+2, James Nelson wrote:
>
> 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.
>
Could that work if we complemented the "instanceof URLClassLoader" with
some check for "is the system classloader" and then use
System.getProperty("java.class.path") (or the equivalent
ManagementFactory.getRuntimeMXBean().getClassPath()) to get the system
classpath entries? (do we also need the bootclasspath?)
> That would be a broader discussion to have though.
>
IIRC, when CodeServer was added, with its -src argument, I suggested
passing classpaths as argument rather than using the system classpath.
At the time though, there was even more code that relied on the context
classloader than today (rather than using the ResourceOracle). This was
fixed later for the most part, but I believe there's still code that uses
the context classloader (including looking up annotations from
com.google.gwt.core.ext.typeinfo, and AFAIK also JDT loading bytecode that
ends up being looked up in the context classloader;
see 8b584f412d055ff39949d8b28a8e78d6b0bfe9b6 for example)
I suppose that could be fixed by using a child URLClassLoader from the
classpath argument (that could be necessary anyway for generators and
linkers)
> 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").
>
Apparently
not:
http://openjdk.java.net/projects/jigsaw/spec/issues/#AvoidConcealedPackageConflicts
IIUC, they say this can be worked around using classloaders, or
shading/shadowing (i.e. what you're doing)
> 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.
>
Does that also apply to subpackage? Because it looks like the only
conflicting packages are c.g.g.core.client and c.g.g.core.shared, so maybe
moving classes around could be enough?
> 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/9d17a4b1-449e-42d4-914d-d7f0549d9a85%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
