Exactly what it means probably varies a bit from language to language. In C, which is the main language I'd associate with structs, a struct is a type that has fields made up of other types. It's similar to a class in that respect, but it doesn't have methods or the idea of private state.
Saif Asif wrote:What is the difference between a structure and a class ? Also specify where and when would you use a structure instead of a class
I wonder if you're confusing "structure" and struct, which is a keyword used in C and C++.
If so, the basic difference is: methods. A Java class binds data, constructors and methods.
However, you will almost never hear the term "structure" used in that context in Java, because there is no such thing as a struct in Java.
Saif Asif wrote:I agree , but what about the idea of actually coding a structure implementation in Java via class . Would that be feasible ? As far as the possibility is concerned , I dont think we would we able to get a 100% implementation of a strucuture in Java
And why would you want one? A Java class is more that a struct will ever be, so why would you want an inferior construct simply because it exists in another language?
Saif Asif wrote:Well at the moment, the things coming to my mind are ...
Like Matthew, other than (possibly) being stack-based, I don't see what any of the other things buy you (and in fact most of them don't apply to C structs anyway): memory is cheap, mutability is up to you, CRUD wouldn't appear to be an issue since you don't want it to be updatable anyway, and you're not supposed to be worried about memory - that's the JVM's job. Not to mention how some of the Java keywords would apply:
for example: what would a volatile struct mean?
Saif Asif wrote:Well at the moment, the things coming to my mind are
having a light data type that resides in the stack will not be changed after its creation since it resides in stack , then relatively faster CRUD operations on it prevent casting
1. In Java, objects (instances of classes) are always created on the heap, and not on the stack*. There is no way to create an object-like thing on the stack explicitly.
2. You can make your classes immutable, and very often it's a good idea to do so.
3. The JVM is very good at optimizing code. One of the things it does is inlining. Calling a getter or setter on an object is most of the time just as cheap as accessing the field directly.
4. There's no way you can prevent casting.
* except in special circumstances, when the JVM does escape analysis - a sophisticated optimization technique.
It sounds like you have a C++ mindset, where you're worrying about low-level optimization of your code. In Java, you normally don't need to think about these things. The JVM does a lot of sophisticated optimization for you to make your code run fast.