ImmutableSet.toArray issue on singletonImmutableSet for v14

[GoogleCodeExporter]

Hi,

private static final ImmutableSet<String> ISLEM_EB_FIELDS = 
ImmutableSet.of("ISLBLG");

For above desc, a singletonImmutableSet is created. When I try

ISLEM_EB_FIELDS.toArray(new String[0])

on V13.0.1, ist OK but in v14, it throw class not found exception for

com.google.common.collect.GwtPlatform.java

I tried it on a GWT application.

Original issue reported on code.google.com by gokhano...@gmail.com on 11 Mar 2013 at 3:23

[GoogleCodeExporter]

+Chris as our resident GWT expert

Original comment by kurt.kluever on 11 Mar 2013 at 5:02

• Added labels: Package-Collect, Type-Defect

[GoogleCodeExporter]

Hmm. If anything, I would have hoped that v14 would have *helped* with any 
GwtPlatform problems (not that I was aware of any problems in practice):

http://code.google.com/p/guava-libraries/source/detail?r=02e459aacc3b534a580cd65
6b2e5d167b8b45026&name=v14.0

GWT should be using GwtPlatform only in development mode. Is that where you're 
seeing the error?

Original comment by cpov...@google.com on 11 Mar 2013 at 5:25

[GoogleCodeExporter]

Actually yes, I see that error on gwt dev mode and only sets that has 1 
element. If I put another element, it creates a regular set and everything is 
fine

Original comment by gokhano...@gmail.com on 11 Mar 2013 at 6:27

[GoogleCodeExporter]

Thanks. I can reproduce it as you've described.

I notice this TODO in GwtPlatform:

"Once we start using server-side source in hosted mode, we won't need this."

It sounds like hosted mode (i.e., dev mode) didn't use to do that before but 
that now it does. It may be enough for us to just get rid of the class. I'll 
investigate further. This will probably deserve a patch release.

Original comment by cpov...@google.com on 11 Mar 2013 at 9:04

• Changed state: Accepted
• Added labels: Milestone-Release14

[GoogleCodeExporter]

Err, what I said doesn't make sense: Dev mode is *still* using client-side 
source, as we can tell from its use of GwtPlatform. In case that's not 
convincing, here's the stack trace:

Caused by: java.lang.NoClassDefFoundError: com/google/common/collect/GwtPlatform
    at com.google.common.collect.Platform.newArray(Platform.java:41)
    at com.google.common.collect.ObjectArrays.newArray(ObjectArrays.java:45)
    at com.google.common.collect.ImmutableCollection.toArray(ImmutableCollection.java:52)

That's all emul code.

So maybe the fix is to compile the dev-mode GwtPlatform as part of the 
server-side GWT sources? I'll try that.

Original comment by cpov...@google.com on 11 Mar 2013 at 9:42

[GoogleCodeExporter]

Initial results are positive: My dummy app no longer gets a 
NoClassDefFoundError, and the other tests I've run still pass. I'll do some 
more testing tomorrow.

Original comment by cpov...@google.com on 11 Mar 2013 at 11:18

[GoogleCodeExporter]

Testing is still looking good. I'm now trying to figure out how important 
GwtPlatform's @GwtScriptOnly annotation is in the hope that we can eliminate it 
-- or GwtPlatform entirely, to minimize the chance of problems like this in the 
future, especially since our tests don't detect them.

Original comment by cpov...@google.com on 12 Mar 2013 at 9:16

[GoogleCodeExporter]

We can safely remove @GwtScriptOnly from the 
guava-gwt/src/com/google/common/collect copy of GwtPlatform: It's the 
annotation on the copy in 
guava-gwt/src-super/com/google/common/collect/super/com/google/common/collect 
that appears to be authoritative. This saves us from having to ask some 
questions about new dependencies internally.

My attempts to eliminate GwtPlatform entirely have been unsuccessful for 
reasons that I don't quite understand. I'll be working with the GWT team to get 
that figured out.

Original comment by cpov...@google.com on 12 Mar 2013 at 10:15

[GoogleCodeExporter]

I was wrong about most of this. It's true that GWtPlatform needs to be 
available on the server side, but this was already true. Or rather, it should 
have been true if not for the real problem, a sourceDirectory error I 
introduced a while back and fixed for rc3:

http://code.google.com/p/guava-libraries/source/detail?r=f3a94bc591b3c738bb4b04f
95e263515f0b62f29&name=v14.0-rc3

But somehow the fix isn't in 14.0-final. It looks like that may have gotten 
branched from 14.0-rc2 instead of rc3. If so, the good news is that we don't 
need to wait at all before releasing 14.0.1, since we've already had its rc out 
for testing... :) Kurt?

http://code.google.com/p/guava-libraries/source/list?name=v14.0

Original comment by cpov...@google.com on 13 Mar 2013 at 4:05

[GoogleCodeExporter]

This was fixed in 14.0.1.

Original comment by cpov...@google.com on 10 Apr 2013 at 9:20

• Changed state: Fixed

[GoogleCodeExporter]

This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<issue id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:12

• Added labels: MigratedToGitHub

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:08

• Added labels: Restrict-AddIssueComment-Commit