"Hello world!" without a public class?

Discussion in 'Java' started by Stefan Ram, Jan 6, 2013.

  1. Stefan Ram

    Stefan Ram Guest

    »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, Jan 6, 2013
    #1
    1. Advertising

  2. Stefan Ram

    Stefan Ram Guest

    -berlin.de (Stefan Ram) writes:
    >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, Jan 6, 2013
    #2
    1. Advertising

  3. Stefan Ram

    Stefan Ram Guest

    -berlin.de (Stefan Ram) writes:
    >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).
     
    Stefan Ram, Jan 6, 2013
    #3
  4. Stefan Ram

    Lew Guest

    Stefan Ram wrote:
    > »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.

    --
    Lew
     
    Lew, Jan 6, 2013
    #4

  5. > 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)
     
    Aryeh M. Friedman, Jan 6, 2013
    #5
  6. On 06.01.2013 09:44, Lew wrote:

    > 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

    --
    remember.guy do |as, often| as.you_can - without end
    http://blog.rubybestpractices.com/
     
    Robert Klemme, Jan 6, 2013
    #6
  7. On Sunday, January 6, 2013 8:09:45 AM UTC-5, 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,


    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, Jan 6, 2013
    #7
  8. Comments on entery point and teaching Java:
    <snip>

    > 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.
     
    Aryeh M. Friedman, Jan 6, 2013
    #8
  9. Stefan Ram

    Stefan Ram Guest

    "Chris Uppal" <-THIS.org> writes:
    >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, Jan 6, 2013
    #9
  10. Stefan Ram

    Stefan Ram Guest

    -berlin.de (Stefan Ram) writes:
    >, 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 ])); }}
     
    Stefan Ram, Jan 6, 2013
    #10
  11. Stefan Ram

    Arne Vajhøj Guest

    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/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, Jan 6, 2013
    #11
  12. Stefan Ram

    Arne Vajhøj Guest

    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
     
    Arne Vajhøj, Jan 6, 2013
    #12
  13. Stefan Ram

    Arne Vajhøj Guest

    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, Jan 6, 2013
    #13
  14. Stefan Ram

    Stefan Ram Guest

    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.
     
    Stefan Ram, Jan 6, 2013
    #14
  15. Stefan Ram

    Arne Vajhøj Guest

    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
     
    Arne Vajhøj, Jan 6, 2013
    #15
  16. Stefan Ram

    Lew Guest

    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
     
    Lew, Jan 6, 2013
    #16
  17. 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, Jan 6, 2013
    #17
  18. Stefan Ram

    Lew Guest

    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
     
    Lew, Jan 6, 2013
    #18
  19. 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
    }
    }
     
    Aryeh M. Friedman, Jan 6, 2013
    #19
  20. In article <-berlin.de>,
    -berlin.de (Stefan Ram) wrote:

    > »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.
    --
    I will not see posts from Google because I must filter them as spam
     
    Kevin McMurtrie, Jan 6, 2013
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Charles A. Lackman
    Replies:
    1
    Views:
    1,389
    smith
    Dec 8, 2004
  2. SpamProof
    Replies:
    0
    Views:
    592
    SpamProof
    Oct 21, 2003
  3. vijay
    Replies:
    8
    Views:
    722
  4. Roy
    Replies:
    6
    Views:
    634
    Roedy Green
    Jan 7, 2008
  5. Larry
    Replies:
    27
    Views:
    434
    Michele Dondi
    Jan 25, 2005
Loading...

Share This Page