Re: Java Memory question
Eric wrote:
Nigel Wade wrote:
Eric wrote:
2. What I call 'native' Java is quite different than the Java
technical term. I considered a byte to be a 'native' variable type,
This is Java. Use the right terminology. Don't use incorrect
terminology. Especially don't insist on using incorrect terminology
and argue about it. You're wrong. Fix it.
We've already told you on several occasions. They are primitive types.
'Native' has explicit meaning in Java, it relates to non-Java code
executed by the JVM. Don't call primitive types 'native', people will
not understand you.
We've already established that. I was explaining my intent, to
describe Java code which is already there, which is in the Java
installation which doesn't require custom classes/jars. I'd
appreciate if you want to be helpful and provide a better word for
it. I don't need you repeating what someone else just said.
Yes, you clearly do, because not only have you not fixed your mistake,
now you're arguing about it. Just fix your dang mistake, for Pete's
sake!
Get over yourself. There's no crime in being wrong. There sure is
one in being stubborn about it and refusing to correct your error.
Did I say it's a constant value? I said it gets the same value every
time. This means variables which need to be initialized, which may
take multiple statements and/or depend on other values but always come
out the same.
In other words, it has a constant value, just as you said.
Why would anyone keep a variable hanging around "for no good reason"?
You tell us. You're the one suggesting to do such a thing.
The main reasons I had for making an instance variable instead of a
method variable were 1. To reduce lines of code and 2. To reduce
processing time if the create may take a while. If that's not clear
enough, review this specific example clip.
As many have pointed out here, those are fallacious reasons. It does
no good to reduce lines of code by introducing bugs, and the amount of
time to allocate an object is nearly nil, far less than the
inefficiencies caused by promoting objects to the tenured generation
unnecessarily. Please take the advice we're offering. You came to us
for help but you're rejecting every answer you're getting. That'd be
one thing if you were right and we were wrong, but it's exactly the
other way around.
So it uses the same object variable many times within the class for
the same purpose with different values.
It may be fewer lines of code to put the "JMenu " on each line in
front of "menu = new" though it is more characters after a few uses.
What, are you afraid you'll sprain a finger typing Ctrl-V?
It's no win to create bugs and save typing.
Is performance any different to create an object in one statement
(JMenu menu = new JMenu("Title");) or two (Jmenu menu; menu = new
JMenu("Title"))?
Performance, no. Semantics, yes.
Why are you worried about performance? Have you measured a
bottleneck?
If performance is the same I prefer to use 2 statements and put all
the declares (JMenu menu;) at the beginning of the method (which can
look like a lot of duplication), or to define them as instance
variables if it makes sense to do so.
Performance is less important than semantics. Focus on the latter,
not the former, especially at your stage of knowledge.
To the one who misinterpreted my statement "I don't believe cloning
can copy a reference."
The reason anyone misinterprets what you are saying is because you keep
inventing your own terminology which is in conflict with the terminology
used in Java.
I apologize if the technical words are not correct. I work with
Apologies are meaningless without any commitment to correct the
error. Fix your mistakes.
several languages at once and it's my job to write working efficient
maintainable code, not to study program theory and technical terms. I
Then you must really suck at your job. If you don't know what you're
doing, you'll screw things up. Your refusal to study means you will
be really bad at your job.
did that in college over a decade ago. Terminology changes with each
And we all know that computer technology doesn't change in over a
decade, so why bother to keep up? Just get all snarky with folks who
try to help you, then cop a stupid ego attitude about, "I learned this
a decade ago and I now never ever need to learn anything else ever
again!"
Real useful approach, that.
language. I try to explain what I write when I think there may be
some confusion. If you still don't understand what I write you are
free to ask for clarification or simply not respond.
But you flat-out refuse to play nice with those who know what they're
talking about, or to accept the corrections freely offered.
We're getting nothing from you but deliberate ignorance, obstinacy and
ridiculous rationalizations.
Are you following the thread? I did say just that. I wrote this
message you responded to in order to clarify. If you don't understand
that just ask. Don't tell me what I didn't say. I'm not sure what
your intent is in writing this but please try to be inquisitive or
helpful like most here have been.
Man, you sure are one snarky SOB! Chill out, man! Yeesh!
You really need an attitude adjustment. You waltz in here, presuming
on our good will to voluntarily help you, then *completely* disregard
everyone's advice, then act like a total ass about it. Your behavior
is shameful.
"The point of copying the array is that I can't create the new object
as a reference to the same memory, because the copy is a cloned
object
on a different machine through a webstart."
When variables are sent between a server and a client they will be
serialized to the stream, not cloned. An entirely different operation,
carried out by different methods.
Serializing is cloning. If you want to pick at terminology, you're
No, it is not. Now you're just being obstinate.
Use the correct terminology.
wrong too. Cloning is creating a copy of an object. You may think o=
f
it as creating a new object which must exist in the same JVM, perhaps
as simple as "Object a = b.clone();". I'm essentially doing the same
thing but the copy needs to be created on the other machine. The
The term for that is "serialization".
custom API I'm calling to do that uses cloneAsClientObject() for the
method name. If you want to get technical, when you serialize an
object to a stream it doesn't go anywhere. If that stream is on the
server and a stream on the client is connected to it, you might be
sending it 'to' the client but not 'between' the server and client.
Wacky. Of coursae it's "between" them. Going from one to the other
is what "between" means.
Now you're not even using standard English correctly. It was bad
enough that you refused to use the correct Java terms, but can't you
even use correct natural-language terms?
You forgot to mention the client must deserialize the object. This
creates a COPY (or clone) of the object. Call it what you want but
you missed the point. The point was I got an OOME on the previously
mentioned cloning process, which as we've established was likely
caused by the JNLP memory setting.
No, it is not "likely" caused by that, but by some bug in your code.
Given what you've been saying about object scope and lifetime, it's
likely that you fail to release objects to the garbage collector. If
so, no increase in your memory allocation will save you. You'll use
up any amount you allocate until you fix your bugs.
While it may
be possible for an object to simply be a reference to another object,
It isn't. You still appear to be exhibiting a misunderstanding of the
difference between a reference variable and the object to which a
reference variable refers. A reference variable holds a reference to an
object. Any number of reference variables can refer to the same object.
An object may contain reference variables which refer to other objects.
An object cannot reference another object, other than it contains a
reference variable which refers to that other object.
SomeObject a;
defines a reference variable.
A reference to what? It appears you're just declaring what type that
variable refers to.
A reference to a 'SomeObject' instance or to 'null'.
You should read the Java tutorials. You need to know at least the
fundamentals of Java to make any progress at all with what you're
trying to do.
a = new SomeObject();
creates a new SomeObject and sets the reference variable "a" to point t=
o
the created object.
SomeObject b = a;
creates a new reference variable b, which also points to the same
instance of SomeObject.
That's an object which is a reference to another object. That's what
I just said. You said no.
No, that's not at all what that is. You're wrong. 'a' is not an
object; 'b' is not an object. The object is the thing to which both
'a' and 'b' point.
a = null;
does nothing. b still points to the object so it's not available for GC=
..
b = null;
does nothing per se, but in this example does remove the last reference
to the object so that at some time later GC may release the object. At
this point in time there is no way to reference the object, or access
any of its content.
That is what I initially suggested and the response was 1. b still
keeps the memory from GC if defined as an instance variable. 2. That
Not if 'b' is pointed to 'null', no.
is done implicitly on exiting a method if the object was declared in
the method (and GC won't clear it's [sic] memory before the method
completes).
Not true. GC will kick in before the method completes if it wants
to. Many of the objects referenced in the method might be collected
before the method exits.
I wouldn't think the other object could exist on a different machine.
It can't. You cannot refer to an object on another machine, or within
another JVM on the same machine. You can transfer a copy of an object b=
y
serializing it at the sending end and de-serializing it at the receivin=
g
end.
That's what I said. I'm copying an object from a server to a client.
That copy must be a clone, not a reference. The clone is created
through the ObjectOutputStream.
No, it's not a clone. "Clone" has a particular meaning in Java that
does not apply to that scenario.
When in Rome, speak Italian.
--
Lew