"Hello world!" without a public class?

[Stefan Ram]

»class HelloWorldApp {
public static void main(String[] args) {
System.out.println("Hello World!"); // Display the string.
}
}
«

http://docs.oracle.com/javase/tutorial/getStarted/cupojava/win32.html

There is no »public« in front of »class« in Oracles Tutorial!

What should I teach in my classes?

1.) »public class HelloWorldApp« (because this is most common IIRC)

2.) »class HelloWorldApp« (because this is in Oracles tutorial)

3.) »final class HelloWorldApp« (because this class is not designed
for inheritance and Bloch says that one should not inherit from
it in this case and the students can as well get used to this
right from the start)

4.) »public final class HelloWorldApp« (combination of »1.)« and »3.)«)

 

[Stefan Ram]

1.) »public class HelloWorldApp« (because this is most common IIRC)

and because ...

I just observed an error message from a certain Java implementation
(not the JDK): »At least one public class is required«.

This is an implementation that does not use filenames for the
source code (such as »Main.java«), so it seems to depend on
»public« as a marker for the start class.

 

[Stefan Ram]

2.) »class HelloWorldApp« (because this is in Oracles tutorial)

and because ...

Students do not need to learn an additional rule, when
they start to write multiple classes into a single
source file. (While it might be good style to have
one class per file, it sometimes is convenient to
be able to write several classes into a single source file).

 

[Lew]

»class HelloWorldApp {
public static void main(String[] args) {
System.out.println("Hello World!"); // Display the string.
}
}
«

http://docs.oracle.com/javase/tutorial/getStarted/cupojava/win32.html

There is no »public« in front of »class« in Oracles Tutorial!

What should I teach in my classes?

Depends on the kinds of students you have, I should think.

There's pedagogical merit in teaching the good habits first and the
exceptional cases later. So you could begin with only 'public' classes
overall, let alone for the main one, mentioning briefly at first that
there is a way to drop the 'public' that you'll explain later.

As for 'final', that's harder. Hardly anyone in the field uses it,
myself included, because most classes basically aren't inherited so it's
not really risky to leave it out, and also there's a benefit to making
classes heritable for test purposes.

I think as a teacher I would use 'final' nearly always for classes, and
explain to the class (of students) that I'm being picky, but for good
reason. Also I'd mention that heritable classes support a certain style of
test code, and teach it once inheritance had been covered.

1.) »public class HelloWorldApp« (because this is most common IIRC)

First time you deal with class definition, show all these forms once.

2.) »class HelloWorldApp« (because this is in Oracles tutorial)

Mention that this rarely occurs in practice.

3.) »final class HelloWorldApp« (because this class is not designed
for inheritance and Bloch says that one should not inherit from
it in this case and the students can as well get used to this
right from the start)

package-private again - same brief mention.

4.) »public final class HelloWorldApp« (combination of »1.)« and »3.)«)

Go with this but explain that practice can differ.

Break the 'final' later when there is a pedagogical and good-code reason to..

Just off the top of my head - I haven't put nearly the thought into this that
you have.

 

[Aryeh M. Friedman]

1.) »public class HelloWorldApp« (because this is most common IIRC)

This the most common they are going to run into in real life and when you get in inheritance explain the difference between the 4 options. You should also point out (I know I will get flamed for this ;-)) that the only timeyou do not want to use "public" is in inner classes (which in my opinion should be outlawed anyways)

 

[Robert Klemme]

There's pedagogical merit in teaching the good habits first and the
exceptional cases later. So you could begin with only 'public' classes
overall, let alone for the main one, mentioning briefly at first that
there is a way to drop the 'public' that you'll explain later.
+1

As for 'final', that's harder. Hardly anyone in the field uses it,
myself included, because most classes basically aren't inherited so it's
not really risky to leave it out, and also there's a benefit to making
classes heritable for test purposes.

I use it rather frequently on the basis of whether I intend a class for
inheritance or not. It's easier to loosen a restriction later than the
other way round. Plus, it /might/ help the JVM optimize. But that's
really the smallest benefit and the most unimportant reason.

I think as a teacher I would use 'final' nearly always for classes, and
explain to the class (of students) that I'm being picky, but for good
reason. Also I'd mention that heritable classes support a certain style of
test code, and teach it once inheritance had been covered.

That's a bit contradictory, isn't it? I mean you say that almost nobody
uses it (including you, and also for good reasons) yet you would
recommend making it a habit to a beginner.

Kind regards

robert

 

[Aryeh M. Friedman]

Stefan Ram wrote:






I don't have a strong opinion on how the class should be declared, but I do

think -- and very strongly -- that the Java entry-point convention is a massive

kludge,

It makes sense for historical reasons (it was designed to model the Unix/C convention [likely a hold over before the JVM itself was created]).

FWIW: the examples in the JLS3 all use an default access class to house the

(specified to be required) public static void main(String args...) or public

static void main(String[] args) entry-point. The spec does not appear tocare

what access the class itself has (and there's no obvious reason -- technical or

semantic -- why it should). Does "private" work ? If so then using thatwould

be defensible.

And no *SANE* person would use the JLS to teach the language from! That being said private is allowed for inner classes but no where else I think

 

[Aryeh M. Friedman]

Comments on entery point and teaching Java:

It makes sense for historical reasons (it was designed to model the Unix/C convention [likely a hold over before the JVM itself was created]).

Even though I detest IDE's for actual professional use when I learned Java (to save money I decided to do it through the local community college sinceI already had a CS background) they used BlueJ and one feature it had really helped in this regard... the feature being that you where allowed in instantiate any class from the IDE directly and needed no wrapping classes/main/etc. this was of great benefit to the students who where in their first programming class, I did some tutoring of the newer students, (it did hinderthem slightly when they transferred to Sr. colleges but I think the trade off was worth it)... also note that Micheal Koling [author of BlueJ] has an companion text "Objects First" [I forget the full title] that is a very good graceful but complete introduction to Java/OO.

 

[Stefan Ram]

students if you made that very clear to them from the start (yes, there is a

I have no idea what you would prefer instead, but I just
made up this:

Rename »java.exe« (the JVM) to »new.exe« and modify the
interpretation of its command line arguments so that one can
write on the command line:

new Main().start()

, which will create a new object of the class »Main()« and
send the message »start()« to it (Java lingo: will invoke
the non-static message invocation »start()« with a new
object of class »Main« as the target object).

Of course, the JVM has to be rewritten for this. It does not
work with today's »java.exe«.

The general JVM syntax would become

"new"
<classname>
"("
<parameterlist>
")"
{ "."
<methodname>
"("
<parameterlist>
")"
}

, where the parameterlist might be empty and might contain
literals, instance creation expressions and method invocations
(a very small subset of Java, which can be implemented easily).

 

[Stefan Ram]

, where the parameterlist might be empty and might contain
literals, instance creation expressions and method invocations
(a very small subset of Java, which can be implemented easily).

Which also might open the world of amazing »Java one-liners«,
where JavaSE methods are invoked from the command line without
any actual user code to do something useful.

What we can do today is:

public class Main
{ public static void main( final java.lang.String[] args )
throws javax.script.ScriptException /* js.eval */
{ final javax.script.ScriptEngine js = new
javax.script.ScriptEngineManager().getEngineByName( "JavaScript" );
java.lang.System.out.println( js.eval( args[ 0 ])); }}

 

[Arne Vajhøj]

»class HelloWorldApp {
public static void main(String[] args) {
System.out.println("Hello World!"); // Display the string.
}
}
«

http://docs.oracle.com/javase/tutorial/getStarted/cupojava/win32.html

There is no »public« in front of »class« in Oracles Tutorial!

What should I teach in my classes?

1.) »public class HelloWorldApp« (because this is most common IIRC)

2.) »class HelloWorldApp« (because this is in Oracles tutorial)

3.) »final class HelloWorldApp« (because this class is not designed
for inheritance and Bloch says that one should not inherit from
it in this case and the students can as well get used to this
right from the start)

4.) »public final class HelloWorldApp« (combination of »1.)« and »3.)«)

#1

It is common.

It complies with one public class per file.

It makes logical sense that it is public because calling code
(the JVM) is not part of the package and there are really
no need to rely on the JVM being able to cheat.

The convention in practice is only to use final on classes
in special cases.

Arne

 

[Arne Vajhøj]

I don't have a strong opinion on how the class should be declared, but I do
think -- and very strongly -- that the Java entry-point convention is a massive
kludge, highly non-representative of how any sane OO code would be written, and
not at all an example to be followed.

It is obviously C/C++ inspired.

But I don't see it as being that bad.

Static makes perfectly sense in the context.

Obviously one could prefer the method name to be
specified to the JVM instead of having a magic value
"main".

But to me that is an uninteresting totally insignificant
issue.

Arne

 

[Arne Vajhøj]

Even though I detest IDE's for actual professional use when I learned
Java (to save money I decided to do it through the local community
college since I already had a CS background) they used BlueJ and one
feature it had really helped in this regard... the feature being that you
where allowed in instantiate any class from the IDE directly and needed
no wrapping classes/main/etc. this was of great benefit to the students
who where in their first programming class, I did some tutoring of the
newer students, (it did hinder them slightly when they transferred to Sr.
colleges but I think the trade off was worth it)... also note that
Micheal Koling [author of BlueJ] has an companion text "Objects First"
[I forget the full title] that is a very good graceful but complete
introduction to Java/OO.

If I were required to teach Java, then I would be very likely to use BlueJ, for
that and any many other reasons which collectively can be summed up as "you
can't teach a OO language properly without teaching OO properly".

I am highly skeptical about BlueJ.

I have seen so many new Java programmers learning BlueJ and then
not being able to do anything, because they did not understand
classpath, what is Java vs what is IDE etc..

To make a car analogy (!): they know how the engine and the brakes
works, but they don't know how to turn the ignition key or
actually turn the steering wheel.

Arne

 

[Stefan Ram]

I have seen so many new Java programmers learning BlueJ and then
not being able to do anything, because they did not understand
classpath, what is Java vs what is IDE etc..

The course announcement of my classes announce clearly that
the participants do not need to have programming knowledge
but need to know how to work with the operating system.

However, in reality often they do not know what the meaning
of the PATH environment variable is. Sometimes, they even do
not know how to create a text file, how to edit a text file,
how to use the clipboard to transfer text and so on. So I am
often forced to give a kind of Windows training, but since
the time for the whole beginner's Java course is very small
(about 18 hours), I hate to waste any time teaching Windows
instead of Java, which is also boring for those participants
who already know this.

So, in the next course I will try to use a Java online
compiler for the first steps. No need to setup any software
at all. Just paste or type the code into the web page and
press »compile«. The participants can do this from home, too.
No need for any preparation. One can start with Java
immediately, which is very good for a course announced as
a Java course, since that's what one is expecting from it.

Someone who has learned the language Java, but not the
meaning of the CLASSPATH environment variable, can learn the
meaning of the CLASSPATH environment variable whenever he
needs it for the first time. Not learning it right from the
start does not impede learning it anytime later.

 

[Arne Vajhøj]

The course announcement of my classes announce clearly that
the participants do not need to have programming knowledge
but need to know how to work with the operating system.

However, in reality often they do not know what the meaning
of the PATH environment variable is. Sometimes, they even do
not know how to create a text file, how to edit a text file,
how to use the clipboard to transfer text and so on. So I am
often forced to give a kind of Windows training, but since
the time for the whole beginner's Java course is very small
(about 18 hours), I hate to waste any time teaching Windows
instead of Java, which is also boring for those participants
who already know this.

So, in the next course I will try to use a Java online
compiler for the first steps. No need to setup any software
at all. Just paste or type the code into the web page and
press »compile«. The participants can do this from home, too.
No need for any preparation. One can start with Java
immediately, which is very good for a course announced as
a Java course, since that's what one is expecting from it.

Someone who has learned the language Java, but not the
meaning of the CLASSPATH environment variable, can learn the
meaning of the CLASSPATH environment variable whenever he
needs it for the first time. Not learning it right from the
start does not impede learning it anytime later.

In theory you are absolutely right.

Getting a good start on OO should be the focus and not the
trivial stuff of getting external jar files added to classpath.

But my practical experience from various help forums is that many
of those BlueJ users never learn the practical stuff and instead
give up on Java.

In that regard it is very similar to those learning PHP and
MySQL by installing one of the popular XAMP packages. They are
up and running in 5 minutes. But when they run into something that
require them to change httpd.conf or php.ini then half of them
give up.

There are obviously caveats:
1) I only know about success rate among those that encounter
problems - I have no way of knowing about how many that do
encounter problems
2) Making is difficult should not be taken too far - having
everybody writing Ada95 code using COPY CON: Foobar.ada
would certainly not be good

If I were to teach Java for an entire semester, then I would
do the first month with a standard editor and command line
build and run to learn them how things work and then switch them
to a standard Java IDE after that (I like Eclipse, but NetBeans
and IntelliJ would certainly do as well) - sure the options
can be a bit scary, but they are on a path they can continue
on and if they need help, then it is a hell lot easier to
get it for Eclipse/NetBeans than for BlueJ.

Arne

 

[Lew]

This the most common they are going to run into in real life and when youget in inheritance explain the difference between the 4 options. You should also point out (I know I will get flamed for this ;-)) that the only time you do not want to use "public" is in inner classes (which in my opinionshould be outlawed anyways)

Do you really mean just inner classes? Would you ban all nested classes
outright?

It would be a very, very boneheaded thing to outlaw inner classes.
You'd destroy a common idiom for declaring listeners. You'd make lambdas
impossible. You'd kill one of the most expressive features of Java, that
was introduced to the language in the first place because of its great
power.

You are aware that nested classes were added to Java, not there from the
beginning, yes? There were excellent reasons to do that.

Study the matter.

 

[Aryeh M. Friedman]

Do you really mean just inner classes? Would you ban all nested classes

outright?



It would be a very, very boneheaded thing to outlaw inner classes.

You'd destroy a common idiom for declaring listeners. You'd make lambdas

impossible. You'd kill one of the most expressive features of Java, that

was introduced to the language in the first place because of its great

power.

And get rid of one the most unreadable/widely abused parts of all Java code? Sounds good to me... almost everything done with inner/nested classes can be done cleaner with post 1.5 constructs that do not require impossible to read code.

 

[Lew]

Well?




And get rid of one the most unreadable/widely abused parts of all Java code?

Conclusion not in evidence.

Sounds good to me... almost everything done with inner/nested classes can be

Which, inner or non-inner nested?

done cleaner with post 1.5 constructs that do not require impossible to read code.

Show the idioms you have in mind. Show how nested classes are "impossible to
read". They aren't. Unless you don't know Java, in which case don't bother
arguing about how to improve it. Show that what you have in mind is easier to
read. Show how you'd do lambdas without them. For God's sake, provide some
evidence and logic for your point.

Otherwise it's just your personal, non-engineering-based and utterly irrelevant
opinion.

 

[Aryeh M. Friedman]

On inner classes:

First of all anytime I see more then one class in a .java file I tend to lump them together (i.e. make no distinction between nested and inner). Now that being said here is a good example of something that is easier to read then either (yes it does get compiled into something very close to inner classes [not nested if I remember the jargon correctly] but no where near as ugly):

Foo.java:

public enum Foo
{
ACK {
public void doSomething(SomeClass arg)
{
do what ever for ACK
}
},
BAR {
public void doSomething(SomeClass arg)
{
do what ever for BAR
}
}
}

Fred.java:

public class Fred
{
public void someMethod()
{
SomeClass sc=new SomeClass(...);
Foo[] arr=new Foo[]{ACK,BAR}; // typing this for this example sobeing lazy on syntax

for(Foo elem:arr)
elem.doSomething(sc);
}
}

and voila much more readable then putting a whole rats nest of stuff in theinitialization of arr
}
}

 

[Kevin McMurtrie]

»class HelloWorldApp {
public static void main(String[] args) {
System.out.println("Hello World!"); // Display the string.
}
}
«

http://docs.oracle.com/javase/tutorial/getStarted/cupojava/win32.html

There is no »public« in front of »class« in Oracles Tutorial!

What should I teach in my classes?

1.) »public class HelloWorldApp« (because this is most common IIRC)

2.) »class HelloWorldApp« (because this is in Oracles tutorial)

3.) »final class HelloWorldApp« (because this class is not designed
for inheritance and Bloch says that one should not inherit from
it in this case and the students can as well get used to this
right from the start)

4.) »public final class HelloWorldApp« (combination of »1.)« and »3.)«)

'final' classes are useful for:

1) Safety. Not all classes can be subclassed safely. For example, a
subclass of Thread that starts itself from the constructor may be
executing the run() method before a subclass' constructor completes.
Another case would be data for which the equals() method can not be
generalized. Marking the class as final forces compile-time safety
against accidentally subclassing something that isn't ready for it.

2) Security. Imagine the damage you could do if String was mutable.
You wouldn't want a credit card encryptor/decryptor to gain any extra
features because a mistake could cost millions of dollars.

3) Performance. Methods known to have a single implementation can be
highly optimized by the JIT. This optimization must be removed as soon
as it's possible for there to be more than one implementation. This is
an awful side-effect that's difficult to trace. Classes requiring
maximum performance should be guarded from subclassing.


So for "Hello World" the 'final' modifier isn't much use. You could
argue that demonstration code should not be subclassed (#1 above), but
maybe somebody wants to make another demo.