Serialized Object

I have serialized an object to disk.  The disk file starts out with eight bytes of gobbledygook (let's call it XXXXXXXX), followed by project.object, followed by eight more bytes of gobbledygook (let's call it YYYYYYYY), followed by the bulk of the serialized object (let's call it BBB...B).  Herre are the results of an experiment:

Object with method:    XXXXXXXXproject.objectYYYYYYYYBBB...B
Object without method: XXXXXXXXproject.objectZZZZZZZZBBB...B
and YYYYYYYY is not at all similar to ZZZZZZZZ.

I have only one question, but I have to ask it in three pieces: (1) Why is the method-induced information embedded in the serialized object?  (2) The method is certainly not stored inside the serialized object, is it? It would have increased the byte count! (3) How the $#!@ am I supposed to make serialized objects publicly available, while the uppity little jerks demand to be reused by only the project that created them?  Note: It does not help to put the objects into database storage with public permission, because the byte code within the retrieved object still cites itself as belonging to the project that created it.
richbAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

jhanceCommented:
This is the essence of serialized objects.  They are useful ONLY to objects of the same type.  No other use can be guaranteed.  My advice it to serialize only objects that you are prepared to deliver with the data.  This is not as restrictive as it might seem.  You don't have to tie this to a particular class with your methods, you really should create a "lower level" class to encapsulate your data. Then your application can instanciate, use, and serialize those objects.  Then other "clients" of the serialized data can use the data as well by using the same base class objects.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
richbAuthor Commented:
"Clients" of the serialized data ?  Please elaborate.
0
jhanceCommented:
I'm assuming here that you have an application that is writing out serialized objects.  This is the producer or server of the objects.  I gather from your question that you want to use these serialized objects in some other application, a consumer or client.  Since the server and the client are likely to be different applications and have different classes, they won't be able to share each others serialized objects.  Hence my suggestion is to use a common object that they both know about that is defined in a separate class.  These objects can be serialized and written out by the server and de-serialized and read-in by the client.
0
OWASP: Avoiding Hacker Tricks

Learn to build secure applications from the mindset of the hacker and avoid being exploited.

richbAuthor Commented:
My observation was that common objects are wanted but they have information embedded in them that I do not want embedded in them, i.e. the project or package name.  I feel trapped into rolling all my projects together into a single big ugly project, just because they all use a common object.  I am looking for a way around this.
0
jhanceCommented:
I'll see if I can work up an example of what I mean.  Sometimes a few lines of code can really clarify the situation.
0
jhanceCommented:
OK, here's an example.  First, the DataObject class:

import java.io.*;
import java.util.*;

public class DataObject implements Serializable
{
      private int number;
      
      DataObject(){ number = 2; }
      public int getNumber(){ return number; }
      public void setNumber(int inNumber){ number = inNumber; }
      
}


Now, the Writer Class:

import java.io.*;

public class Writer
{
      public static void main (String args[])
      {
            System.out.println("Writing a DataObject...");
            
            // Create the object and set it's value to non-default
            DataObject myObj = new DataObject();
            myObj.setNumber(5);
            
            // Open an ObjectOutputStream to write it to
            try{
                  FileOutputStream fo = new FileOutputStream("ObjectDataFile");
                  ObjectOutputStream myOutputStream = new ObjectOutputStream(fo);
                  myOutputStream.writeObject(myObj);
                  myOutputStream.flush();
                  myOutputStream.close();
            }
            catch(IOException e){
                  System.out.println("ERROR");
            }                        
      }
}


And the Reader Class:

import java.io.*;

public class Reader
{
      public static void main (String args[])
      {
            System.out.println("Reading a DataObject...");
            
            // Create the object
            DataObject myObj = null;
            
            // Open an ObjectInputStream and read from it
            try{
                  FileInputStream fi = new FileInputStream("ObjectDataFile");
                  ObjectInputStream myInputStream = new ObjectInputStream(fi);
                  myObj = (DataObject)myInputStream.readObject();
                  myInputStream.close();
            }
            catch(Exception e){
                  System.out.println("ERROR");
            }
            
            System.out.println("Object read was: " + myObj.getNumber());
      }
}
0
richbAuthor Commented:
I agree, all my complaints vanish when I abstain from using package names.  That is what I used to do when I was writing test programs.  Now I am trying to develop stuff for real, so I need to use package statements, and I need to make them correspond to directories.

DataObject class:
package common;  // source code in C:\somewhere\common
import ...
public class DataObject implements Serializable ...

Writer Class:
package common;  // source code in C:\somewhere\common
import ...
public class Writer { public static void main ...

Reader Class:     // source code in C:\somewhere\special
package special;  // this is my problem: special!=common
import ...        // so not eligible to read serialized object
public class Reader { public static void main ...

What I am trying to do is set up an environment of directories that correspond to packages.  Perhaps what I need to do is somehow nest diectories of the new projects within the directory of the project which created the object?  Could this somehow permit access to the serialized objects?

Reader1 Class:
package common.special1;
// source code in C:\somewhere\common\special1
import java.io.*;  
public class Reader1 { public static void main ...

Reader2 Class:
package common.special2;
// source code in C:\somewhere\common\special2
import java.io.*;  
public class Reader2 { public static void main ...


0
jhanceCommented:
It really doesn't make any difference, but this also works:

package DataObject;
import java.io.*;
import java.util.*;

public class DataObject implements Serializable
{
      private int number;
      
      DataObject(){ number = 2; }
      public int getNumber(){ return number; }
      public void setNumber(int inNumber){ number = inNumber; }
      
}


import java.io.*;
import DataObject.*;

public class Reader
{
      public static void main (String args[])
      {
            System.out.println("Reading a DataObject...");
            
            // Create the object
            DataObject myObj = null;
            
            // Open an ObjectInputStream and read from it
            try{
                  FileInputStream fi = new FileInputStream("ObjectDataFile");
                  ObjectInputStream myInputStream = new ObjectInputStream(fi);
                  myObj = (DataObject)myInputStream.readObject();
                  myInputStream.close();
            }
            catch(Exception e){
                  System.out.println("ERROR");
            }
            
            System.out.println("Object read was: " + myObj.getNumber());
      }
}



import java.io.*;
import DataObject.*;

public class Writer
{
      public static void main (String args[])
      {
            System.out.println("Writing a DataObject...");
            
            // Create the object and set it's value to non-default
            DataObject myObj = new DataObject();
            myObj.setNumber(5);
            
            // Open an ObjectOutputStream to write it to
            try{
                  FileOutputStream fo = new FileOutputStream("ObjectDataFile");
                  ObjectOutputStream myOutputStream = new ObjectOutputStream(fo);
                  myOutputStream.writeObject(myObj);
                  myOutputStream.flush();
                  myOutputStream.close();
            }
            catch(IOException e){
                  System.out.println("ERROR");
            }                        
      }
}
0
richbAuthor Commented:
Doh!
0
jhanceCommented:
richb,

I'm curious about what the problem you were seeing was.

Thanks...
0
richbAuthor Commented:
I had the concept of "package" embedded in my head in two different locations with bogus linkage inbetween.  One instance of "package" was useful only for management of a project through subdirectories, and the other instance was useful only for importing stuff created by somebody not identically equal to me.  If aliens ever invade and force all humans to link up to a common hive mind, I'd cause irreparable damage within the first few milliseconds.
0
jhanceCommented:
The "package" definition is not very well understood and I put the blame on the Java documentors.  I've never seen a good explanation of it anywhere.  C and C++ don't really have an equivalent concept.  If you combine a header and a compiled library file, you come close but it's still not the same.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Java

From novice to tech pro — start learning today.