• Hulk (unregistered)

    I like turtles.

  • surt (unregistered) in reply to JM
    c.) yes you can serialize at will. Serialiable is a marker interface that just tells the compiler that you want to be able to serialize this thing. The fact that it has no methods is irrelevent. Think of it like a keyword like public/private/protected or perhaps volatile. As far as running bytecode is concerned there is not much meaning but the compiler does or expects certain things when it is encountered.

    I use this feature all the time for communicating from applet to server. It's a very easy way to let a client build up a bunch of state, and pass it to a server (over tcp stream). Keeps you from having to build any of your own object serdes code when you want to pass structured data between different vm instances.

    captcha: craaazy (maybe I am, but this seems straightforward to me)

  • (cs) in reply to Steve
    Steve:
    Of course, that might have been just a jesting effort to shut the stupid compiler up and keep it from complaining about a missing serialVersionUID in a class extended from one which implements the Serializable interface.

    You'll find

        private static final long serialVersionUID = 42L; // To shut up compiler
    in a lot of my classes which are never going to be serialized.

    What you'll come to find is that, in Java, things which are a bad idea, tend to be a pain to implement. That is largely by design.

    For instance, when you extend a class, you are inheriting not only methods but also all of the contracts honored by that class. The whole point of inheritance and polymorphism is that instances of your class should be suitable and safe replacements for instances of the superclass.

    So when you extend a Serializable class, you are expected to uphold the Serializable contract, because an instance of your class can be passed anywhere an instance of the superclass is expected.

    Extending a class just to use its functionality, when a simple aggregate relationship would do, is not especially good practice. (Unfortunately, it is nearly universal among Swing programs.)

  • (cs)

    Neat! They should add a prize (like gambling in vegas or lotto tickets) if you manage to open a file! The odds of actually matching serial versions are what... like ... 1 in 4.3billion?

  • (cs) in reply to SomeCoder
    SomeCoder:
    A pretty handy feature I might say. Without it, the API would need to rely on the compiled assembly’s version number (which might change on each compile) even if the class definition remains the same. But with a serialVersionUID, developers can be in control of whether or not two versions of a class definition are the same.

    Yeah... sure be nice if .NET would do that.

    The .NET assembly loading code is the biggest WTF I've ever seen in my life.

    you can manually enter the version number in the project properties. (Major, Minor, Rev) Can't assign it to a random 64 bit integer though... (is java running 64 bit longs yet? I wasnt sure). Actually... I like the way that .NET handles it better... becuase you can set it to auto-increment... and it is all integrated into deployment packages.

  • sf (unregistered) in reply to pitchingchris
    pitchingchris:
    BlueEagle:
    This isn't a wtf. The person is clearly implementing this strategy so that noone should be able to (unless really (un)lucky) to load an old instance of the class because the class is under development and as such is changing. Any attempts to load an old class would ofcourse fail.

    So therefore it's important to ehh.. no.. wait.. It actually IS a wtf.

    captcha: Sanitarium (I would need one)

    From an objective standpoint, why even make it to where your loads will fail. Its serialization. The point is to save the object so you can load it later. If you don't want to load it later, don't serialize it in the first place !

    Well saving and restoring are not the only situations where serialization is used. It is also use when passing objects between distributed services/clients with fromeworks such as RMI.

    This kind of technique would make it so that, if a client were using dynamic class loading, the client would only be able to exchange the same data with a service that it received from the service during that service's lifetime. That said, I'm guessing that a service that had that kind requirement must be full of WTF's.

  • Logan (unregistered) in reply to VGR
    VGR:
    Steve:
    You'll find 
        private static final long serialVersionUID = 42L; // To shut up compiler
    in a lot of my classes which are never going to be serialized.
    What you'll come to find is that, in Java, things which are a bad idea, tend to be a pain to implement. That is largely by design.

    For instance, when you extend a class, you are inheriting not only methods but also all of the contracts honored by that class.

    So when you extend a Serializable class, you are expected to uphold the Serializable contract

    This is all well and good except for one little thing: java.lang.Exception is Serializable by default, thus forcing Serializable onto every exception you want to throw. And because Java forces exceptions into a fixed hierarchy of classes (Throwable, Exception, etc.) with hardcoded behavior, you have to use that class hierarchy for your own exceptions. Whether you want them to be serialized or not.

    I can see an argument for serializing exceptions sometimes, but it's not something you always want to do. And that's why my exception classes often have a dummy serial number to shut the compiler up.

  • (cs) in reply to AC
    AC:
    This doesn't account for the fact the class itself could be garbage collected and then you couldn't even deserialize the object from within the same VM. It also doesn't allow a different ClassLoader's version of the class to be loaded within the same VM. Static isn't once per VM, it's once per class load.
    In most cases, the only ClassLoader that will be active is the bootstrap ClassLoader, and the classes it loads are never garbage collected.
  • (cs) in reply to Mexi-Fry
    Mexi-Fry:
    you can manually enter the version number in the project properties. (Major, Minor, Rev) Can't assign it to a random 64 bit integer though... (is java running 64 bit longs yet? I wasnt sure).
    Yet? Java longs have been ALWAYS been 64 bit as per the language spec.
  • (cs) in reply to sf
    sf:
    Well saving and restoring are not the only situations where serialization is used. It is also use when passing objects between distributed services/clients with fromeworks such as RMI.

    This kind of technique would make it so that, if a client were using dynamic class loading, the client would only be able to exchange the same data with a service that it received from the service during that service's lifetime.

    I don't think that would work. The SerialVersionUID is a static field, so the client would not be able to deserialize the instances it receives since it would have a different value. Thus, it would never get to the point where it could send them back.

  • Blaufish (unregistered) in reply to surt
    surt:
    I use this feature all the time for communicating from applet to server. It's a very easy way to let a client build up a bunch of state, and pass it to a server (over tcp stream).

    One would really have to think one or two times about the design of such a solution. If you just transmit data through the class, no problem. If the class is more powerful, then "Can it be abused?"

    consider

    public class Insecure implements Serializable {
private String stuff;
public void doStuff() {
Process proc = Runtime.getRuntime().exec(stuff);
}
}

    The example is absurd, certainly. But I think many people might miss the implications of desearilizing from an external and untrusted source.

  • Synonymous Awkward (unregistered) in reply to Jim R. Wilson
    Jim R. Wilson:
    var m=Math;r=m.random;(r()<0.5?'-':'')+m.round(m.pow(10,17)*r())+'L'

    For those of us who don't randomly reassign system functions for the hell of it, that's:

    (Math.random()<0.5 ? '-' : '') + Math.round(Math.pow(10,17)*Math.random()) + 'L'

  • (cs) in reply to Blaufish
    Blaufish:
    One would really have to think one or two times about the design of such a solution. If you just transmit data through the class, no problem. If the class is more powerful, then "Can it be abused?"

    consider

    public class Insecure implements Serializable {
private String stuff;
public void doStuff() {
Process proc = Runtime.getRuntime().exec(stuff);
}
}

    The example is absurd, certainly. But I think many people might miss the implications of desearilizing from an external and untrusted source.

    Only instance state is serialized and deserialized, not the class implementation. So you don't have any more to fear than with any other kind of communication protocol.

  • TraumaPony (unregistered)

    As MyAbacusHasAVirus said, this could be used to keep memory usage down. Sort of like a page file; the memory contents would only be valid for a certain run of the application. Otherwise, it would be invalid data; so don't let it be re-instated after it's been shut down. But loading and saving data to the HDD while the app is still running, then there'd be nothing wrong with it.

    CAPTCHA: Who gives a fuck what it is.

  • Steve (unregistered) in reply to BG
    BG:
    Why are you making classes "implement Serializable" if they will never be Serialized...WTF.
    I'm not. I'm extending classes which implement Serializable, for instance, JPanel.

    If there's a better way of doing this, I'm all for hearing about it. I learned how to program in Java by buying the Flanagan book and reading the first three or four chapters, so I'm sure I missed something or another along the way. My first efforts weren't particularly pretty but I think I'm getting there. . .

  • Joe Blaim (unregistered)

    For all of you C# programmers who missed the point, (I don't blame you, java Serialization is slightly counter-intuitive) the best comparison is C-style binary reading and writing. Saving a data structure in binary and then adding a field to it can cause unpredictable results when reading that data. This mechanism gives the developer control over when the read library should even try.

    Also, It's not so much a true interface as a message to the compiler to allow it to be used in ways similar to directly reading and writing data structures as binary in C. This is what makes it confusing.

    It may not be the case (see above) but this would make sense for resticting serialization to the same JVM. System.currentTimeMillis() is a better choice but the principle still stands. Consider a program that virtually never closes like a server. Some data may need to be stored for long periods of time to the file system or to a database (see Blob in jdbc) without being kept in active memory.

    All session data for example must be serializable so that it can be garbage collected between requests. A server may spend .0001% percent of its time servicing requests from a particular session so why keep its data around in main memory the rest of the time?

  • (cs)

    CAPTCHA: fkwitfkwitfkwiti'mafkwitwhotypes intheircaptchastringfkwitfkwit

  • AC (unregistered) in reply to brazzy
    brazzy:
    AC:
    This doesn't account for the fact the class itself could be garbage collected and then you couldn't even deserialize the object from within the same VM. It also doesn't allow a different ClassLoader's version of the class to be loaded within the same VM. Static isn't once per VM, it's once per class load.
    In most cases, the only ClassLoader that will be active is the bootstrap ClassLoader, and the classes it loads are never garbage collected.

    Hardly. Any web app run in a standard container will have multiple class loaders. And class GCing doesn't typically happen unless memory is scarce, but unless you start the JVM with the appropriate args, you can't count on the class not being cleaned up.

  • Synonymous Awkward (unregistered) in reply to Joe Blaim
    Joe Blaim:
    It may not be the case (see above) but this would make sense for resticting serialization to the same JVM. System.currentTimeMillis() is a better choice but the principle still stands. Consider a program that virtually never closes like a server. Some data may need to be stored for long periods of time to the file system or to a database (see Blob in jdbc) without being kept in active memory.

    A better idea would be to use some reproducible but distinct values for your instances, so that if they go down unexpectedly they don't lose anything they had written out. An even better idea would be to do it a completely different way, since serialVersionUID isn't made for that purpose.

    Still, I suppose it's an improvement over the guy who wanted to know how to alter the class' serialVersionUID at runtime to match that of the object he was trying to load so that it would "fix the loading failure".

  • surt (unregistered) in reply to Blaufish

    Replying to Blaufish: I'm definitely aware of the potential risk. I'm only using this in a context where there's no security issue (no escapeable strings, just basic structured data with very predictable structure processing).

    Really, as someone else pointed out, it's no different from any other data transmission mechanism: you must ensure that you either don't trust the data, or don't need to.

  • Cowbert (unregistered) in reply to Anonymous Coward
    Anonymous Coward:
    anjan bacchu:
    I did a google search to see how many google can find.

    http://www.google.com/codesearch?as_q=serialVersionUID.*compiler&btnG=Search+Code&hl=en&as_lang=java&as_license_restrict=i&as_license=&as_package=&as_filename=&as_case=

    That's nothing. Try this Codesearch on for size!

    http://www.google.com/codesearch?hl=en&lr=&q=serialVersionUID.*random+lang%3Ajava

    Incredibly, Howard's find isn't a one-off!

    What's really interesting is that JBoss used it in a DTO test case:

    in testsuite/src/main/org/jboss/test/scoped/interfaces/dto/SimpleResponseDTO.java from http://anonsvn.jboss.org/repos/jbossas/trunk -

    package org.jboss.test.scoped.interfaces.dto;

import java.io.Serializable;
import java.util.Random;

public class SimpleResponseDTO implements Serializable
{
   private static final long serialVersionUID = 1L;
//   private static final long serialVersionUID = new Random().nextLong();
  • segmentation fault (unregistered)

    java is probably the worst language known to man.

  • digdug (unregistered) in reply to BG
    BG:
    Steve:
    ... You'll find 
    private static final long serialVersionUID = 42L; // To shut up compiler
    in a lot of my classes which are never going to be serialized.

    Why are you making classes "implement Serializable" if they will never be Serialized...WTF.

    Your class might not be serializable, but its parent might be.

  • scooter (unregistered) in reply to Steve
    Steve:
    BG:
    Why are you making classes "implement Serializable" if they will never be Serialized...WTF.
    I'm not. I'm extending classes which implement Serializable, for instance, JPanel.

    If there's a better way of doing this, I'm all for hearing about it. I learned how to program in Java by buying the Flanagan book and reading the first three or four chapters, so I'm sure I missed something or another along the way. My first efforts weren't particularly pretty but I think I'm getting there. . .

    The times you need to extend JPanel must be tiny. I don't know about you but I don't create custom components all that often.
  • (cs) in reply to Steve
    Steve:
    BG:
    Why are you making classes "implement Serializable" if they will never be Serialized...WTF.
    I'm not. I'm extending classes which implement Serializable, for instance, JPanel.

    If there's a better way of doing this, I'm all for hearing about it. I learned how to program in Java by buying the Flanagan book and reading the first three or four chapters, so I'm sure I missed something or another along the way. My first efforts weren't particularly pretty but I think I'm getting there. . .

    Don't extend JPanel unless you're overriding one of the paint* methods.

    In general, you should not extend a class unless you need to. Subclass when you must, not whenever you can.

    I know most books contain examples that consist of extending Frame or JFrame or JPanel. Those books are wrong. (Printed Java material tends to contain a lot of inaccuracies....)

    What should you do instead? How about just making a JPanel and putting things in it? The JPanel you build should be a field in your class (which you may or may not wish to make available via a public get-method). Nothing more.

  • Dilbert (unregistered) in reply to MyAbacusHasAVirus

    WTF?*

    Dude, let the Operating System swap the program out do disk if it becomes idle for a long time. There shouldn't be a much of a need for a "Sleep Mode".

    The OS is there for a reason. If you look back at what DOS programs had to do on their own, you'll see why.

  • kblees (unregistered) in reply to Dilbert

    Unfortunately, todays operating system's virtual memory models are incompatible with garbage collected memory models. If your app needs more memory than is physically available, you need to do the swapping yourself (there are some caching frameworks around which can 'overflow to disk'). Otherwise, the first full garbage collection will effectively halt your machine.

    However, if the swapped data is private to the process / VM, you'd usually create and open the swap file exclusively. No need for random serialVersionUIDs.

  • Carrie (unregistered) in reply to fanguad
    fanguad:
    Steve:
    You'll find 
        private static final long serialVersionUID = 42L; // To shut up compiler
    in a lot of my classes which are never going to be serialized.

    Usually the compiler doesn't complain, but IDEs certainly do. I believe I've used that exact same comment before (although I'm usually slightly less creative with the arbitrary numbers I assign).

    If your IDE is Eclipse, it will generate one for you (choice of default or generated) if you hover over the highlighted part and select one of the options. It handily provides a Javadoc comment for you to write 'to shut up IDE/compiler' in, too.

    Eclipse is lovely. Especially ctrl+a ctrl+i. I just can't use that shortcut enough.

Leave a comment on “Serializalicious”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article