System.out.println();

[lsrinu]

who will create the object out for the System class, where we find the
method println();

 

[John]

Its a built in class file so I would assume its created on JVM startup.
that and/or its a static class that doesn't to instanciated. Your
question is a little bit ambiguous.

 

[lakshmi2510]

Read this and you will know :
http://www.javaworld.com/javaworld/jw-10-1996/jw-10-indepth.html

 

[Chris Uppal]

who will create the object out for the System class, where we find the
method println();

I'm not sure if this is actually answering your question, but still....

There's is no object which has the println() method. That method (like all the
methods of java.lang.System) is static, which means that the method is part of
the class, but is not attatched to any specific instance of that class.

So you call it by using the name of the class rather then via some object:

java.lang.System.println("whatever");


-- chris

 

[Bjorn Abelli]

...

I'm not sure if this is actually answering your question, but still....

There's is no object which has the println() method.

There sure is...

That method (like all the methods of java.lang.System) is
static, which means that the method is part of
the class, but is not attatched to any specific
instance of that class.

I'm not sure what version of the Java libraries you have, but in my version
at least System's static member out is an instance of PrintStream

So you call it by using the name of the class rather
then via some object:

java.lang.System.println("whatever");

Again, in what version of the Java libraries can you do that?

I have always used the PrintStream object out in the System class:

java.lang.System.out.println("whatever");
--------------------^

As John hinted, the System.out object is instantiated at startup of the JVM.

Immediately at startup, "out" is set to null, but as soon as the JVM has
initialized the thread, it calls some private native methods to instantiate
the object.

// Bjorn A



Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php

 

[Chris Uppal]

Bjorn Abelli wrote:

[me:]

There sure is...

Yes, you are right. Careless of me.

I was responding to what I thought was the OP's underlying issue -- where do
the static methods of java.lang.System live ? -- and missed the fact that this
particular method isn't part of System at all. If you replace
System.out.println() by, say, System.currentTimeMillis() throughout the OP's
question and my reply, then you'll get the question that I /thought/ I was
responding to, plus a (correct this time) response.

Apologies for the confusion.

-- chris

 

[Dale King]

Immediately at startup, "out" is set to null, but as soon as the JVM has
initialized the thread, it calls some private native methods to instantiate
the object.

Tangential to the question, but I was looking at the code in Java 1.5
and it is more bizarre than that.

When the System class is loaded out, in, and err are set to the result
of method calls like the following:

private static PrintStream nullPrintStream() throws NullPointerException
{
if (currentTimeMillis() > 0)
return null;
throw new NullPointerException();
}

What is the check of currentTimeMillis for? Well according to the
comments in the code it is in there to prevent the compiler from
inlining access to them.

There is a static method initializeSystemClass which is the one that
actually sets them to wrappers around FileInputStream or
FileOutputStream. It does use native calls to actually do the setting.
Probably because it needs to coordinate with native code that can also
print messages.

 

[Thomas Hawtin]

There is a static method initializeSystemClass which is the one that
actually sets them to wrappers around FileInputStream or
FileOutputStream. It does use native calls to actually do the setting.
Probably because it needs to coordinate with native code that can also
print messages.

It uses native methods because those statics are final (they weren't in
1.00). The Java Memory Model has to make an exception for
System.in/out/err. The should have been methods. 1.1 should probably
have made them proxies, so setIn/setOut/setErr could have worked in a
sensible fashion.

Tom Hawtin

 

[Dale King]

It uses native methods because those statics are final (they weren't in
1.00). The Java Memory Model has to make an exception for
System.in/out/err. The should have been methods. 1.1 should probably
have made them proxies, so setIn/setOut/setErr could have worked in a
sensible fashion.

Ah! Now I understand. Once again goes to show how it is a bad idea to
expose raw fields. They exposed them as raw fields and then by the time
1.1 came about they realized that was a security hole to let arbitrary
code redirect them without checking permissions. But they were stuck
with exposing them as fields. So they had to do this hack. They had to
use the methods for the initial value to prevent the compiler from
treating them as compile time constants and inlining them.

It might have been nice if they did something like .NET did with
properties where you can access them using field-like syntax but have it
actually use methods.

 

[Thomas Hawtin]

It might have been nice if they did something like .NET did with
properties where you can access them using field-like syntax but have it
actually use methods.

As I understand it, .NET makes that approach useless. Switching from a
field to a property will break binary compatibility. So you still need
to make sure all your fields are private.

Tom Hawtin

 

[Dale King]

As I understand it, .NET makes that approach useless. Switching from a
field to a property will break binary compatibility. So you still need
to make sure all your fields are private.

Yes, I have heard that too, but I wasn't assuming that it would
necessarily have the same limitation. One could devise a mechanism
whereby you did not lose binary compatibility by changing between the two.

Unfortunately, it would lose binary compatibility with the current
implementation. That is why we have get/set methods instead of a more
complete solution for properties.