• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

[Help] Sending List<String> via Socket.

 
Ranch Hand
Posts: 103
Netbeans IDE Eclipse IDE Firefox Browser
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello everyone, let me intruduce my question at begining.

Ok, Im making CLIENT <-> SERVER based application with sockets (its multithreaded server)

Everything works well, by sending simple STRINGS such us:



But in my program, my CLIENT will have to receive LIST with some kind of Strings inside, and iterate it and add to the JList swing component

Server contains such List:



Now I would like to send it to my Client, and also receive LIST (or something else to be able to iterate it and simply add one by one to the JList)

Thanks in advance for any help!
 
Ranch Hand
Posts: 79
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You could get OutputStream from Socket, wrap it in ObjectOutputStream class and write there almost any object you like using writeObject method. But you should keep in mind the following two things. First - the object you write should implement Serializable interface. Second - you should write not object itself but it's clone, otherwise you will be recieving the same object on client side. So object you write should also be cloneable.

In your case: Lists are not cloneable, while arrays are. So i believe it's better to convert your List to array using 'toArray' function and then write this array to client. The code for this will be like the following:
 
Sheriff
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Andrey Kozhanov wrote:Second - you should write not object itself but it's clone, otherwise you will be recieving the same object on client side. So object you write should also be cloneable.


Say what? I think you don't understand how serialization works. It turns objects into a sequence of bytes, and de-serialization turns a sequence of bytes into objects. Those de-serialized objects are not the same as the serialized objects. Furthermore, with the client-server setup here, it's impossible to have the same object on the client side as that's running in a separate JVM. JVMs do not share the same objects, as those are stored in memory and JVMs do not share memory.

The de-serialized object is in general equal to the original (as determined by the equals method), but it's not the same object (as determined by ==) (unless readResolve is used to explicitly allow this, but that's mostly not the case).
 
Andrey Kozhanov
Ranch Hand
Posts: 79
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Rob Spoor wrote:Say what? I think you don't understand how serialization works. It turns objects into a sequence of bytes, and de-serialization turns a sequence of bytes into objects. Those de-serialized objects are not the same as the serialized objects. Furthermore, with the client-server setup here, it's impossible to have the same object on the client side as that's running in a separate JVM. JVMs do not share the same objects, as those are stored in memory and JVMs do not share memory.

The de-serialized object is in general equal to the original (as determined by the equals method), but it's not the same object (as determined by ==) (unless readResolve is used to explicitly allow this, but that's mostly not the case).



Just try pass some object via socket yourself. For some reasons clones are still needed, at least for all my local examples it was true.
 
Mathew Mintalm
Ranch Hand
Posts: 103
Netbeans IDE Eclipse IDE Firefox Browser
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hm guys, thanks for your help, and what do you think about this kind of "solution" (quite primitive I guess)

Lets say I have List<String> at my Server side with some Strings.

Now Im making "one String" based at this list with this way:



So lets say my List contains those Strings: "Test1", "hello", "lol", "works"

So I will receive:

playerList_Test1_hello_lol_works String

And im sending it via socket to my client, and receiving with this way:



It works well, but its quite primitive i guess, and would it work well while for example LIST contains several thousand of Strings?
 
Rob Spoor
Sheriff
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Andrey Kozhanov wrote:

Rob Spoor wrote:Say what? I think you don't understand how serialization works. It turns objects into a sequence of bytes, and de-serialization turns a sequence of bytes into objects. Those de-serialized objects are not the same as the serialized objects. Furthermore, with the client-server setup here, it's impossible to have the same object on the client side as that's running in a separate JVM. JVMs do not share the same objects, as those are stored in memory and JVMs do not share memory.

The de-serialized object is in general equal to the original (as determined by the equals method), but it's not the same object (as determined by ==) (unless readResolve is used to explicitly allow this, but that's mostly not the case).



Just try pass some object via socket yourself. For some reasons clones are still needed, at least for all my local examples it was true.


Can you show us a SSCCE that shows this problem? Because it's the first time I've heard about it.


Mathew, what will you do if one of your values contains a _ itself? I strongly suggest using ObjectOutputStream / ObjectInputStream and sending either a List<String> or a String[].
 
Mathew Mintalm
Ranch Hand
Posts: 103
Netbeans IDE Eclipse IDE Firefox Browser
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My LIST containt only nick names of players from MMORPG Server emulator (Lineage2 mmo game, L2J Server emulator)

And player may have only strict name, without any chars such as "_", "!@#$%^&*())" etc, so its not a problem.

Anyway, nice that you have noticed it, because I didn't
 
Andrey Kozhanov
Ranch Hand
Posts: 79
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Rob Spoor wrote:Can you show us a SSCCE that shows this problem?


There you are:
I used array of strings in my example. But actually the same is true if we are sending any mutable object.
 
Rob Spoor
Sheriff
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ah, yes. This occurs because you write the very same object to the ObjectOutputStream twice. Serialization is smart enough to notice this, and the second time it only stores a reference to the first one inside the serialized data. So you have a point - if you plan on writing the same object twice to the same ObjectOutputStream then you should clone the data, to make sure that the second one is a copy instead of a reference. Unless of course you need a reference only.
 
To do a great right, do a little wrong - shakepeare. twisted little ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic