<P> In the context of static (compile - time) type systems, type safety usually involves (among other things) a guarantee that the eventual value of any expression will be a legitimate member of that expression's static type . The precise requirement is more subtle than this--see, for example, subtype and polymorphism for complications . </P> <P> Type safety is closely linked to memory safety, a restriction on the ability to copy arbitrary bit patterns from one memory location to another . For instance, in an implementation of a language that has some type t (\ displaystyle t), such that some sequence of bits (of the appropriate length) does not represent a legitimate member of t (\ displaystyle t), if that language allows data to be copied into a variable of type t (\ displaystyle t), then it is not type - safe because such an operation might assign a non - t (\ displaystyle t) value to that variable . Conversely, if the language is type - unsafe to the extent of allowing an arbitrary integer to be used as a pointer, then it is not memory - safe . </P> <P> Most statically typed languages provide a degree of type safety that is strictly stronger than memory safety, because their type systems enforce the proper use of abstract data types defined by programmers even when this is not strictly necessary for memory safety or for the prevention of any kind of catastrophic failure . </P> <P> Type - safe code accesses only the memory locations it is authorized to access . (For this discussion, type safety specifically refers to memory type safety and should not be confused with type safety in a broader respect .) For example, type - safe code cannot read values from another object's private fields . </P>

What is meant by type safe in java