«

On 1/6/2013 3:20 AM, Stefan Ram wrote:
> »class HelloWorldApp {
> public static void main(String[] args) {
> System.out.println("Hello World!"); // Display the string.
> }
> }
> «
>
> http://docs.oracle.com/javase/tutori...ava/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

On 1/6/2013 8:09 AM, Chris Uppal wrote:
> Stefan Ram wrote:
>
>> There is no »public« in front of »class« in Oracles Tutorial!
>>
>> What should I teach in my classes?
>
> 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

On 1/6/2013 8:44 AM, Chris Uppal wrote:
> Aryeh M. Friedman wrote:
>> 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

Arne Vajhøj <> writes:
>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.

On 1/6/2013 11:14 AM, Stefan Ram wrote:
> Arne Vajhøj <> writes:
>> 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.

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

Aryeh M. Friedman wrote:
>> 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 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.

--
Lew

On Sunday, January 6, 2013 12:43:53 PM UTC-5, Lew wrote:
> Aryeh M. Friedman wrote:
>
> >> 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 time you do not want to use "public" is in inner classes (which in my opinion should 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.

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.

Aryeh M. Friedman wrote:
> Lew wrote:
>> Aryeh M. Friedman wrote:
>>>> 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 time you do not want to use "public" is in inner classes (which in my opinion should be outlawed anyways)
>
>> Do you really mean just inner classes?

Well?

>> 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?

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.

--
Lew

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
}
}

In article <public->,
(Stefan Ram) wrote:

> »class HelloWorldApp {
> public static void main(String[] args) {
> System.out.println("Hello World!"); // Display the string.
> }
> }
> «
>
> http://docs.oracle.com/javase/tutori...ava/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.
--
I will not see posts from Google because I must filter them as spam