[gwt-contrib] Ant, ZipScanner, and GWT

[Colin Alworth]

We have two issues tracking the dependency that GWT has on Ant, 
https://github.com/gwtproject/gwt/issues/9690 and 
https://github.com/gwtproject/gwt/issues/9677. I've taken a little time and 
produced a minimal set of classes copied from ant which appear to provide a 
working ZipScanner. For the moment, this lives in its own git repository at 
https://github.com/vertispan/ant-zipscanner, and is not deployed anywhere.

I spent a while testing with latest ant, 1.10.8, but semantics have changed 
with the zip/directory scanner API such that leading "/" characters no 
longer match - rather than break behavior, I've instead switched to simply 
using the 1.6.5 code, and modified that for our purposes. This has the 
advantage of being substantially smaller than 1.10.8 - 18 types instead of 
46, and of those 18, 11 are required for ant's own implementation of the 
zip format, so the other 7 are needed to scan a zip and match contents. It 
is quite likely that this could be pruned further, but might come at a cost 
when updating to some later ant version (should we decide to do that).

This repository is arranged in three commits:

   - Create a script to copy the classes we need from the ant repo, and a 
   pom to ship these contents. The script is handy when iterating on a new 
   version, but probably won't be needed unless we do attempt to use a new 
   version
   - Copy all required classes from the tag "rel/1.6.5" in the upstream ant 
   repo 
   - Comment out anything which didn't compile due to missing dependencies 
   (we have no use for Project or refs, we only call ZipScanner methods 
   directly), or which modify the filesystem in some way (to limit risks when 
   depending on this codebase

The resulting output is shaded into a new package by the pom so that it 
will not interfere with ant when GWT is compiled (or if GWT is invoked from 
ant). 

When GWT is updated to both include this jar and also to reference these 
new shaded classes instead of the originals within ant, all tests in dev/ 
pass and all samples compile, though I haven't yet run all of the other 
tests.

So, my question is then how to proceed. First of all, is this approach 
acceptable in terms of maintenance, or would we prefer reimplementing the 
API from scratch in order to drop this dependency, or just updating to the 
latest ant version for this one API?

Assuming we like the approach, should we incorporate these copied/modified 
sources into GWT itself, or add an additional jar to gwtproject/tools, with 
instructions on how to update it, and from there include it into the 
project? A somewhat related option could be releasing this jar to maven 
central under something like org.gwtproject.ant:ant-zipscanner, and 
maintaining it in the github.com/gwtproject umbrella.

Finally, is there any objection to staying with 1.6.5, or should I see if 
we can use a later version, or update GWT's internals to use the new 
behavior around leading slashes, etc?

-- 
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/f3957563-9097-4e1d-9166-77858655aa64o%40googlegroups.com.

[gwt-contrib] Re: Discussion on changing gwt release groupid

[Thomas Broyer]

On Thursday, June 11, 2020 at 10:19:00 PM UTC+2, Colin Alworth wrote:
>
> @Thomas, it sounds like you think relocation should be well supported 
> then? My primary concern was the quote on the linked page, but if this is 
> well supported, then I think we're on the same page. From the linked page:
>
> *2020 rework in progress*, see discussion on dev mailing list 
>> ,
>>  
>> still need analysis of issues, definition of improvements, and of course 
>> implementation...
>>
>
> I'd also suggest going one step further and release a o.g:*:2.9.0 which 
> just has a relocation to point at c.g.g:*:2.9.0, and a BOM as you describe, 
> so that projects can begin migrating right away, even before the first 
> org.gwtproject-only release. We don't even necessarily need to wait until 
> 2.10 this way, but other 2.9.x releases could move to gwtproject, and just 
> have some canned maven files ready to have Google ship following each 
> release (for some limited window of time/versions)?
>

I'm worried that this two way relocation (o.g:*:2.9.0 relocated to 
c.g.g:*:2.9.0, then c.g.g:*:2.10.0 relocating "back" to o.g:*:2.10.0) might 
cause more problems than it solves.
Also, referencing a relocating POM will print a warning in the console (at 
least for Maven, AFAICT) so you don't actually want to use o.g *before* it 
actually exists.
 

> I do think we need to push more than just the BOM (you may not have been 
> suggesting this) for c.g.g releases, as there are plenty of projects out 
> there not using the BOM.
>
> Just to be sure I am clear, you are suggesting that o.g BOM includes o.g 
> dependencies as well as c.g.g, while the c.g.g BOM would only reference 
> c.g.g dependencies (which themselves would be relocated to o.g anyway).
>

I would have had the c.g.g BOM relocate as well, actually.

But first and foremost, I'm suggesting someone tests this (and/or variants) 
within his local Maven repository (or even better, some actual Maven 
repository accessed through HTTP; should be as easy as copy/pasting some 
files in another directory and running a simple web server there).
 

> If so, I think I see a conflict here:
>
>- SomeLibrary depends on c.g.g:gwt-user:2.9.0 or earlier, with or 
>without BOM
>- MyProject depends on o.g:gwt-user:2.10.0 or later, without a BOM, 
>and also on SomeLibrary
>
> Without a BOM, and without o.g:gwt-user:2.10.0 depending on some empty 
> c.g.g:gwt-user (and making that conflict apparent), the project would end 
> up with both old and new gwt-user on the classpath at the same time.
>

Absolutely. When migrating to o.g, you would have to add a 
dependencyManagement to *upgrade* c.g.g to the relocating version, either 
right in your POM or through the o.g BOM.
Indeed we could make o.g:gwt-user:2.10.0 have a dependency on an empty 
c.g.g:gwt-user:2.10.0 (but then, not relocating, or you'll have warnings 
AFAICT) but that wouldn't even work in all cases with Maven, depending on 
the order the dependencies to SomeLibrary and gwt-user are declared in 
MyProject. And if we can't have a c.g.g:gwt-user:2.10.0 that relocates to 
to o.g, then it's going to surprise people who automatically update to 
c.g.g:gwt-user:2.10.0 following some tooling advice and don't understand 
why the JAR is empty.

One thing we could possibly do to detect such cases would be to add some 
code the Main classes (Compiler, DevMode, CodeServer, JUnitShell) that 
would look for some duplicate resource on the classpath, or even look for 
all the com/google/gwt/dev/About.properties content and warn or fail if it 
finds differing gwt.version properties in there (unfortunately this is in 
gwt-dev which has fewer risks of being duplicated than gwt-user).

So, my plan would be:

   - test relocation, without overthinking it, and detecting limitations; 
   then we can refine the plan
   - add a check to detect duplicated gwt-user on the classpath when 
   running GWT tools


>
> @Jens
>
>> Our new published org.gwtproject:...:2.10 release would depend on 
>> com.google.gwt:...:99.0 which means all old GWT libraries should be 
>> upgraded via Maven/etc to 99.0 automatically as soon as you add 
>> org.gwtproject:...:2.10 to your dependencies.
>>
> I suspect this will not work except in gradle, which picks the highest 
> version in the case of a conflict. Maven picks the "nearest to your 
> project", so:
>
>- SomeLibrary depends on c.g.g:gwt-user:2.9.0 (or earlier, with or 
>without a BOM)
>- MyProject depends on SomeLibrary (so c.g.g:gwt-user is now 2 steps 
>away)
>- MyProject depends on o.g:gwt-user:2.10 without a BOM, which depends 
>on c.g.g:gwt-user:99.0 (which is also 2 steps away)
>
> It isn't clear to me which will win automatically. As above, we need the 
> user to use a BOM if they update to the org.gwtproject implementation to 
> work reliably, or for the 

[gwt-contrib] Re: HashCode H$ property should be not enumerable

[Vegegoku]

Most of our cliensts dropped support for ancient IEs, and we now only 
support IE11 and edge.

On Thursday, June 11, 2020 at 10:18:18 PM UTC+3, Colin Alworth wrote:
>
> Since the existing code is very similar to J2CL's code, it seems like a 
> reasonable change, provided it is indeed safe to drop support for IE8. At a 
> glance, I'm having trouble finding a recent statement describing whether or 
> not IE8 (and 9, 10) ought to be supported - since GWT is often used for 
> large long-lived applications, it can sometimes make sense to provide 
> support for browsers that might be officially unsupported, but still either 
> have a wide install base or where some other "extended support" is still 
> available.
>
> For example, from 
> https://docs.microsoft.com/en-us/lifecycle/faq/internet-explorer-microsoft-edge,
>  
> it appears that while IE8 and IE10 are no longer supported, IE9 is still 
> supported in some supported operating systems as the most recent browser. 
> However, there is still the note "To continue receiving IE 8 updates after 
> January 12, 2016, please contact your Microsoft Account Team.", suggesting 
> it is still possible to get IE8 support.
>
> This is contradicted somewhat by 
> https://docs.microsoft.com/en-us/deployedge/microsoft-edge-supported-operating-systems,
>  
> which says that the two OS versions (Win Server 2008 IA64 and SP2) which 
> support IE9 are no longer supported, suggesting that aside from some 
> specialized support contract, IE8, IE9, and IE10 should be considered dead.
>
> On Thursday, June 11, 2020 at 1:08:48 PM UTC-5, stockiNail wrote:
>>
>> Hi all,
>>
>> I was facing an annoying issue about the hashcode *$N* property, stored 
>> inside the java script object.
>>
>> I'm using GWT 2.8.2 but no JSNI implementation, only JSInterop objects.
>>
>> I'm writing an object (JsType native) in order to configure a chart for 
>> Chart.js. 
>>
>> @JsType(isNative = true, name = "Object", namespace = JsPackage.GLOBAL)
>>
>> Every property is the ID of another object.
>>
>> But unfortunately I got an error from Chart.js because it is scanning all 
>> properties keys to get the objects but it does not recognize the value of 
>> *$H*, being a number and not a object.
>>
>> scales: { 
>>   $H: 135, 
>>   x: {id: "x", _charbaId: 2, type: "category", axis: "x", display: true, …}, 
>>   y: {id: "y", _charbaId: 3, type: "linear", axis: "y", display: true, …} 
>> }
>>
>> It's clear that a hashcode must be stored therefore there is no way to 
>> remove it.
>>
>> Searching for a solution, I have found the *javaemul.internal.ObjectHashing* 
>> class which is managing the H$ property, I guess:
>>
>>  public static native int getHashCode(Object o) /*-{
>> return o.$H || (o.$H = @ObjectHashing::getNextHashId()());
>>  }-*/;
>>
>> I think the definition of H$ property must be changed, in order to define 
>> the property "not enumerable" (currently is writable, enumerable and 
>> configurable) using *Object.defineProperty()*, as it is reported 
>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty.
>>
>> The *Object.defineProperty()* method is not supported into Internet Explorer 
>> 8 therefore if going to manage the hascode in this way, GWT will drop the 
>> support on IE8 as well.
>>
>> In the J2CL implementation, it looks like already aligned with my proposal:
>>
>>
>> /** 
>>   * Utility functions for setting and retrieving system level hashcodes. 
>>   */
>> class Hashing { 
>>/** 
>>  * Gets a hash code on the passed-in object. 
>>  * 
>>  * @param {*} obj 
>>  * @return {number} 
>>  * @public 
>>  */ 
>>  static $getHashCode(obj) { 
>> let o = /** @type {Object} */ (obj); 
>> return o.$systemHashCode || (Object.defineProperties(o, { 
>> $systemHashCode: {value: Hashing.$getNextHashId(), enumerable: false} }), 
>> o.$systemHashCode); 
>>  }
>>
>> Anyway, as workaround, I'm rewriting the hashcode property for this object, 
>> maintaining the same value but setting the property as not enumerale and it 
>> seems working.
>>
>>
>>
>>

-- 
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/c735b2fa-ec61-4140-925c-91b3c34b9679o%40googlegroups.com.

[gwt-contrib] Re: HashCode H$ property should be not enumerable

[stockiNail]

Some frameworks can support IE8 polyfilling the application. In my opinion 
the IE 8 support could be dropped.

Don't forget that the proposal (the* Object.defineProperty()*usage) is 
available from IE9, therefore we are not saying that we raise the GWT 
requirement to IE11 or Edge, but only 1 version up.

Il giorno venerdì 12 giugno 2020 16:32:24 UTC+2, Vegegoku ha scritto:
>
> Most of our cliensts dropped support for ancient IEs, and we now only 
> support IE11 and edge.
>
> On Thursday, June 11, 2020 at 10:18:18 PM UTC+3, Colin Alworth wrote:
>>
>> Since the existing code is very similar to J2CL's code, it seems like a 
>> reasonable change, provided it is indeed safe to drop support for IE8. At a 
>> glance, I'm having trouble finding a recent statement describing whether or 
>> not IE8 (and 9, 10) ought to be supported - since GWT is often used for 
>> large long-lived applications, it can sometimes make sense to provide 
>> support for browsers that might be officially unsupported, but still either 
>> have a wide install base or where some other "extended support" is still 
>> available.
>>
>> For example, from 
>> https://docs.microsoft.com/en-us/lifecycle/faq/internet-explorer-microsoft-edge,
>>  
>> it appears that while IE8 and IE10 are no longer supported, IE9 is still 
>> supported in some supported operating systems as the most recent browser. 
>> However, there is still the note "To continue receiving IE 8 updates after 
>> January 12, 2016, please contact your Microsoft Account Team.", suggesting 
>> it is still possible to get IE8 support.
>>
>> This is contradicted somewhat by 
>> https://docs.microsoft.com/en-us/deployedge/microsoft-edge-supported-operating-systems,
>>  
>> which says that the two OS versions (Win Server 2008 IA64 and SP2) which 
>> support IE9 are no longer supported, suggesting that aside from some 
>> specialized support contract, IE8, IE9, and IE10 should be considered dead.
>>
>> On Thursday, June 11, 2020 at 1:08:48 PM UTC-5, stockiNail wrote:
>>>
>>> Hi all,
>>>
>>> I was facing an annoying issue about the hashcode *$N* property, stored 
>>> inside the java script object.
>>>
>>> I'm using GWT 2.8.2 but no JSNI implementation, only JSInterop objects.
>>>
>>> I'm writing an object (JsType native) in order to configure a chart for 
>>> Chart.js. 
>>>
>>> @JsType(isNative = true, name = "Object", namespace = JsPackage.GLOBAL)
>>>
>>> Every property is the ID of another object.
>>>
>>> But unfortunately I got an error from Chart.js because it is scanning 
>>> all properties keys to get the objects but it does not recognize the value 
>>> of *$H*, being a number and not a object.
>>>
>>> scales: { 
>>>   $H: 135, 
>>>   x: {id: "x", _charbaId: 2, type: "category", axis: "x", display: true, 
>>> …}, 
>>>   y: {id: "y", _charbaId: 3, type: "linear", axis: "y", display: true, …} 
>>> }
>>>
>>> It's clear that a hashcode must be stored therefore there is no way to 
>>> remove it.
>>>
>>> Searching for a solution, I have found the 
>>> *javaemul.internal.ObjectHashing* class which is managing the H$ property, 
>>> I guess:
>>>
>>>  public static native int getHashCode(Object o) /*-{
>>> return o.$H || (o.$H = @ObjectHashing::getNextHashId()());
>>>  }-*/;
>>>
>>> I think the definition of H$ property must be changed, in order to define 
>>> the property "not enumerable" (currently is writable, enumerable and 
>>> configurable) using *Object.defineProperty()*, as it is reported 
>>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty.
>>>
>>> The *Object.defineProperty()* method is not supported into Internet 
>>> Explorer 8 therefore if going to manage the hascode in this way, GWT will 
>>> drop the support on IE8 as well.
>>>
>>> In the J2CL implementation, it looks like already aligned with my proposal:
>>>
>>>
>>> /** 
>>>   * Utility functions for setting and retrieving system level hashcodes. 
>>>   */
>>> class Hashing { 
>>>/** 
>>>  * Gets a hash code on the passed-in object. 
>>>  * 
>>>  * @param {*} obj 
>>>  * @return {number} 
>>>  * @public 
>>>  */ 
>>>  static $getHashCode(obj) { 
>>> let o = /** @type {Object} */ (obj); 
>>> return o.$systemHashCode || (Object.defineProperties(o, { 
>>> $systemHashCode: {value: Hashing.$getNextHashId(), enumerable: false} }), 
>>> o.$systemHashCode); 
>>>  }
>>>
>>> Anyway, as workaround, I'm rewriting the hashcode property for this object, 
>>> maintaining the same value but setting the property as not enumerale and it 
>>> seems working.
>>>
>>>
>>>
>>>

-- 
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/52606c59-b

Re: [gwt-contrib] Re: HashCode H$ property should be not enumerable

[Colin Alworth]

Agreed that this fix only requires dropping IE8, but I'm suggesting that we go 
a bit further and either a) also drop other dead browsers, or b) have a 
plan/timeline for when we can drop those browsers - at least officially. We 
might still leave in support for them (as we did for IE6 for some years), but 
require that projects go out of their way to enable that support.

-- 
 Colin Alworth
co...@colinalworth.com



On Fri, Jun 12, 2020, at 9:49 AM, stockiNail wrote:
> Some frameworks can support IE8 polyfilling the application. In my opinion 
> the IE 8 support could be dropped.
> 
> Don't forget that the proposal (the`* Object.defineProperty()*`usage) is 
> available from IE9, therefore we are not saying that we raise the GWT 
> requirement to IE11 or Edge, but only 1 version up.
> 
> Il giorno venerdì 12 giugno 2020 16:32:24 UTC+2, Vegegoku ha scritto:
>> Most of our cliensts dropped support for ancient IEs, and we now only 
>> support IE11 and edge.
>> 
>> On Thursday, June 11, 2020 at 10:18:18 PM UTC+3, Colin Alworth wrote:
>>> Since the existing code is very similar to J2CL's code, it seems like a 
>>> reasonable change, provided it is indeed safe to drop support for IE8. At a 
>>> glance, I'm having trouble finding a recent statement describing whether or 
>>> not IE8 (and 9, 10) ought to be supported - since GWT is often used for 
>>> large long-lived applications, it can sometimes make sense to provide 
>>> support for browsers that might be officially unsupported, but still either 
>>> have a wide install base or where some other "extended support" is still 
>>> available.
>>> 
>>> For example, from 
>>> https://docs.microsoft.com/en-us/lifecycle/faq/internet-explorer-microsoft-edge,
>>>  it appears that while IE8 and IE10 are no longer supported, IE9 is still 
>>> supported in some supported operating systems as the most recent browser. 
>>> However, there is still the note "To continue receiving IE 8 updates after 
>>> January 12, 2016, please contact your Microsoft Account Team.", suggesting 
>>> it is still possible to get IE8 support.
>>> 
>>> This is contradicted somewhat by 
>>> https://docs.microsoft.com/en-us/deployedge/microsoft-edge-supported-operating-systems,
>>>  which says that the two OS versions (Win Server 2008 IA64 and SP2) which 
>>> support IE9 are no longer supported, suggesting that aside from some 
>>> specialized support contract, IE8, IE9, and IE10 should be considered dead.
>>> 
>>> On Thursday, June 11, 2020 at 1:08:48 PM UTC-5, stockiNail wrote:
 Hi all,
 
 I was facing an annoying issue about the hashcode *$N* property, stored 
 inside the java script object.
 
 I'm using GWT 2.8.2 but no JSNI implementation, only JSInterop objects.
 
 I'm writing an object (JsType native) in order to configure a chart for 
 Chart.js. 
 
 @JsType(isNative = true, name = "Object", namespace = JsPackage.GLOBAL)
 
 Every property is the ID of another object.
 
 But unfortunately I got an error from Chart.js because it is scanning all 
 properties keys to get the objects but it does not recognize the value of 
 *$H*, being a number and not a object.
 scales: { 
   $H: 135, 
   x: {id: "x", _charbaId: 2, type: "category", axis: "x", display: true, 
 …}, 
   y: {id: "y", _charbaId: 3, type: "linear", axis: "y", display: true, …} 
 }
 
 It's clear that a hashcode must be stored therefore there is no way to 
 remove it.
 
 Searching for a solution, I have found the 
 *javaemul.internal.ObjectHashing* class which is managing the H$ property, 
 I guess:
 
  public static native int getHashCode(Object o) /*-{
     return o.$H || (o.$H = @ObjectHashing::getNextHashId()());
  }-*/;
 
 I think the definition of H$ property must be changed, in order to define 
 the property "not enumerable" (currently is writable, enumerable and 
 configurable) using *Object.defineProperty()*, as it is reported 
 https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty.
 
 The *Object.defineProperty()* method is not supported into Internet 
 Explorer 8 therefore if going to manage the hascode in this way, GWT will 
 drop the support on IE8 as well.
 
 In the J2CL implementation, it looks like already aligned with my proposal:
 
 
 /** 
   * Utility functions for setting and retrieving system level hashcodes. 
   */
 class Hashing { 
    /** 
      * Gets a hash code on the passed-in object. 
      * 
      * @param {*} obj 
      * @return {number} 
      * @public 
      */ 
      static $getHashCode(obj) { 
         let o = /** @type {Object} */ (obj); 
         return o.$systemHashCode || (Object.defineProperties(o, { 
 $systemHashCode: {value: Hashing.$getNextHashId(), enumerable: false} }), 
 o.$systemHashCode); 
>>>

Re: [gwt-contrib] Re: HashCode H$ property should be not enumerable

[stockiNail]

I fully agree. Based on my experience, I'd suggest, for IE, to set the 
minimum supported version at IE11.  

Il giorno venerdì 12 giugno 2020 17:48:48 UTC+2, Colin Alworth ha scritto:
>
> Agreed that this fix only requires dropping IE8, but I'm suggesting that 
> we go a bit further and either a) also drop other dead browsers, or b) have 
> a plan/timeline for when we can drop those browsers - at least officially. 
> We might still leave in support for them (as we did for IE6 for some 
> years), but require that projects go out of their way to enable that 
> support.
>
> -- 
>   Colin Alworth
>   co...@colinalworth.com 
>
>
>
> On Fri, Jun 12, 2020, at 9:49 AM, stockiNail wrote:
>
> Some frameworks can support IE8 polyfilling the application. In my opinion 
> the IE 8 support could be dropped.
>
> Don't forget that the proposal (the* Object.defineProperty()*usage) is 
> available from IE9, therefore we are not saying that we raise the GWT 
> requirement to IE11 or Edge, but only 1 version up.
>
> Il giorno venerdì 12 giugno 2020 16:32:24 UTC+2, Vegegoku ha scritto:
>
> Most of our cliensts dropped support for ancient IEs, and we now only 
> support IE11 and edge.
>
> On Thursday, June 11, 2020 at 10:18:18 PM UTC+3, Colin Alworth wrote:
>
> Since the existing code is very similar to J2CL's code, it seems like a 
> reasonable change, provided it is indeed safe to drop support for IE8. At a 
> glance, I'm having trouble finding a recent statement describing whether or 
> not IE8 (and 9, 10) ought to be supported - since GWT is often used for 
> large long-lived applications, it can sometimes make sense to provide 
> support for browsers that might be officially unsupported, but still either 
> have a wide install base or where some other "extended support" is still 
> available.
>
> For example, from 
> https://docs.microsoft.com/en-us/lifecycle/faq/internet-explorer-microsoft-edge,
>  
> it appears that while IE8 and IE10 are no longer supported, IE9 is still 
> supported in some supported operating systems as the most recent browser. 
> However, there is still the note "To continue receiving IE 8 updates after 
> January 12, 2016, please contact your Microsoft Account Team.", suggesting 
> it is still possible to get IE8 support.
>
> This is contradicted somewhat by 
> https://docs.microsoft.com/en-us/deployedge/microsoft-edge-supported-operating-systems,
>  
> which says that the two OS versions (Win Server 2008 IA64 and SP2) which 
> support IE9 are no longer supported, suggesting that aside from some 
> specialized support contract, IE8, IE9, and IE10 should be considered dead.
>
> On Thursday, June 11, 2020 at 1:08:48 PM UTC-5, stockiNail wrote:
>
> Hi all,
>
> I was facing an annoying issue about the hashcode *$N* property, stored 
> inside the java script object.
>
> I'm using GWT 2.8.2 but no JSNI implementation, only JSInterop objects.
>
> I'm writing an object (JsType native) in order to configure a chart for 
> Chart.js. 
>
> @JsType(isNative = true, name = "Object", namespace = JsPackage.GLOBAL)
>
> Every property is the ID of another object.
>
> But unfortunately I got an error from Chart.js because it is scanning all 
> properties keys to get the objects but it does not recognize the value of 
> *$H*, being a number and not a object.
>
> scales: { 
>   $H: 135, 
>   x: {id: "x", _charbaId: 2, type: "category", axis: "x", display: true, …}, 
>   y: {id: "y", _charbaId: 3, type: "linear", axis: "y", display: true, …} 
> }
>
> It's clear that a hashcode must be stored therefore there is no way to remove 
> it.
>
> Searching for a solution, I have found the *javaemul.internal.ObjectHashing* 
> class which is managing the H$ property, I guess:
>
>  public static native int getHashCode(Object o) /*-{
> return o.$H || (o.$H = @ObjectHashing::getNextHashId()());
>  }-*/;
>
> I think the definition of H$ property must be changed, in order to define the 
> property "not enumerable" (currently is writable, enumerable and 
> configurable) using *Object.defineProperty()*, as it is reported 
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty.
>
> The *Object.defineProperty()* method is not supported into Internet Explorer 
> 8 therefore if going to manage the hascode in this way, GWT will drop the 
> support on IE8 as well.
>
> In the J2CL implementation, it looks like already aligned with my proposal:
>
>
> /** 
>   * Utility functions for setting and retrieving system level hashcodes. 
>   */
> class Hashing { 
>/** 
>  * Gets a hash code on the passed-in object. 
>  * 
>  * @param {*} obj 
>  * @return {number} 
>  * @public 
>  */ 
>  static $getHashCode(obj) { 
> let o = /** @type {Object} */ (obj); 
> return o.$systemHashCode || (Object.defineProperties(o, { 
> $systemHashCode: {value: Hashing.$getNextHashId(), enumerable: false} }), 
> o.$systemHashCode); 
>  }
>
> Anyway, as workaround, I'm 

Re: [gwt-contrib] Re: Discussion on changing gwt release groupid

[Colin Alworth]

Yep, sounds like the test stuff I had in mind - for a quick demo I'll set up a 
repo, put some "libraries" and "gwt" jars/boms into it, and then make a bunch 
of sample projects. The "gwt jars" will have some service loader wiring, and 
the sample projects will check to see which jars they end up with, so that we 
can see which configurations cause which surprises.

Roughly, I'll deploy

 * LibraryWithNewGwt
 * LibraryWithOldGwt
 * LibraryWithBomAndNewGwt
 * LibraryWithBomAndOldGwt
 * LibraryWithTransitiveOldGwt (two flavors of this, one for each of the old 
gwt above)
 * LibraryWithTransitiveNewGwt (again, two flavors)

then try to build projects with old or new gwt, plus 1-2 of the libraries 
above. If a project ever detects more than one gwt version, we'll fail that, 
and go from there.


> 
> I'm worried that this two way relocation (o.g:*:2.9.0 relocated to 
> c.g.g:*:2.9.0, then c.g.g:*:2.10.0 relocating "back" to o.g:*:2.10.0) might 
> cause more problems than it solves.
> Also, referencing a relocating POM will print a warning in the console (at 
> least for Maven, AFAICT) so you don't actually want to use o.g *before* it 
> actually exists.
Good point - perhaps we just push a o.g:gwt:2.9.0 bom then, and encourage 
switching to just that? Same idea as before - projects can future proof 
themselves and move to this BOM, then only have to change its version in the 
BOM declaration to be correctly updated. This does miss out on some of the 
benefits though. Will hold off exploring until the above experiment has some 
results to share.


> 
> One thing we could possibly do to detect such cases would be to add some code 
> the Main classes (Compiler, DevMode, CodeServer, JUnitShell) that would look 
> for some duplicate resource on the classpath, or even look for all the 
> com/google/gwt/dev/About.properties content and warn or fail if it finds 
> differing gwt.version properties in there (unfortunately this is in gwt-dev 
> which has fewer risks of being duplicated than gwt-user).
> 
> So, my plan would be:
>  * test relocation, without overthinking it, and detecting limitations; then 
> we can refine the plan
>  * add a check to detect duplicated gwt-user on the classpath when running 
> GWT tools
Yeah, I was thinking about this - It would be nice if we could go back in time 
and add some nice version sentinel that can be scanned for across all jars, but 
About.properties is as good as anything. Confirming gwt-dev is current doesn't 
tell you much (plenty of libraries only use gwt-user), but hopefully it will 
catch the important cases. Probably should augment the above samples to have 
another axis: gwt-user, or gwt-user+gwt-dev on each library.

-- 
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/d9878fe9-4880-4722-984e-dbf1d8aca600%40www.fastmail.com.

[gwt-contrib] Re: Ant, ZipScanner, and GWT

[Thomas Broyer]

To minimize the work, and because 1.6.5 works well for us without known 
vulnerability, I would either copy/paste the code into gwtproject/gwt or 
provide it in a JAR in gwtproject/tools and call it a day. We already have 
a copy of Rhino (with changes for JSNI), and a slimmed down version of 
jsilver containing only the streamhtmlparser.
No need to try to update and risk a breaking change, and no need to make it 
"more maintainable" as I'm sure it'll be a one-shot anyway (and that 
decision could be revisited in the future should we need to make changes to 
those Ant classes).

On Friday, June 12, 2020 at 3:31:04 PM UTC+2, Colin Alworth wrote:
>
> We have two issues tracking the dependency that GWT has on Ant, 
> https://github.com/gwtproject/gwt/issues/9690 and 
> https://github.com/gwtproject/gwt/issues/9677. I've taken a little time 
> and produced a minimal set of classes copied from ant which appear to 
> provide a working ZipScanner. For the moment, this lives in its own git 
> repository at https://github.com/vertispan/ant-zipscanner, and is not 
> deployed anywhere.
>
> I spent a while testing with latest ant, 1.10.8, but semantics have 
> changed with the zip/directory scanner API such that leading "/" characters 
> no longer match - rather than break behavior, I've instead switched to 
> simply using the 1.6.5 code, and modified that for our purposes. This has 
> the advantage of being substantially smaller than 1.10.8 - 18 types instead 
> of 46, and of those 18, 11 are required for ant's own implementation of the 
> zip format, so the other 7 are needed to scan a zip and match contents. It 
> is quite likely that this could be pruned further, but might come at a cost 
> when updating to some later ant version (should we decide to do that).
>
> This repository is arranged in three commits:
>
>- Create a script to copy the classes we need from the ant repo, and a 
>pom to ship these contents. The script is handy when iterating on a new 
>version, but probably won't be needed unless we do attempt to use a new 
>version
>- Copy all required classes from the tag "rel/1.6.5" in the upstream 
>ant repo 
>- Comment out anything which didn't compile due to missing 
>dependencies (we have no use for Project or refs, we only call ZipScanner 
>methods directly), or which modify the filesystem in some way (to limit 
>risks when depending on this codebase
>
> The resulting output is shaded into a new package by the pom so that it 
> will not interfere with ant when GWT is compiled (or if GWT is invoked from 
> ant). 
>
> When GWT is updated to both include this jar and also to reference these 
> new shaded classes instead of the originals within ant, all tests in dev/ 
> pass and all samples compile, though I haven't yet run all of the other 
> tests.
>
> So, my question is then how to proceed. First of all, is this approach 
> acceptable in terms of maintenance, or would we prefer reimplementing the 
> API from scratch in order to drop this dependency, or just updating to the 
> latest ant version for this one API?
>
> Assuming we like the approach, should we incorporate these copied/modified 
> sources into GWT itself, or add an additional jar to gwtproject/tools, with 
> instructions on how to update it, and from there include it into the 
> project? A somewhat related option could be releasing this jar to maven 
> central under something like org.gwtproject.ant:ant-zipscanner, and 
> maintaining it in the github.com/gwtproject umbrella.
>
> Finally, is there any objection to staying with 1.6.5, or should I see if 
> we can use a later version, or update GWT's internals to use the new 
> behavior around leading slashes, etc?
>

-- 
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/7e0c1856-2835-4254-a8ed-b73a03de1ea7o%40googlegroups.com.

Re: [gwt-contrib] Re: HashCode H$ property should be not enumerable

[Thomas Broyer]

Fwiw: IE11 will be EOL for mainstream in October this year: 
https://www.swyx.io/writing/ie11-eol/ (of course, for enterprise customers 
this will be longer; my opinion is that those companies that have enough 
money to pay for special Microsoft support contract could also pay a 
company to fork and maintain GWT for those usecases; or they can just stay 
on an old version of GWT like they're staying on an old version of IE; 
those companies are not my customers though so my opinion probably doesn't 
weight much)

Also, jQuery dropped support for IE8 while back and is now IE9+ 
https://jquery.com/browser-support/. That supports the option for GWT to do 
the same, at a minimum.

Finally, several "modularized gwt-user" modules already dropped support for 
IE8 and IE9 AFAICT, possibly even IE10.

On Friday, June 12, 2020 at 5:53:56 PM UTC+2, stockiNail wrote:
>
> I fully agree. Based on my experience, I'd suggest, for IE, to set the 
> minimum supported version at IE11.  
>
> Il giorno venerdì 12 giugno 2020 17:48:48 UTC+2, Colin Alworth ha scritto:
>>
>> Agreed that this fix only requires dropping IE8, but I'm suggesting that 
>> we go a bit further and either a) also drop other dead browsers, or b) have 
>> a plan/timeline for when we can drop those browsers - at least officially. 
>> We might still leave in support for them (as we did for IE6 for some 
>> years), but require that projects go out of their way to enable that 
>> support.
>>
>> -- 
>>   Colin Alworth
>>   co...@colinalworth.com
>>
>>
>>
>> On Fri, Jun 12, 2020, at 9:49 AM, stockiNail wrote:
>>
>> Some frameworks can support IE8 polyfilling the application. In my 
>> opinion the IE 8 support could be dropped.
>>
>> Don't forget that the proposal (the* Object.defineProperty()*usage) is 
>> available from IE9, therefore we are not saying that we raise the GWT 
>> requirement to IE11 or Edge, but only 1 version up.
>>
>> Il giorno venerdì 12 giugno 2020 16:32:24 UTC+2, Vegegoku ha scritto:
>>
>> Most of our cliensts dropped support for ancient IEs, and we now only 
>> support IE11 and edge.
>>
>> On Thursday, June 11, 2020 at 10:18:18 PM UTC+3, Colin Alworth wrote:
>>
>> Since the existing code is very similar to J2CL's code, it seems like a 
>> reasonable change, provided it is indeed safe to drop support for IE8. At a 
>> glance, I'm having trouble finding a recent statement describing whether or 
>> not IE8 (and 9, 10) ought to be supported - since GWT is often used for 
>> large long-lived applications, it can sometimes make sense to provide 
>> support for browsers that might be officially unsupported, but still either 
>> have a wide install base or where some other "extended support" is still 
>> available.
>>
>> For example, from 
>> https://docs.microsoft.com/en-us/lifecycle/faq/internet-explorer-microsoft-edge,
>>  
>> it appears that while IE8 and IE10 are no longer supported, IE9 is still 
>> supported in some supported operating systems as the most recent browser. 
>> However, there is still the note "To continue receiving IE 8 updates after 
>> January 12, 2016, please contact your Microsoft Account Team.", suggesting 
>> it is still possible to get IE8 support.
>>
>> This is contradicted somewhat by 
>> https://docs.microsoft.com/en-us/deployedge/microsoft-edge-supported-operating-systems,
>>  
>> which says that the two OS versions (Win Server 2008 IA64 and SP2) which 
>> support IE9 are no longer supported, suggesting that aside from some 
>> specialized support contract, IE8, IE9, and IE10 should be considered dead.
>>
>> On Thursday, June 11, 2020 at 1:08:48 PM UTC-5, stockiNail wrote:
>>
>> Hi all,
>>
>> I was facing an annoying issue about the hashcode *$N* property, stored 
>> inside the java script object.
>>
>> I'm using GWT 2.8.2 but no JSNI implementation, only JSInterop objects.
>>
>> I'm writing an object (JsType native) in order to configure a chart for 
>> Chart.js. 
>>
>> @JsType(isNative = true, name = "Object", namespace = JsPackage.GLOBAL)
>>
>> Every property is the ID of another object.
>>
>> But unfortunately I got an error from Chart.js because it is scanning all 
>> properties keys to get the objects but it does not recognize the value of 
>> *$H*, being a number and not a object.
>>
>> scales: { 
>>   $H: 135, 
>>   x: {id: "x", _charbaId: 2, type: "category", axis: "x", display: true, …}, 
>>   y: {id: "y", _charbaId: 3, type: "linear", axis: "y", display: true, …} 
>> }
>>
>> It's clear that a hashcode must be stored therefore there is no way to 
>> remove it.
>>
>> Searching for a solution, I have found the *javaemul.internal.ObjectHashing* 
>> class which is managing the H$ property, I guess:
>>
>>  public static native int getHashCode(Object o) /*-{
>> return o.$H || (o.$H = @ObjectHashing::getNextHashId()());
>>  }-*/;
>>
>> I think the definition of H$ property must be changed, in order to define 
>> the property "not enumerable" (currently is writable, enumerable and 
>> configurable) using *Obje

[gwt-contrib] Re: HashCode H$ property should be not enumerable

[Rocco De Angelis]

Regarding the ie support: We have really a lot of large customers 
(https://resources.softwareag.com/customers) in all business sectors and 
also a lot of customers in the financial sector which are normally very 
slow updating software. Last year we removed the support for ie8, ie9 and 
ie10 for all our up coming web based product releases. But ie11 is still 
present in some companies ...
The customers mentioned on the page are really a very small set of all 
customer that we have. So I personally think that is absolute okay removing 
all ie<11 browsers from the GWT support list.


Am Donnerstag, 11. Juni 2020 20:08:48 UTC+2 schrieb stockiNail:
>
> Hi all,
>
> I was facing an annoying issue about the hashcode *$N* property, stored 
> inside the java script object.
>
> I'm using GWT 2.8.2 but no JSNI implementation, only JSInterop objects.
>
> I'm writing an object (JsType native) in order to configure a chart for 
> Chart.js. 
>
> @JsType(isNative = true, name = "Object", namespace = JsPackage.GLOBAL)
>
> Every property is the ID of another object.
>
> But unfortunately I got an error from Chart.js because it is scanning all 
> properties keys to get the objects but it does not recognize the value of 
> *$H*, being a number and not a object.
>
> scales: { 
>   $H: 135, 
>   x: {id: "x", _charbaId: 2, type: "category", axis: "x", display: true, …}, 
>   y: {id: "y", _charbaId: 3, type: "linear", axis: "y", display: true, …} 
> }
>
> It's clear that a hashcode must be stored therefore there is no way to remove 
> it.
>
> Searching for a solution, I have found the *javaemul.internal.ObjectHashing* 
> class which is managing the H$ property, I guess:
>
>  public static native int getHashCode(Object o) /*-{
> return o.$H || (o.$H = @ObjectHashing::getNextHashId()());
>  }-*/;
>
> I think the definition of H$ property must be changed, in order to define the 
> property "not enumerable" (currently is writable, enumerable and 
> configurable) using *Object.defineProperty()*, as it is reported 
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty.
>
> The *Object.defineProperty()* method is not supported into Internet Explorer 
> 8 therefore if going to manage the hascode in this way, GWT will drop the 
> support on IE8 as well.
>
> In the J2CL implementation, it looks like already aligned with my proposal:
>
>
> /** 
>   * Utility functions for setting and retrieving system level hashcodes. 
>   */
> class Hashing { 
>/** 
>  * Gets a hash code on the passed-in object. 
>  * 
>  * @param {*} obj 
>  * @return {number} 
>  * @public 
>  */ 
>  static $getHashCode(obj) { 
> let o = /** @type {Object} */ (obj); 
> return o.$systemHashCode || (Object.defineProperties(o, { 
> $systemHashCode: {value: Hashing.$getNextHashId(), enumerable: false} }), 
> o.$systemHashCode); 
>  }
>
> Anyway, as workaround, I'm rewriting the hashcode property for this object, 
> maintaining the same value but setting the property as not enumerale and it 
> seems working.
>
>
>
>

-- 
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/391b43c1-4863-4002-a292-4c6d3740832co%40googlegroups.com.

Re: [gwt-contrib] Re: Ant, ZipScanner, and GWT

[Colin Alworth]

So, given either "make a git repo on gwtproject/ and add a jar to 
gwtproject/tools" with the minimal history, or a single commit adding all 
already-modified classes to gwt in one go? I should be able to turn out either 
change fairly quickly, once we decide.

Adding to GWT directly would be somewhat lower friction (no need to ship a jar 
to central, easier to further tweak if something is screwy), but as I said, 
loses that tiny bit of history/context. Like you said, a forked jar is not at 
all new for the project to have, and is a nice way to say "this is external, 
even if we tweaked it a bit". For the zip distribution I imagine we'd shade it 
in to the overall zip, but for the m2 release it would probably be an external 
jar (since it will hopefully never change).

-- 
 Colin Alworth
co...@colinalworth.com



On Fri, Jun 12, 2020, at 1:36 PM, Thomas Broyer wrote:
> To minimize the work, and because 1.6.5 works well for us without known 
> vulnerability, I would either copy/paste the code into gwtproject/gwt or 
> provide it in a JAR in gwtproject/tools and call it a day. We already have a 
> copy of Rhino (with changes for JSNI), and a slimmed down version of jsilver 
> containing only the streamhtmlparser.
> No need to try to update and risk a breaking change, and no need to make it 
> "more maintainable" as I'm sure it'll be a one-shot anyway (and that decision 
> could be revisited in the future should we need to make changes to those Ant 
> classes).
> 
> On Friday, June 12, 2020 at 3:31:04 PM UTC+2, Colin Alworth wrote:
>> We have two issues tracking the dependency that GWT has on Ant, 
>> https://github.com/gwtproject/gwt/issues/9690 and 
>> https://github.com/gwtproject/gwt/issues/9677. I've taken a little time and 
>> produced a minimal set of classes copied from ant which appear to provide a 
>> working ZipScanner. For the moment, this lives in its own git repository at 
>> https://github.com/vertispan/ant-zipscanner, and is not deployed anywhere.
>> 
>> I spent a while testing with latest ant, 1.10.8, but semantics have changed 
>> with the zip/directory scanner API such that leading "/" characters no 
>> longer match - rather than break behavior, I've instead switched to simply 
>> using the 1.6.5 code, and modified that for our purposes. This has the 
>> advantage of being substantially smaller than 1.10.8 - 18 types instead of 
>> 46, and of those 18, 11 are required for ant's own implementation of the zip 
>> format, so the other 7 are needed to scan a zip and match contents. It is 
>> quite likely that this could be pruned further, but might come at a cost 
>> when updating to some later ant version (should we decide to do that).
>> 
>> This repository is arranged in three commits:
>>  * Create a script to copy the classes we need from the ant repo, and a pom 
>> to ship these contents. The script is handy when iterating on a new version, 
>> but probably won't be needed unless we do attempt to use a new version
>>  * Copy all required classes from the tag "rel/1.6.5" in the upstream ant 
>> repo
>>  * Comment out anything which didn't compile due to missing dependencies (we 
>> have no use for Project or refs, we only call ZipScanner methods directly), 
>> or which modify the filesystem in some way (to limit risks when depending on 
>> this codebase
>> The resulting output is shaded into a new package by the pom so that it will 
>> not interfere with ant when GWT is compiled (or if GWT is invoked from ant). 
>> 
>> When GWT is updated to both include this jar and also to reference these new 
>> shaded classes instead of the originals within ant, all tests in dev/ pass 
>> and all samples compile, though I haven't yet run all of the other tests.
>> 
>> So, my question is then how to proceed. First of all, is this approach 
>> acceptable in terms of maintenance, or would we prefer reimplementing the 
>> API from scratch in order to drop this dependency, or just updating to the 
>> latest ant version for this one API?
>> 
>> Assuming we like the approach, should we incorporate these copied/modified 
>> sources into GWT itself, or add an additional jar to gwtproject/tools, with 
>> instructions on how to update it, and from there include it into the 
>> project? A somewhat related option could be releasing this jar to maven 
>> central under something like org.gwtproject.ant:ant-zipscanner, and 
>> maintaining it in the github.com/gwtproject umbrella.
>> 
>> Finally, is there any objection to staying with 1.6.5, or should I see if we 
>> can use a later version, or update GWT's internals to use the new behavior 
>> around leading slashes, etc?
> 

> --
>  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/googl

Re: [gwt-contrib] Re: Ant, ZipScanner, and GWT

[Peter Donald]

Possibly a dumb question ... but isn't it possible to just manually
vendor in the source files to GWT? I can't imagine there is a whole
lot of dependencies that would need to be maintained. Just strip out
the gunk you don't need.

On Sat, Jun 13, 2020 at 7:05 AM Colin Alworth  wrote:
>
> So, given either "make a git repo on gwtproject/ and add a jar to 
> gwtproject/tools" with the minimal history, or a single commit adding all 
> already-modified classes to gwt in one go? I should be able to turn out 
> either change fairly quickly, once we decide.
>
> Adding to GWT directly would be somewhat lower friction (no need to ship a 
> jar to central, easier to further tweak if something is screwy), but as I 
> said, loses that tiny bit of history/context. Like you said, a forked jar is 
> not at all new for the project to have, and is a nice way to say "this is 
> external, even if we tweaked it a bit". For the zip distribution I imagine 
> we'd shade it in to the overall zip, but for the m2 release it would probably 
> be an external jar (since it will hopefully never change).
>
> --
>   Colin Alworth
>   co...@colinalworth.com
>
>
>
> On Fri, Jun 12, 2020, at 1:36 PM, Thomas Broyer wrote:
>
> To minimize the work, and because 1.6.5 works well for us without known 
> vulnerability, I would either copy/paste the code into gwtproject/gwt or 
> provide it in a JAR in gwtproject/tools and call it a day. We already have a 
> copy of Rhino (with changes for JSNI), and a slimmed down version of jsilver 
> containing only the streamhtmlparser.
> No need to try to update and risk a breaking change, and no need to make it 
> "more maintainable" as I'm sure it'll be a one-shot anyway (and that decision 
> could be revisited in the future should we need to make changes to those Ant 
> classes).
>
> On Friday, June 12, 2020 at 3:31:04 PM UTC+2, Colin Alworth wrote:
>
> We have two issues tracking the dependency that GWT has on Ant, 
> https://github.com/gwtproject/gwt/issues/9690 and 
> https://github.com/gwtproject/gwt/issues/9677. I've taken a little time and 
> produced a minimal set of classes copied from ant which appear to provide a 
> working ZipScanner. For the moment, this lives in its own git repository at 
> https://github.com/vertispan/ant-zipscanner, and is not deployed anywhere.
>
> I spent a while testing with latest ant, 1.10.8, but semantics have changed 
> with the zip/directory scanner API such that leading "/" characters no longer 
> match - rather than break behavior, I've instead switched to simply using the 
> 1.6.5 code, and modified that for our purposes. This has the advantage of 
> being substantially smaller than 1.10.8 - 18 types instead of 46, and of 
> those 18, 11 are required for ant's own implementation of the zip format, so 
> the other 7 are needed to scan a zip and match contents. It is quite likely 
> that this could be pruned further, but might come at a cost when updating to 
> some later ant version (should we decide to do that).
>
> This repository is arranged in three commits:
>
> Create a script to copy the classes we need from the ant repo, and a pom to 
> ship these contents. The script is handy when iterating on a new version, but 
> probably won't be needed unless we do attempt to use a new version
> Copy all required classes from the tag "rel/1.6.5" in the upstream ant repo
> Comment out anything which didn't compile due to missing dependencies (we 
> have no use for Project or refs, we only call ZipScanner methods directly), 
> or which modify the filesystem in some way (to limit risks when depending on 
> this codebase
>
> The resulting output is shaded into a new package by the pom so that it will 
> not interfere with ant when GWT is compiled (or if GWT is invoked from ant).
>
> When GWT is updated to both include this jar and also to reference these new 
> shaded classes instead of the originals within ant, all tests in dev/ pass 
> and all samples compile, though I haven't yet run all of the other tests.
>
> So, my question is then how to proceed. First of all, is this approach 
> acceptable in terms of maintenance, or would we prefer reimplementing the API 
> from scratch in order to drop this dependency, or just updating to the latest 
> ant version for this one API?
>
> Assuming we like the approach, should we incorporate these copied/modified 
> sources into GWT itself, or add an additional jar to gwtproject/tools, with 
> instructions on how to update it, and from there include it into the project? 
> A somewhat related option could be releasing this jar to maven central under 
> something like org.gwtproject.ant:ant-zipscanner, and maintaining it in the 
> github.com/gwtproject umbrella.
>
> Finally, is there any objection to staying with 1.6.5, or should I see if we 
> can use a later version, or update GWT's internals to use the new behavior 
> around leading slashes, etc?
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "

[gwt-contrib] Re: HashCode H$ property should be not enumerable

[Matt Davis]

I would love to see just ie11 supported. 

-- 
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/a829513d-bc84-456f-9f38-739747e65608o%40googlegroups.com.

[gwt-contrib] Re: HashCode H$ property should be not enumerable

[Slava Pankov]

Even IE11 is not needed anymore for my projects, there is Edge for Windows 
7+, so all my customers are already upgraded.

-- 
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/bee51470-39b2-47cb-9688-15034d981617o%40googlegroups.com.

Re: [gwt-contrib] Re: Ant, ZipScanner, and GWT

[Colin Alworth]

If I understand you, that is what I'm doing - I only the required 18 classes 
(with some members removed so that I don't need more than that), and am just 
seeking an opinion other than my own as to whether it is better to checked them 
straight into gwt as com.google.gwt.thirdparty.ant... classes, or into a 
standalone jar (to be clearer that this is external work+license, and have a 
pointer to where that work originated).

Ant works as a standalone jar as it is, so this would include no external 
dependencies, just these few classes either added directly to gwt, or to gwt's 
tools repo as a jar. The manual work is done, and it was fairly minimal (after 
i figured out the minimal set, and that latest ant doesnt work), just want to 
get thoughts on packaging/licensing, if there are any considerations.

-- 
  Colin Alworth
  co...@colinalworth.com

On Fri, Jun 12, 2020, at 5:19 PM, Peter Donald wrote:
> Possibly a dumb question ... but isn't it possible to just manually
> vendor in the source files to GWT? I can't imagine there is a whole
> lot of dependencies that would need to be maintained. Just strip out
> the gunk you don't need.
> 
> On Sat, Jun 13, 2020 at 7:05 AM Colin Alworth  wrote:
> >
> > So, given either "make a git repo on gwtproject/ and add a jar to 
> > gwtproject/tools" with the minimal history, or a single commit adding all 
> > already-modified classes to gwt in one go? I should be able to turn out 
> > either change fairly quickly, once we decide.
> >
> > Adding to GWT directly would be somewhat lower friction (no need to ship a 
> > jar to central, easier to further tweak if something is screwy), but as I 
> > said, loses that tiny bit of history/context. Like you said, a forked jar 
> > is not at all new for the project to have, and is a nice way to say "this 
> > is external, even if we tweaked it a bit". For the zip distribution I 
> > imagine we'd shade it in to the overall zip, but for the m2 release it 
> > would probably be an external jar (since it will hopefully never change).
> >
> > --
> >   Colin Alworth
> >   co...@colinalworth.com
> >
> >
> >
> > On Fri, Jun 12, 2020, at 1:36 PM, Thomas Broyer wrote:
> >
> > To minimize the work, and because 1.6.5 works well for us without known 
> > vulnerability, I would either copy/paste the code into gwtproject/gwt or 
> > provide it in a JAR in gwtproject/tools and call it a day. We already have 
> > a copy of Rhino (with changes for JSNI), and a slimmed down version of 
> > jsilver containing only the streamhtmlparser.
> > No need to try to update and risk a breaking change, and no need to make it 
> > "more maintainable" as I'm sure it'll be a one-shot anyway (and that 
> > decision could be revisited in the future should we need to make changes to 
> > those Ant classes).
> >
> > On Friday, June 12, 2020 at 3:31:04 PM UTC+2, Colin Alworth wrote:
> >
> > We have two issues tracking the dependency that GWT has on Ant, 
> > https://github.com/gwtproject/gwt/issues/9690 and 
> > https://github.com/gwtproject/gwt/issues/9677. I've taken a little time and 
> > produced a minimal set of classes copied from ant which appear to provide a 
> > working ZipScanner. For the moment, this lives in its own git repository at 
> > https://github.com/vertispan/ant-zipscanner, and is not deployed anywhere.
> >
> > I spent a while testing with latest ant, 1.10.8, but semantics have changed 
> > with the zip/directory scanner API such that leading "/" characters no 
> > longer match - rather than break behavior, I've instead switched to simply 
> > using the 1.6.5 code, and modified that for our purposes. This has the 
> > advantage of being substantially smaller than 1.10.8 - 18 types instead of 
> > 46, and of those 18, 11 are required for ant's own implementation of the 
> > zip format, so the other 7 are needed to scan a zip and match contents. It 
> > is quite likely that this could be pruned further, but might come at a cost 
> > when updating to some later ant version (should we decide to do that).
> >
> > This repository is arranged in three commits:
> >
> > Create a script to copy the classes we need from the ant repo, and a pom to 
> > ship these contents. The script is handy when iterating on a new version, 
> > but probably won't be needed unless we do attempt to use a new version
> > Copy all required classes from the tag "rel/1.6.5" in the upstream ant repo
> > Comment out anything which didn't compile due to missing dependencies (we 
> > have no use for Project or refs, we only call ZipScanner methods directly), 
> > or which modify the filesystem in some way (to limit risks when depending 
> > on this codebase
> >
> > The resulting output is shaded into a new package by the pom so that it 
> > will not interfere with ant when GWT is compiled (or if GWT is invoked from 
> > ant).
> >
> > When GWT is updated to both include this jar and also to reference these 
> > new shaded classes instead of the originals within ant, all tests in dev/

Re: [gwt-contrib] Re: Ant, ZipScanner, and GWT

[Peter Donald]

On Sat, Jun 13, 2020 at 11:11 AM Colin Alworth  wrote:
> If I understand you, that is what I'm doing - I only the required 18 classes 
> (with some members removed so that I don't need more than that), and am just 
> seeking an opinion other than my own as to whether it is better to checked 
> them straight into gwt as com.google.gwt.thirdparty.ant... classes, or into a 
> standalone jar (to be clearer that this is external work+license, and have a 
> pointer to where that work originated).

If it was me, I would just pull the source in and place it in
com.google.gwt.util.tools.zipscanner and flatten all the files into
that package. No need to mark it as vendored as you never intend to
pull from upstream again as they have moved in an incompatible
direction. They are license compatible as both Apache-2.0 and as long
as the GWT project does not have a policy against including code that
is copyright to another organization in source tree then that seems
like the easiest option going forward.

-- 
Cheers,

Peter Donald

-- 
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/CACiKNc5WRTMQHNRDxLgSJGUnfPfOfguLkfcvfVioDK4P%3DTAqdg%40mail.gmail.com.