Re: Problem with Generics and Serialization of Primitive Type Array Fields
Unfortunately, this won't work due to the bug I referenced earlier (sorry, I must have cut it out of the quoted section). This will compile, but will throw a ClassCastException due to a known bug (http://code.google.com/p/google-web-toolkit/issues/detail? id=1822): new MySerializableObject(new Integer[] {1}) As suggested in the issue comments, it's possible to work around this by creating another class, which is a reasonable way to solve the problem for arrays of most types: class MySerializableArrayObject extends MySerializableObject { private Serializable serializableArrayField[]; void MySerializableObject(T[] value) { serializableArrayField= value; } T[] getField() { return serializableArrayField; } } The class above makes this work (for Integer, or any other non- primitive type): new MySerializableArrayObject(new Integer[] {1}); . . .But won't fix the problem for primitive types, since it is not possible to type the array version of the object for use with primitives: new MySerializableArrayObject(new int[] {1}); //This won't compile, of course new MySerializableArrayObject(new int[] {1}); //Nor will this, since int[] can't be autoboxed to Integer[] If you're suggesting that I can replace all uses of int[] with Integer [] in the existing code (at least the parts that need to interact with this class), you are technically correct. This will, however, leave a significant maintenance hazard for anyone else working on the app. I can document the problem, but given the context in which these classes are used, it would be tough to do so in enough places that anyone wanting to use primitive arrays would notice it. That's why I'm looking for a better work-around. I'm currently planning to make variations on MySerializableArrayObject to specifically handle each type of primitive array. I don't think this will cover some edge-cases, such as multidimensional arrays, but it looks like it may be the best solution available for now. If someone can suggest a better one, I'm still very interested. On Feb 9, 3:53 pm, Dan Ox wrote: > Have you tried: > new MySerializableObject(new Integer[] {1}); > > ? > > On Feb 10, 4:13 am, jsegal wrote: > > > You're correct that primitives themselves will not work, but they can > > be autoboxed using their Object versions. My problem is with *arrays* > > of primitive types, which *can* be used as parameters for for generic > > classes, and should (according to everything I've found on the > > subject) be serializable. > > > You're right that this will not compile: > > new MySerializableObject(1); > > > This will compile, however: > > new MySerializableObject(new int[]{1}); > > > As will this (due to autoboxing): > > new MySerializableObject(1); > > > On the other hand, arrays cannot be autoboxed, so this will not > > compile: > > new MySerializableObject(new int[]{1}); > > > On Feb 6, 6:10 pm, Ben Tilford wrote: > > > > Primitives do not extend Object and cannot implement Serializable. You > > > should use the Object versions of primitives (i.e. use Integer instead of > > > int) > > > I don't think the code would even compile if you tried to use a primitive > > > with generics. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Problem with Generics and Serialization of Primitive Type Array Fields
You're correct that primitives themselves will not work, but they can be autoboxed using their Object versions. My problem is with *arrays* of primitive types, which *can* be used as parameters for for generic classes, and should (according to everything I've found on the subject) be serializable. You're right that this will not compile: new MySerializableObject(1); This will compile, however: new MySerializableObject(new int[]{1}); As will this (due to autoboxing): new MySerializableObject(1); On the other hand, arrays cannot be autoboxed, so this will not compile: new MySerializableObject(new int[]{1}); On Feb 6, 6:10 pm, Ben Tilford wrote: > Primitives do not extend Object and cannot implement Serializable. You > should use the Object versions of primitives (i.e. use Integer instead of > int) > I don't think the code would even compile if you tried to use a primitive > with generics. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Problem with Generics and Serialization of Primitive Type Array Fields
I've been having some trouble with using arrays of primitive type where an array of type Serializable is expected. I have an object similar to: class MySerializableObject implements Serializable { private Serializable serializableField; void MySerializableObject(T value) { serializableField= value; } T getField(T value) { return serializableField; } } All of these cases can be serialized and deserialized successfully: - new MySerializableObject(new Integer(0)); - new MySerializableObject(1); - new MySerializableObject(true); - new MySerializableObject("Test"); These cases case produces an exception when deserialized (Note that these will *not* cause a class cast exception as seen in http://code.google.com/p/google-web-toolkit/issues/detail?id=1822, although an array of non-primitive type will cause it): - new MySerializableObject<(Serializable)>((Serializable)new int[0]); - new MySerializableObject(new int[0]); The exception's message is: "com.google.gwt.user.client.rpc.IncompatibleRemoteServiceException: Type '[I' was not included in the set of types which can be deserialized by this SerializationPolicy or its Class object could not be loaded. For security purposes, this type will not be deserialized." The exception goes way if I add this type to my project, even if I don't actually create an instance of it anywhere: class MySerializableIntArrayObject extends MySerializableObject { } I'm aware that the GWT compiler has to identify sub-types that can be used with parameterized serializable objects during compilation in order to build its serialization mechanism for those objects. I'm guessing this problem means that arrays of primitive types are not taken into account when it enumerates subtypes of Serializable, despite the fact that they are effectively subtypes of Serializable. If I'm correct, what is the proper way to fix this? I suppose it's possible to create fixed-type objects like "MySerializableIntArrayObject" for all primitives, but I'd like to avoid that (especially since I would end up having to do that for any other typed serializable objects I add in the future). If I understand the typeArgs annotation, using it would actually restrict the set of values I can use with this object, not add to the set (I can enumerate the primitive array types easily enough, but not all the other types that may be passed). If I'm not correct about the cause of the problem, I'd appreciate it if someone could explain it and suggest an appropriate remedy. Thanks, -jsegal --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
MenuBar Too Small to Display All Items
I'm having trouble with a MenuBar that can (and commonly does) end up being too short (horizontally) to display all of its items after the user resizes its container, or new items are added to the menu. Adding standard scrolling behavior doesn't seem to work very well (the presence of the horizontal scrollbar makes the menu take up too much space, and forces it to scroll vertically as well). I'd really like to do one of two of two things: 1. When the menu becomes too small to display all items, it could replace its rightmost item with an "arrow" item that shows all of the hidden items in a submenu when clicked (I see this in a lot of desktop applications). 2. Add "scroll left" and "scroll right" buttons on either end of the menu that allow the user to scroll the menu left or right in order to access hidden items (the buttons would behave similarly to the buttons on either end of a standard scrollbar, but would be in line with the menu items, instead of having a full scrollbar that appears below the menu). Can anyone suggest a way to implement either of these behaviors (or an alternative)? Right now, I don't even see a good way to determine when the MenuBar has become too small. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---