com.google.common.collect.GwtPlatform in incompatible with GWT 2.8.0-beta1

[fkirill]

Guava-GWT 18.0 and 19.0 are both incompatible with GWT 2.8.0-beta1. 2.7.0 is working properly.
Both versions reference missing method int GWT core library that is no longer present in 2.8.0.

Interesting aspect is that this problem only appears in SuperDev mode, there is no error message during 'normal' GWT compile.

SuperDev mode produces the following error message:
Compiling module XXXXX
[ERROR] Errors in 'com/google/common/collect/super/com/google/common/collect/GwtPlatform.java'
[ERROR] Line 38: The method createFrom(T[], int) is undefined for the type Array
Tracing compile failure path for type 'com.google.common.collect.GwtPlatform'
[ERROR] Errors in 'com/google/common/collect/super/com/google/common/collect/GwtPlatform.java'
[ERROR] Line 38: The method createFrom(T[], int) is undefined for the type Array

The root cause is in class GwtPlatform (comments removed)

package com.google.common.collect;

import com.google.common.annotations.GwtCompatible;
import com.google.gwt.core.client.GwtScriptOnly;
import com.google.gwt.lang.Array;

@GwtCompatible
@GwtScriptOnly
public final class GwtPlatform {

  private GwtPlatform() {}

  public static <T> T[] newArray(T[] reference, int length) {
    return Array.createFrom(reference, length);
  }
}

As you can see, it references Array.createFrom that was removed in version 2.8.0.

I would suggest the following solution. It doesn't use any internal API and seems to be working cleaner then previous one (Array,createFrom didn't initialize the elements of new array that were not copied from reference and they stayed undefined instead of null).

  public static <T> T[] newArray(T[] reference, int length) {
        T[] res = (T[]) new Object[length];
        if ((reference != null) && (reference.length > 0)) {
            System.arraycopy(reference, 0, res, 0, Math.min(length, reference.length));
        }
        return res;
  }

Thank you!

[cpovirk]

Sorry for the trouble. Various GWT changes have made it impossible for a single version of Guava to support both GWT 2.7 and GWT 2.8. We intend to release a new Guava that is compatible with GWT 2.8 once 2.8 is out: #1999 You can follow that issue for updates.

[cpovirk]

(This is in the release notes but easy to miss: https://github.com/google/guava/wiki/Release19#gwt-notes)

[fkirill]

Alrighty, if you use the proposed code above, it does NOT depend on any internal GWT structures at all. So it is safe to use it in any case (in all GWT versions).
I'm unaware of any other troubles, but this one is easy to fix.

Thanks.

[cpovirk]

There are some other issues. GWT is adding a Charset emulation that would conflict with ours, for instance.

[fkirill]

I guess, that;s independent of this one. I'm not arguing, just if you accept this fix, it will make your life in terms of #1999 a bit easier.

[cpovirk]

The above fix compiles but doesn't actually return a T[], only an Object[] that looks like one. The method is expected to return a T[].

[fkirill]

OK, maybe, I'm not an expert in low-level implementation details, I guess,
GWT team should help here.

On Thu, 7 Jan 2016 13:51 Chris Povirk notifications@github.com wrote:

The above fix compiles but doesn't actually return a T[], only an Object[]
that looks like one. The method is expected to return a T[].

—
Reply to this email directly or view it on GitHub
#2353 (comment).

[AlihassanProgrammer]

are you using singleton pattern in your project .... if yes then why..

[JamesXNelson]

The code above is not what you want at all.

The class literal on the object array will cause troubles later if you try to assign it to a properly typed variable.

The method you are looking for is new:
javaemul.internal.ArrayHelper.createFrom(notCopied, length)

All of the really intrinsic "must have this just to use java types" all live in the new javaemul.internal package.

[JamesXNelson]

These types are, of course, super sourced, but I imagine that it is no problem, as they will be accessed via super-sourced types.

[JamesXNelson]

Ah, I see it is patched using Arrays.copyOf, which is already emulated to route to the ArrayHelper. Nevermind :D