Java Bean Static Memory

[kevin Abel]

I have never written or seen the inside of a Java Bean.  

I am communicating with a Java Developer and have  questions on a high level about a Java Bean.   I only know they are something like a container, object, class or something that can communicate through puts, gets, updates.  I imagine that it behaves as a class/object and maybe a bit like an API in the way that developers use it but don't all have the opportunity to see the source code for the abstract entity. That's all of my understanding of what it is.

What I want to know is  1) if the Bean can be written so that it can see variables outside of itself.   Perhaps in the calling class?  2) Can the Bean have a sticky variable that remembers something from the previous time it was called?  

Thanks,

Kevin

[Campbell Ritchie]

In its most basic form, a bean is an object with a no‑arguments constructor and getXXX() and setXXX() methods for each field. Any field can be used to remember information from a previous method call. What would you want to remember?
An object can only “see into” a calling object if that object passes information on to it; remember methods don't “know” where they were called from.

[kevin Abel]

Campbell,

Campbell wrote:In its most basic form, a bean is an object with a no‑arguments constructor and getXXX() and setXXX() methods for each field. Any field can be used to remember information from a previous method call. What would you want to remember?
An object can only “see into” a calling object if that object passes information on to it; remember methods don't “know” where they were called from.

I read this from two years ago and it got me thinking about classes in a different way.  It seems as if they have a lifetime.

The class gets instantiated and follows rules in its constructor class if it has one.
It lives in the heap.
On the stack there is a reference variable.
It is there but doesn't do anything. I'm  not sure about this part.  If I make a frog object can it do frog stuff like hopping while the rest of the code is performing other tasks?
I"ll call it an object now that it has been instantiated.
The object sees something calling it.  It looks for a match of object types and position. It uses the one that matches.
It does things.  It can remember things from the last time it was used.
I t will return values if the private, public grantors allow it.
When the method is done it might return a value to the calling line of code.
If all references to the object are  removed, they object will eventually get sent to garbage disposal.

I don't know if you are familiar with the Saturday Morning TV show called "School House Rock".   There was a catchy cartoon with funky music explaining the life of a USA Bill in Congress.   They showed the bill from the viewpoint of the Bill.  If I was better at music, Id write a song about the life of a Class.

Thanks,

Kevin

[Stephan van Hulst]

kevin Abel wrote:The class gets instantiated and follows rules in its constructor class if it has one.

Why do you keep saying "constructor class"? A constructor is a constructor, not a class. No thing called "constructor class" exists.

It lives in the heap.

Objects generally live on the heap, but not necessarily.

On the stack there is a reference variable.

Local variables live on the stack. It doesn't matter if they have a reference type or a primitive type.

Fields live wherever the object containing them live, which is generally on the heap, but in very special circumstances may also be on the stack.

If I make a frog object can it do frog stuff like hopping while the rest of the code is performing other tasks?

Objects do whatever you program them to do. But they only do it when a thread is executing your code. A thread can only execute one piece of code at a time. If you want two tasks to be executed concurrently, they need to be performed by different threads.

The object sees something calling it.

An object does no such thing. Instead, when a thread is executing a piece of code, and when that piece of code performs a method call on an object, the thread will push a stack frame - containing a reference to the object and the local variables of the method - onto the stack. Then it will start executing the code inside the method body. When the method returns, the stack frame is popped off the stack and the thread continues executing the code that made the method call.

Also, objects aren't called. Methods are.

It looks for a match of object types and position. It uses the one that matches.

I have no idea what you mean by this.

It can remember things from the last time it was used.

Methods don't remember anything. They just have a reference to the object they're called on. The object contains fields that retain their value during the lifetime of the object (or until you overwrite the value).

I t will return values if the private, public grantors allow it.

No. Access modifiers don't determine whether a method returns values. They determine who can call the method in the first place. This is usually checked at compile-time.

[kevin Abel]

Stephen,

Thank you for the corrections.   I don't know why I keep writing constructclass.   A constructor is a method.   Switching the words around to "class constructor" makes some more sense.   Maybe the class's constructor is even better.    

I understand what a constructor is and I use them and yet I keep saying it wrong.  

Thanks,

Keivn

[Campbell Ritchie]

kevin Abel wrote:Stephen

Do you mean Stephan?

. . . A constructor is a method.

No, it isn't. It behaves totally differently from a method.

 Switching the words around to "class constructor" makes some more sense.   Maybe the class's constructor is even better. . . .

Please say, “constructor,” full stop. A constructor belongs more to the object being created than to the class, but it has to be written in the class.

[Stephan van Hulst]

kevin Abel wrote:A constructor is a method.

No. A constructor is a constructor and a method is a method. Superficially they might seem similar, but they function differently and they achieve different things.

Switching the words around to "class constructor" makes some more sense.   Maybe the class's constructor is even better.

Yes, it makes more sense, but it's also redundant. Just say "constructor".

[edit]

Campbell beat me by a full 5 minutes.