I saw a challenge Roedy posted on cljh, and I thought I might have a 
slightly more interesting one.

Write a Java program which outputs "Hello World" followed by a new line 
(and nothing else).

Now, do it using as few characters in the .java source code as possible.

I've got mine down to 61 characters. See if you can match that.

On 6/13/12 1:45 PM, Daniel Pitts wrote:
> I saw a challenge Roedy posted on cljh, and I thought I might have a
> slightly more interesting one.
>
> Write a Java program which outputs "Hello World" followed by a new line
> (and nothing else).
>
> Now, do it using as few characters in the .java source code as possible.
>
> I've got mine down to 61 characters. See if you can match that.

Hint, the following is 82 characters, if you remove line wrapping. Where 
do I trim the 21 characters?

"class M{public static void main(String[]args){System.out.println("Hello 
World");}}"

Daniel Pitts <newsgroup.nospam@virtualinfinity.net> writes:
>>Write a Java program which outputs "Hello World" followed by a new line
(...)
>"class M{public static void main(String[]args){System.out.println("Hello World");}}"

  �System.out.println("Hello World");� does not output "Hello
  World" followed by a new line, but "Hello World" followed by
  the line separator string. The line separator string is
  defined by the system property line.separator, and is not
  necessarily a single newline character ('\n').

Daniel Pitts <newsgroup.nospam@virtualinfinity.net> writes:
>Where do I trim the 21 characters?

  You can trim the �args� to �a�. Possibly, some earlier JDKs allowed
  omission of the main method, but a recent JDK seems to require it.

On 6/13/12 2:06 PM, Stefan Ram wrote:
> Daniel Pitts<newsgroup.nospam@virtualinfinity.net>  writes:
>>> Write a Java program which outputs "Hello World" followed by a new line
> (...)
>> "class M{public static void main(String[]args){System.out.println("Hello World");}}"
>
>    �System.out.println("Hello World");� does not output "Hello
>    World" followed by a new line, but "Hello World" followed by
>    the line separator string. The line separator string is
>    defined by the system property line.separator, and is not
>    necessarily a single newline character ('\n').
>
I didn't say a "new line" character. However, print("Hello World\n") is 
the same length.  My intent was line separator, however if you choose to 
interpret it the other way, there is no benefit or penalty.

On 6/13/12 2:29 PM, Stefan Ram wrote:
> Daniel Pitts<newsgroup.nospam@virtualinfinity.net>  writes:
>> Where do I trim the 21 characters?
>
>    You can trim the �args� to �a�.
Ah, yes. That was just habit on my part.

> Possibly, some earlier JDKs allowed
>    omission of the main method, but a recent JDK seems to require it.
>

The JDK doesn't require anything of a class.  java on the other hand 
goes through a specific sequence when asked to "run" a Java program.

My smallest program is still 61 characters long, the example I posted, 
after replacing args with a, is 79.

On 6/13/12 4:19 PM, Daniel Pitts wrote:
> On 6/13/12 2:29 PM, Stefan Ram wrote:
>> Daniel Pitts<newsgroup.nospam@virtualinfinity.net> writes:
>>> Where do I trim the 21 characters?
>>
>> You can trim the �args� to �a�.
> Ah, yes. That was just habit on my part.
>
>> Possibly, some earlier JDKs allowed
>> omission of the main method, but a recent JDK seems to require it.
>>
>
> The JDK doesn't require anything of a class. java on the other hand goes
> through a specific sequence when asked to "run" a Java program.
Ah, although now I see reports that Java 7 does some validation before 
some of that sequence.  So, my 61 character source compiles fine, but 
won't run on Java 7.

I wonder why they bothered.

Daniel Pitts <newsgroup.nospam@virtualinfinity.net> wrote:

(snip)
> I didn't say a "new line" character. However, print("Hello World\n") is 
> the same length.  My intent was line separator, however if you choose to 
> interpret it the other way, there is no benefit or penalty.

Note that there is no requirement that the host system even use
a newline character. There are systems that keep track of lines
by length. 

Now, the C tradition of using '\n' as a line terminator, even
on systems that don't store files that way, isn't completely gone
in Java. Writing a "\n" will likely generate a new line even on
systems that don't use a newline character.

-- glen

On 6/13/2012 1:52 PM, Daniel Pitts wrote:
> On 6/13/12 1:45 PM, Daniel Pitts wrote:
>> I saw a challenge Roedy posted on cljh, and I thought I might have a
>> slightly more interesting one.
>>
>> Write a Java program which outputs "Hello World" followed by a new line
>> (and nothing else).
>>
>> Now, do it using as few characters in the .java source code as possible.
>>
>> I've got mine down to 61 characters. See if you can match that.
>
> Hint, the following is 82 characters, if you remove line wrapping. Where
> do I trim the 21 characters?
>
> "class M{public static void main(String[]args){System.out.println("Hello
> World");}}"


This is a good one, although the options for really trimming things down 
in surprising ways is absent in Java.

Another good one is to write a Java program that prints its own source 
text.  No fair using an external file, of course.

On 13/06/2012 4:45 PM, Daniel Pitts wrote:
> I saw a challenge Roedy posted on cljh, and I thought I might have a
> slightly more interesting one.
>
> Write a Java program which outputs "Hello World" followed by a new line
> (and nothing else).
>
> Now, do it using as few characters in the .java source code as possible.
>
> I've got mine down to 61 characters. See if you can match that.

class X{static{System.out.println("Hello World");for(;;);}}

is 59 characters.

Hey, you didn't say it has to actually *terminate*! ;)

-- 
public final class JSnarker
extends JComponent
A JSnarker is an NNTP-aware component that asynchronously provides 
snarky output when the Ego.needsPuncturing() event is fired in cljp.

On Wed, 13 Jun 2012 13:45:18 -0700, Daniel Pitts
<newsgroup.nospam@virtualinfinity.net> wrote, quoted or indirectly
quoted someone who said :

>
>I've got mine down to 61 characters. See if you can match that.

 here's the obvious solution at 88 chars: 

public class C{public static void main(String[]
a){System.out.println("Hello World");}}

-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Controlling complexity is the essence of computer programming.
~ Brian W. Kernighan 1942-01-01
..

On Jun 13, 9:45=A0pm, Daniel Pitts
<newsgroup.nos...@virtualinfinity.net> wrote:
> I saw a challenge Roedy posted on cljh, and I thought I might have a
> slightly more interesting one.
>
> Write a Java program which outputs "Hello World" followed by a new line
> (and nothing else).
>
> Now, do it using as few characters in the .java source code as possible.
>
> I've got mine down to 61 characters. See if you can match that.

You may also find some of the challenges on http://codegolf.stackexchange.c=
om/
interesting.

On 2012-06-13, Daniel Pitts <newsgroup.nospam@virtualinfinity.net> wrote:
> I saw a challenge Roedy posted on cljh, and I thought I might have a 
> slightly more interesting one.
>
> Write a Java program which outputs "Hello World" followed by a new line 
> (and nothing else).
>
> Now, do it using as few characters in the .java source code as possible.

How much are you permitted to offload to the launcher?

Trivial example of offloading:

class A{public static void main(String[] a){System.out.print(a[0]);}}
(69 chars)

with launch instructions:

run like this (bash command line example shown, other launch
environments will have other ways of expressing the newline)

$ java A "Hello World
> "
$ 


And how much can you offload to a hypothetical "library" function that
just happens to do exactly what you want?

class B{public static void main(String[] a){L.f();}}
(52 chars)

Cheers,

Bent.
-- 
Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
                                    powered by emacs

"Roedy Green" <see_website@mindprod.com.invalid> wrote in message 
news:jqnit7pv9phoig3t2il0s4jf4s19ot7p3i@4ax.com...
> On Wed, 13 Jun 2012 13:45:18 -0700, Daniel Pitts
> <newsgroup.nospam@virtualinfinity.net> wrote, quoted or indirectly
> quoted someone who said :
>
>>
>>I've got mine down to 61 characters. See if you can match that.
>
> here's the obvious solution at 88 chars:
>
> public class C{public static void main(String[]
> a){System.out.println("Hello World");}}

No need for public on class.

-- Hiram Hunt (hiramhunt@verizon.net) 

"Hiram Hunt" <hiramhunt@verizon.net> wrote in message 
news:4fd9d7d1$0$1727$c3e8da3$aae71a0a@news.astraweb.com...
>
> "Roedy Green" <see_website@mindprod.com.invalid> wrote in message 
> news:jqnit7pv9phoig3t2il0s4jf4s19ot7p3i@4ax.com...
>> On Wed, 13 Jun 2012 13:45:18 -0700, Daniel Pitts
>> <newsgroup.nospam@virtualinfinity.net> wrote, quoted or indirectly
>> quoted someone who said :
>>
>>>
>>>I've got mine down to 61 characters. See if you can match that.
>>
>> here's the obvious solution at 88 chars:
>>
>> public class C{public static void main(String[]
>> a){System.out.println("Hello World");}}
>
> No need for public on class.
>
> -- Hiram Hunt (hiramhunt@verizon.net)

Sorry,  I think I missed your point that this was just the obvious
solution.  Other posts are already public-less on class.

-- Hiram Hunt (hiramhunt@verizon.net) 

Bent C Dalager <bcd@pvv.ntnu.no> writes:
>$ java A "Hello World
>> "

  A mere �System.out.println()� will suffice with

java A -Dline.separator="Hello World
"

  , however, some shells might not treat the embedded line
  separator as intended.

Daniel Pitts <newsgroup.nospam@virtualinfinity.net> writes:
>I've got mine down to 61 characters. See if you can match that.

  Here is a new variant of the above challenge:

  Write a java program (source code) with less than 4000
  characters and a java command line with less than 1000
  characters that writes �Hello World� followed by a newline
  character and nothing else, but does so in a somewhat
  surprising or unusual way.

  My entry:

public class Main
{ public static void main( final java.lang.String[] args )
  { System.out.println(); System.out.print( '\n' ); }}

java -Dline.separator="Hello World" Main

On 6/14/12 11:04 AM, Stefan Ram wrote:
> Daniel Pitts<newsgroup.nospam@virtualinfinity.net>  writes:
>> I've got mine down to 61 characters. See if you can match that.
>
>    Here is a new variant of the above challenge:
>
>    Write a java program (source code) with less than 4000
>    characters and a java command line with less than 1000
>    characters that writes �Hello World� followed by a newline
>    character and nothing else, but does so in a somewhat
>    surprising or unusual way.
>
>    My entry:
>
> public class Main
> { public static void main( final java.lang.String[] args )
>    { System.out.println(); System.out.print( '\n' ); }}
>
> java -Dline.separator="Hello World" Main
>

A slightly obfuscated program which illustrates a few surprising things.

public class Hello {
     static Object left = "Top", right = "Bottom";
     static Object top = "Left";
     static Object bottom = "Right";

     public static void main(String[] args) throws Exception {
         for (int i = 0; i < 2; ++i) {
             s.out.print(new Hello());
             y(left, right, top, bottom);
         }
     }

     public String toString() {
         try {
             top = "value";
             bottom = "count";
             return "enumeration" + top + bottom;
         } finally {
             return getClass().getName();
         }
     }

     static <T extends java.lang.reflect.AccessibleObject> T t(T t) { 
t.setAccessible(true); return t;}

     static <T> void y(T l, T r, T... os) throws Exception {
         for (Object o : os) {
             x(l, o).set(l, x(l, o).get(r));
         }
     }

     private static java.lang.reflect.Field x(Object l, Object o) throws 
NoSuchFieldException {
         return t(l.getClass().getDeclaredField(o.toString()));
     }

     {
         left = toString();
         right = " W" + b + 'r' + a + "d\n";
     }

     static Object a = "l";
     static Object b = "o";
     static System s;
}

Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> Daniel Pitts <newsgroup.nospam@virtualinfinity.net> writes:
>>I've got mine down to 61 characters. See if you can match that.
> 
>  Here is a new variant of the above challenge:
> 
>  Write a java program (source code) with less than 4000
>  characters and a java command line with less than 1000
>  characters that writes »Hello World« followed by a newline
>  character and nothing else, but does so in a somewhat
>  surprising or unusual way.
> 
>  My entry:
> 
> public class Main
> { public static void main( final java.lang.String[] args )
>  { System.out.println(); System.out.print( '\n' ); }}
> 
> java -Dline.separator="Hello World" Main
> 

Well, mine doesn't have the same compactness, but here goes.
Run with plain "java HW":


import java.io.PrintStream;
import java.math.BigInteger;

public class HW {
  static boolean debug = false;
  final static  Long l_44 = 044L;

  public static void main(String[] args) {
    if( debug&doDebugLogging() ) {
      System.out.println( "World hello!" );
    }
							
    long ll1 = 42068934;
    long ll2 = 12834282;

    System.out.print(ll1++-ll2);
    System.out.print( " " );
    System.out.println(ll1+++ll2);
  }

  private static boolean doDebugLogging( ) {
    System.setOut( new PrintStream( System.out ) {
      public void print( long l ) { 
        print( BigInteger.valueOf( l ).toString(l_44.intValue()) ); 
      }
      public void print( String s ) {
        super.print( s.toUpperCase().charAt(0) + s.substring(1) );
      } });		   
    return false;
  }	
}

-- 
Leif Roar Moldskred

On 14 Jun 2012 18:04:46 GMT, ram@zedat.fu-berlin.de (Stefan Ram)
wrote:

>Daniel Pitts <newsgroup.nospam@virtualinfinity.net> writes:
>>I've got mine down to 61 characters. See if you can match that.
>
>  Here is a new variant of the above challenge:
>
>  Write a java program (source code) with less than 4000
>  characters and a java command line with less than 1000
>  characters that writes �Hello World� followed by a newline
>  character and nothing else, but does so in a somewhat
>  surprising or unusual way.
>
>  My entry:
>
>public class Main
>{ public static void main( final java.lang.String[] args )
>  { System.out.println(); System.out.print( '\n' ); }}
>
>java -Dline.separator="Hello World" Main

     The IOCCC (International Obfuscated C Code Contest) has been
running yearly for twenty years.  Is someone trying to start an IOJJJ
(International Obfuscated Java Jungle of Junk?)?

Sincerely,

Gene Wirchenko

On 6/14/12 11:04 AM, Stefan Ram wrote:
> Daniel Pitts<newsgroup.nospam@virtualinfinity.net>  writes:
>> I've got mine down to 61 characters. See if you can match that.
>
>    Here is a new variant of the above challenge:
>
>    Write a java program (source code) with less than 4000
>    characters and a java command line with less than 1000
>    characters that writes �Hello World� followed by a newline
>    character and nothing else, but does so in a somewhat
>    surprising or unusual way.
>
>    My entry:
>
> public class Main
> { public static void main( final java.lang.String[] args )
>    { System.out.println(); System.out.print( '\n' ); }}
>
> java -Dline.separator="Hello World" Main
>
Another lesson: Exceptions, and the deprecated (and highly dangerous) 
Thread.stop(Throwable) method.

import java.awt.EventQueue;
import java.io.PrintStream;
import java.lang.reflect.InvocationTargetException;

public class Hello extends Exception {
     public static void main(String[] args) throws Exception {
         Thread.setDefaultUncaughtExceptionHandler(
           new Thread.UncaughtExceptionHandler() {
             public void uncaughtException(Thread t, Throwable e) {
                 e.printStackTrace(System.out);
             }
         });
         final Thread thread = Thread.currentThread();
         EventQueue.invokeAndWait(new Runnable() {
             public void run() {
                 thread.stop(new Hello());
             }
         });
     }

     public void printStackTrace(PrintStream s) {
         s.print("Hello World");
     }
}

On 6/14/12 11:04 AM, Stefan Ram wrote:
> Daniel Pitts<newsgroup.nospam@virtualinfinity.net>  writes:
>> I've got mine down to 61 characters. See if you can match that.
>
>    Here is a new variant of the above challenge:
>
>    Write a java program (source code) with less than 4000
>    characters and a java command line with less than 1000
>    characters that writes �Hello World� followed by a newline
>    character and nothing else, but does so in a somewhat
>    surprising or unusual way.
>
>    My entry:
>
> public class Main
> { public static void main( final java.lang.String[] args )
>    { System.out.println(); System.out.print( '\n' ); }}
>
> java -Dline.separator="Hello World" Main
>
Any one more:
enum Hello{Hello,World;public static void 
main(String[]a){System.out.println(String.valueOf(java.util.Arrays.asList(values())).replaceAll("\\p{Punct}",""));}}

In article <zZ6Cr.4514$v14.839@newsfe06.iad>,
 Daniel Pitts <newsgroup.nospam@virtualinfinity.net> wrote:

> I saw a challenge Roedy posted on cljh, and I thought I might have a 
> slightly more interesting one.
> 
> Write a Java program which outputs "Hello World" followed by a new line 
> (and nothing else).
> 
> Now, do it using as few characters in the .java source code as possible.
> 
> I've got mine down to 61 characters. See if you can match that.

Without putting "Hello World" in the environment or using assembly:

class A{static{System.out.println("Hello World");System.exit(0);}}
-- 
I will not see posts from Google because I must filter them as spam

On 6/15/12 10:13 PM, Kevin McMurtrie wrote:
> In article<zZ6Cr.4514$v14.839@newsfe06.iad>,
>   Daniel Pitts<newsgroup.nospam@virtualinfinity.net>  wrote:
>
>> I saw a challenge Roedy posted on cljh, and I thought I might have a
>> slightly more interesting one.
>>
>> Write a Java program which outputs "Hello World" followed by a new line
>> (and nothing else).
>>
>> Now, do it using as few characters in the .java source code as possible.
>>
>> I've got mine down to 61 characters. See if you can match that.
>
> Without putting "Hello World" in the environment or using assembly:
>
> class A{static{System.out.println("Hello World");System.exit(0);}}
Note, that doesn't work on Java 7.

You can get rid of the static with a few other tricks. You can also trim 
the usage of System. to something shorter.

In article <zZ6Cr.4514$v14.839@newsfe06.iad>, 
newsgroup.nospam@virtualinfinity.net says...

> Write a Java program which outputs "Hello World" followed by a new 
> line (and nothing else).
> 
> Now, do it using as few characters in the .java source code as possible.
> 
> I've got mine down to 61 characters. See if you can match that.

Yoda says:
claim everything you can, prove you must.

Gru�,
-Wanja-

-- 
...Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

On 6/17/12 6:22 AM, Wanja Gayk wrote:
> In article<zZ6Cr.4514$v14.839@newsfe06.iad>,
> newsgroup.nospam@virtualinfinity.net says...
>
>> Write a Java program which outputs "Hello World" followed by a new
>> line (and nothing else).
>>
>> Now, do it using as few characters in the .java source code as possible.
>>
>> I've got mine down to 61 characters. See if you can match that.
>
> Yoda says:
> claim everything you can, prove you must.
I will post my solution, once everyone else has had a chance to attempt 
the problem.

On 17/06/2012 6:24 PM, Daniel Pitts wrote:
> On 6/17/12 6:22 AM, Wanja Gayk wrote:
>> In article<zZ6Cr.4514$v14.839@newsfe06.iad>,
>> newsgroup.nospam@virtualinfinity.net says...
>>
>>> Write a Java program which outputs "Hello World" followed by a new
>>> line (and nothing else).
>>>
>>> Now, do it using as few characters in the .java source code as possible.
>>>
>>> I've got mine down to 61 characters. See if you can match that.
>>
>> Yoda says:
>> claim everything you can, prove you must.
> I will post my solution, once everyone else has had a chance to attempt
> the problem.

"Everyone else"? As in, all seven billion of us?!

-- 
public final class JSnarker
extends JComponent
A JSnarker is an NNTP-aware component that asynchronously provides 
snarky output when the Ego.needsPuncturing() event is fired in cljp.

On 6/17/2012 6:25 PM, javax.swing.JSnarker wrote:
> On 17/06/2012 6:24 PM, Daniel Pitts wrote:
>> On 6/17/12 6:22 AM, Wanja Gayk wrote:
>>> In article<zZ6Cr.4514$v14.839@newsfe06.iad>,
>>> newsgroup.nospam@virtualinfinity.net says...
>>>
>>>> Write a Java program which outputs "Hello World" followed by a new
>>>> line (and nothing else).
>>>>
>>>> Now, do it using as few characters in the .java source code as
>>>> possible.
>>>>
>>>> I've got mine down to 61 characters. See if you can match that.
>>>
>>> Yoda says:
>>> claim everything you can, prove you must.
>> I will post my solution, once everyone else has had a chance to attempt
>> the problem.
>
> "Everyone else"? As in, all seven billion of us?!

In theory if he wait X days, then a good chunk of those 7 B would
have had a chance to go on the internet, read and reply.

In practice it will be a very small subset, but ...

Arne

On 17/06/2012 8:31 PM, Arne Vajh�j wrote:
> On 6/17/2012 6:25 PM, javax.swing.JSnarker wrote:
>> On 17/06/2012 6:24 PM, Daniel Pitts wrote:
>>> I will post my solution, once everyone else has had a chance to attempt
>>> the problem.
>>
>> "Everyone else"? As in, all seven billion of us?!
>
> In theory if he wait X days, then a good chunk of those 7 B would
> have had a chance to go on the internet, read and reply.
>
> In practice it will be a very small subset, but ...

The problem is, he said "everyone else" rather than "almost everyone 
else". So "a good chunk" won't cut it.

-- 
public final class JSnarker
extends JComponent
A JSnarker is an NNTP-aware component that asynchronously provides 
snarky output when the Ego.needsPuncturing() event is fired in cljp.

On 6/13/2012 11:52 PM, Roedy Green wrote:
> On Wed, 13 Jun 2012 13:45:18 -0700, Daniel Pitts
> <newsgroup.nospam@virtualinfinity.net> wrote, quoted or indirectly
> quoted someone who said :
>
>>
>> I've got mine down to 61 characters. See if you can match that.
>
>   here's the obvious solution at 88 chars:
>
> public class C{public static void main(String[]
> a){System.out.println("Hello World");}}

Daniel already posted the obvious solution.

Arne

On 6/17/12 5:55 PM, javax.swing.JSnarker wrote:
> On 17/06/2012 8:31 PM, Arne Vajh�j wrote:
>> On 6/17/2012 6:25 PM, javax.swing.JSnarker wrote:
>>> On 17/06/2012 6:24 PM, Daniel Pitts wrote:
>>>> I will post my solution, once everyone else has had a chance to attempt
>>>> the problem.
>>>
>>> "Everyone else"? As in, all seven billion of us?!
>>
>> In theory if he wait X days, then a good chunk of those 7 B would
>> have had a chance to go on the internet, read and reply.
>>
>> In practice it will be a very small subset, but ...
>
> The problem is, he said "everyone else" rather than "almost everyone
> else". So "a good chunk" won't cut it.
>
Well, while you took me literally, my intent was to wait "for enough 
people that wished to contribute to this conversation to do so."

Or for someone to find the same (or better) solution.

I suppose that a date deadline would have been more appropriate.

In any case, I think the other challenge was more interesting.  My 
solution to the "shortest" source is 60 characters long. The first two 
lines are simply a ruler, and not part of the source code.

          1         2         3         4         4         6
123456789012345678901234567890123456789012345678901234567890
enum H{W;System s;{s.out.println("Hello World");s.exit(0);}}

You would compile whatever file H was in (it needn't be in H.java since 
it isn't public).  Then execute with "java H"

Note, this no longer works in Java 7. It appears a method with the 
signature  "public static void main(String[])" is now required, where it 
could have been omitted in the past (as in my example).

On 17/06/2012 11:40 PM, Daniel Pitts wrote:
> In any case, I think the other challenge was more interesting. My
> solution to the "shortest" source is 60 characters long. The first two
> lines are simply a ruler, and not part of the source code.
>
>          1         2         3         4         4         6
> 123456789012345678901234567890123456789012345678901234567890
> enum H{W;System s;{s.out.println("Hello World");s.exit(0);}}
>
> You would compile whatever file H was in (it needn't be in H.java since
> it isn't public). Then execute with "java H"
>
> Note, this no longer works in Java 7. It appears a method with the
> signature "public static void main(String[])" is now required, where it
> could have been omitted in the past (as in my example).

That's pretty silly.

Of course, if you don't require it to terminate, only to not print 
anything else after "Hello World", you can use

 >          1         2         3         4         5
 > 123456789012345678901234567890123456789012345678901234
 > enum H{W;{System.out.println("Hello World");for(;;);}}

;)

-- 
public final class JSnarker
extends JComponent
A JSnarker is an NNTP-aware component that asynchronously provides 
snarky output when the Ego.needsPuncturing() event is fired in cljp.

On 06/17/2012 08:40 PM, Daniel Pitts wrote:
> On 6/17/12 5:55 PM, javax.swing.JSnarker wrote:
>> On 17/06/2012 8:31 PM, Arne Vajhøj wrote:
>>> On 6/17/2012 6:25 PM, javax.swing.JSnarker wrote:
>>>> On 17/06/2012 6:24 PM, Daniel Pitts wrote:
>>>>> I will post my solution, once everyone else has had a chance to attempt
>>>>> the problem.
>>>>
>>>> "Everyone else"? As in, all seven billion of us?!
>>>
>>> In theory if he wait X days, then a good chunk of those 7 B would
>>> have had a chance to go on the internet, read and reply.
>>>
>>> In practice it will be a very small subset, but ...
>>
>> The problem is, he said "everyone else" rather than "almost everyone
>> else". So "a good chunk" won't cut it.
>>
> Well, while you took me literally, my intent was to wait "for enough people
> that wished to contribute to this conversation to do so."
>
> Or for someone to find the same (or better) solution.
>
> I suppose that a date deadline would have been more appropriate.
>
> In any case, I think the other challenge was more interesting. My solution to
> the "shortest" source is 60 characters long. The first two lines are simply a
> ruler, and not part of the source code.
>
> 1 2 3 4 4 6
> 123456789012345678901234567890123456789012345678901234567890
> enum H{W;System s;{s.out.println("Hello World");s.exit(0);}}
>
> You would compile whatever file H was in (it needn't be in H.java since it
> isn't public). Then execute with "java H"
>
> Note, this no longer works in Java 7. It appears a method with the signature
> "public static void main(String[])" is now required, where it could have been
> omitted in the past (as in my example).

You aren't supposed to rely on a bug.

The JLS 3rd ed., which covers Java 5 and Java 6, says,
"A Java virtual machine starts up by loading a specified class and then 
invoking the method main in this specified class."
<http://docs.oracle.com/javase/specs/jls/se5.0/html/execution.html>

and
"A Java virtual machine starts execution by invoking the method main of some 
specified class, passing it a single argument, which is an array of strings."
<http://docs.oracle.com/javase/specs/jls/se5.0/html/execution.html#44444>

If you got it to start a different way, that was unreliable behavior and not 
actually correct.

Since your proposed solution is in contravention of the Java spec, it cannot 
be accepted.

Java 7 might not be the only version it fails on. How many Java systems did 
you try it on? IBM's? Oracle mainframe? HP? Oracle on Solaris? IBM on Z 
System? Can you be sure that Oracle's Java 6u34 will support this 
non-compliant bug?

You simply cannot legitimately propose a non-compliant "solution".

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

On 18/06/2012 12:25 AM, Lew wrote:
> You aren't supposed to rely on a bug.

It's not a bug.

> The JLS 3rd ed., which covers Java 5 and Java 6, says,
> "A Java virtual machine starts up by loading a specified class and then
> invoking the method main in this specified class."

Exactly. It loads the specified class, as part of which that class's 
static initializer runs. And if it's an enum, the enum elements' 
initializers run too.

If one of those calls System.exit(0) you could argue, theoretically, 
that there's an ambiguity in what the spec says should be the behavior. 
On the one hand, System.exit(0) should terminate the running VM instance 
when invoked. On the other hand, that precludes "and then invoking the 
method main in this specified class".

However, the observed behavior seems to be out of spec. The main 
method's absence should prompt an error upon the attempt to invoke it, 
and did. The error being generated before the main method should be 
being invoked is dissimilar from any other JVM behavior. For example, if 
you create code that attempts to invoke Foo.quux() by reflection, and 
there's no quux static method in class Foo, there won't be any error 
until the reflection attempt, which will throw an exception when it occurs.

More generally, "and then invoking the method main" can mean one of two 
things, given that main itself is static: the call to main is statically 
compiled in, in which case javac should complain when compiling the call 
site, or the call to main is reflective, in which case the error should 
not occur until runtime and should not occur until the running code 
reaches the location of the reflective invocation. We're now seeing an 
error later than compile time and earlier than the running code reaches 
the location of the reflective invocation, which behavior is 
inconsistent with *each* static-method call semantic.

-- 
public final class JSnarker
extends JComponent
A JSnarker is an NNTP-aware component that asynchronously provides 
snarky output when the Ego.needsPuncturing() event is fired in cljp.

On 6/17/12 9:25 PM, Lew wrote:
> On 06/17/2012 08:40 PM, Daniel Pitts wrote:
>> On 6/17/12 5:55 PM, javax.swing.JSnarker wrote:
>>> On 17/06/2012 8:31 PM, Arne Vajhøj wrote:
>>>> On 6/17/2012 6:25 PM, javax.swing.JSnarker wrote:
>>>>> On 17/06/2012 6:24 PM, Daniel Pitts wrote:
>>>>>> I will post my solution, once everyone else has had a chance to
>>>>>> attempt
>>>>>> the problem.
>>>>>
>>>>> "Everyone else"? As in, all seven billion of us?!
>>>>
>>>> In theory if he wait X days, then a good chunk of those 7 B would
>>>> have had a chance to go on the internet, read and reply.
>>>>
>>>> In practice it will be a very small subset, but ...
>>>
>>> The problem is, he said "everyone else" rather than "almost everyone
>>> else". So "a good chunk" won't cut it.
>>>
>> Well, while you took me literally, my intent was to wait "for enough
>> people
>> that wished to contribute to this conversation to do so."
>>
>> Or for someone to find the same (or better) solution.
>>
>> I suppose that a date deadline would have been more appropriate.
>>
>> In any case, I think the other challenge was more interesting. My
>> solution to
>> the "shortest" source is 60 characters long. The first two lines are
>> simply a
>> ruler, and not part of the source code.
>>
>> 1 2 3 4 4 6
>> 123456789012345678901234567890123456789012345678901234567890
>> enum H{W;System s;{s.out.println("Hello World");s.exit(0);}}
>>
>> You would compile whatever file H was in (it needn't be in H.java
>> since it
>> isn't public). Then execute with "java H"
>>
>> Note, this no longer works in Java 7. It appears a method with the
>> signature
>> "public static void main(String[])" is now required, where it could
>> have been
>> omitted in the past (as in my example).
>
> You aren't supposed to rely on a bug.
>
> The JLS 3rd ed., which covers Java 5 and Java 6, says,
> "A Java virtual machine starts up by loading a specified class and then
> invoking the method main in this specified class."
> <http://docs.oracle.com/javase/specs/jls/se5.0/html/execution.html>
My program wasn't a bug, it relied on loading the specified class, which 
has the (documented) side-effect of initializing the class, which causes 
the initializers to run.
>
> and
> "A Java virtual machine starts execution by invoking the method main of
> some specified class, passing it a single argument, which is an array of
> strings."
> <http://docs.oracle.com/javase/specs/jls/se5.0/html/execution.html#44444>
>
> If you got it to start a different way, that was unreliable behavior and
> not actually correct.
The wording in the 3rd edition is different enough to explain the 
difference in behavior, and so Java 6 in fact has the required behavior 
of loading the class.  Java 7 doesn't require the class be loaded before 
invoking the method.
>
> Since your proposed solution is in contravention of the Java spec, it
> cannot be accepted.
For Java 7, I agree. Java 6 it meets the spec.
>
> Java 7 might not be the only version it fails on. How many Java systems
> did you try it on? IBM's? Oracle mainframe? HP? Oracle on Solaris? IBM
> on Z System? Can you be sure that Oracle's Java 6u34 will support this
> non-compliant bug?
Those wouldn't be compliant to JLS 2nd edition then.
>
> You simply cannot legitimately propose a non-compliant "solution".
>
The idea of this "Challenge" was to think outside the box. If it works, 
its a solution.

On 18/06/2012 12:04 PM, Daniel Pitts wrote:
> The wording in the 3rd edition is different enough to explain the
> difference in behavior, and so Java 6 in fact has the required behavior
> of loading the class.  Java 7 doesn't require the class be loaded before
> invoking the method.

Sounds like a bug in the spec, to me. How can invoking a method *ever* 
not require the class containing that method be loaded first?

-- 
public final class JSnarker
extends JComponent
A JSnarker is an NNTP-aware component that asynchronously provides 
snarky output when the Ego.needsPuncturing() event is fired in cljp.

On 6/18/2012 10:09 AM, javax.swing.JSnarker wrote:
> On 18/06/2012 12:04 PM, Daniel Pitts wrote:
>> The wording in the 3rd edition is different enough to explain the
>> difference in behavior, and so Java 6 in fact has the required behavior
>> of loading the class.  Java 7 doesn't require the class be loaded before
>> invoking the method.
>
> Sounds like a bug in the spec, to me. How can invoking a method *ever*
> not require the class containing that method be loaded first?
>


It's just the order that things are done by default.

Before the code was:

1. Load class with initialization.
2. Run 'main' method.

Now, they do the special step of loading without initialization:

1. Load class without initialization.
2. Verify 'main' method, throw error if not present
3. Initialize class
4. Run 'main' method.

You can see how the new method takes more effort.

On 18/06/2012 2:06 PM, markspace wrote:
> Before the code was:
>
> 1. Load class with initialization.
> 2. Run 'main' method.
>
> Now, they do the special step of loading without initialization:
>
> 1. Load class without initialization.
> 2. Verify 'main' method, throw error if not present
> 3. Initialize class
> 4. Run 'main' method.
>
> You can see how the new method takes more effort.

What was the purpose of such a change? It now is a special case 
dissimilar to all other instances of JVM classloading.

-- 
public final class JSnarker
extends JComponent
A JSnarker is an NNTP-aware component that asynchronously provides 
snarky output when the Ego.needsPuncturing() event is fired in cljp.

On Monday, June 18, 2012 9:04:15 AM UTC-7, Daniel Pitts wrote:
> On 6/17/12 9:25 PM, Lew wrote:
> > On 06/17/2012 08:40 PM, Daniel Pitts wrote:
> >> On 6/17/12 5:55 PM, javax.swing.JSnarker wrote:
> >>> On 17/06/2012 8:31 PM, Arne Vajh=F8j wrote:
> >>>> On 6/17/2012 6:25 PM, javax.swing.JSnarker wrote:
> >>>>> On 17/06/2012 6:24 PM, Daniel Pitts wrote:
> >>>>>> I will post my solution, once everyone else has had a chance to
> >>>>>> attempt
> >>>>>> the problem.
> >>>>>
> >>>>> "Everyone else"? As in, all seven billion of us?!
> >>>>
> >>>> In theory if he wait X days, then a good chunk of those 7 B would
> >>>> have had a chance to go on the internet, read and reply.
> >>>>
> >>>> In practice it will be a very small subset, but ...
> >>>
> >>> The problem is, he said "everyone else" rather than "almost everyone
> >>> else". So "a good chunk" won't cut it.
> >>>
> >> Well, while you took me literally, my intent was to wait "for enough
> >> people
> >> that wished to contribute to this conversation to do so."
> >>
> >> Or for someone to find the same (or better) solution.
> >>
> >> I suppose that a date deadline would have been more appropriate.
> >>
> >> In any case, I think the other challenge was more interesting. My
> >> solution to
> >> the "shortest" source is 60 characters long. The first two lines are
> >> simply a
> >> ruler, and not part of the source code.
> >>
> >> 1 2 3 4 4 6
> >> 123456789012345678901234567890123456789012345678901234567890
> >> enum H{W;System s;{s.out.println("Hello World");s.exit(0);}}
> >>
> >> You would compile whatever file H was in (it needn't be in H.java
> >> since it
> >> isn't public). Then execute with "java H"
> >>
> >> Note, this no longer works in Java 7. It appears a method with the
> >> signature
> >> "public static void main(String[])" is now required, where it could
> >> have been
> >> omitted in the past (as in my example).
> >
> > You aren't supposed to rely on a bug.
> >
> > The JLS 3rd ed., which covers Java 5 and Java 6, says,
> > "A Java virtual machine starts up by loading a specified class and then
> > invoking the method main in this specified class."
> > <http://docs.oracle.com/javase/specs/jls/se5.0/html/execution.html>
> My program wasn't a bug, it relied on loading the specified class, which=
=20
> has the (documented) side-effect of initializing the class, which causes=
=20
> the initializers to run.

Not true.

> > and
> > "A Java virtual machine starts execution by invoking the method main of
> > some specified class, passing it a single argument, which is an array o=
f
> > strings."
> > <http://docs.oracle.com/javase/specs/jls/se5.0/html/execution.html#4444=
4>
> >
> > If you got it to start a different way, that was unreliable behavior an=
d
> > not actually correct.
> The wording in the 3rd edition is different enough to explain the=20

How, exactly?

> difference in behavior, and so Java 6 in fact has the required behavior=
=20
> of loading the class.  Java 7 doesn't require the class be loaded before=
=20
> invoking the method.

Java never required initialization upon load, and in fact was very specific=
 about=20
the circumstances under which a class initializes.

<http://docs.oracle.com/javase/specs/jls/se5.0/html/execution.html#12.4.1>
"A class or interface type T will be initialized immediately before the fir=
st occurrence of any one of the following:

- T is a class and an instance of T is created.
- T is a class and a static method declared by T is invoked.
- A static field declared by T is assigned.
- A static field declared by T is used and the field is not a constant vari=
able (=A74.12.4).
- T is a top-level class, and an assert statement (=A714.10) lexically nest=
ed within T is executed.

Invocation of certain reflective methods in class Class and in package java=
..lang.reflect also=20
causes class or interface initialization. A class or interface will not be =
initialized under any=20
other circumstance."

You are saying that the first case applies, an instance is created because =
of=20
the third case, a static field is assigned. But that assignment shouldn't h=
appen=20
yet because nothing has invoked the class legally, i.e., the sequence to in=
voke=20
'main()' didn't happen. It is, in fact, the invocation of 'main()' that is =
supposed to=20
trigger the initialization.

Historically Sun's JVMs have had bugs in this area, by their own admission.

I read the JLS 3rd edition as not allowing the behavior you claim as a solu=
tion.
There has been no change in the language regarding how a JVM starts.

So if the trick violates Java 7, and the language hasn't changed, it must a=
lso violate
Java 6, and that it worked was a bug.

Perhaps if you could quote the exact differences in wording to which you re=
fer?

--=20
Lew

On Sunday, June 17, 2012 9:45:34 PM UTC-7, javax.swing.JSnarker wrote:
> On 18/06/2012 12:25 AM, Lew wrote:
> > You aren't supposed to rely on a bug.
> 
> It's not a bug.
> 
> > The JLS 3rd ed., which covers Java 5 and Java 6, says,
> > "A Java virtual machine starts up by loading a specified class and then
> > invoking the method main in this specified class."
> 
> Exactly. It loads the specified class, as part of which that class's 
> static initializer runs. And if it's an enum, the enum elements' 
> initializers run too.

Loading does not imply initialization, and in fact cannot.

The JVM is forbidden to initialize a class except under specific 
circumstances, a
> 
> If one of those calls System.exit(0) you could argue, theoretically, 
> that there's an ambiguity in what the spec says should be the behavior. 
> On the one hand, System.exit(0) should terminate the running VM instance 
> when invoked. On the other hand, that precludes "and then invoking the 
> method main in this specified class".
> 
> However, the observed behavior seems to be out of spec. The main 
> method's absence should prompt an error upon the attempt to invoke it, 
> and did. The error being generated before the main method should be 
> being invoked is dissimilar from any other JVM behavior. For example, if 
> you create code that attempts to invoke Foo.quux() by reflection, and 
> there's no quux static method in class Foo, there won't be any error 
> until the reflection attempt, which will throw an exception when it occurs.
> 
> More generally, "and then invoking the method main" can mean one of two 
> things, given that main itself is static: the call to main is statically 
> compiled in, in which case javac should complain when compiling the call 
> site, or the call to main is reflective, in which case the error should 
> not occur until runtime and should not occur until the running code 
> reaches the location of the reflective invocation. We're now seeing an 
> error later than compile time and earlier than the running code reaches 
> the location of the reflective invocation, which behavior is 
> inconsistent with *each* static-method call semantic.
> 
> -- 
> public final class JSnarker
> extends JComponent
> A JSnarker is an NNTP-aware component that asynchronously provides 
> snarky output when the Ego.needsPuncturing() event is fired in cljp.



On Sunday, June 17, 2012 9:45:34 PM UTC-7, javax.swing.JSnarker wrote:
> On 18/06/2012 12:25 AM, Lew wrote:
> > You aren't supposed to rely on a bug.
> 
> It's not a bug.
> 
> > The JLS 3rd ed., which covers Java 5 and Java 6, says,
> > "A Java virtual machine starts up by loading a specified class and then
> > invoking the method main in this specified class."
> 
> Exactly. It loads the specified class, as part of which that class's 
> static initializer runs. And if it's an enum, the enum elements' 
> initializers run too.
> 
> If one of those calls System.exit(0) you could argue, theoretically, 
> that there's an ambiguity in what the spec says should be the behavior. 
> On the one hand, System.exit(0) should terminate the running VM instance 
> when invoked. On the other hand, that precludes "and then invoking the 
> method main in this specified class".
> 
> However, the observed behavior seems to be out of spec. The main 
> method's absence should prompt an error upon the attempt to invoke it, 
> and did. The error being generated before the main method should be 
> being invoked is dissimilar from any other JVM behavior. For example, if 
> you create code that attempts to invoke Foo.quux() by reflection, and 
> there's no quux static method in class Foo, there won't be any error 
> until the reflection attempt, which will throw an exception when it occurs.
> 
> More generally, "and then invoking the method main" can mean one of two 
> things, given that main itself is static: the call to main is statically 
> compiled in, in which case javac should complain when compiling the call 
> site, or the call to main is reflective, in which case the error should 
> not occur until runtime and should not occur until the running code 
> reaches the location of the reflective invocation. We're now seeing an 
> error later than compile time and earlier than the running code reaches 
> the location of the reflective invocation, which behavior is 
> inconsistent with *each* static-method call semantic.
> 
> -- 
> public final class JSnarker
> extends JComponent
> A JSnarker is an NNTP-aware component that asynchronously provides 
> snarky output when the Ego.needsPuncturing() event is fired in cljp.



On Sunday, June 17, 2012 9:45:34 PM UTC-7, javax.swing.JSnarker wrote:
> On 18/06/2012 12:25 AM, Lew wrote:
> > You aren't supposed to rely on a bug.
> 
> It's not a bug.
> 
> > The JLS 3rd ed., which covers Java 5 and Java 6, says,
> > "A Java virtual machine starts up by loading a specified class and then
> > invoking the method main in this specified class."
> 
> Exactly. It loads the specified class, as part of which that class's 
> static initializer runs. And if it's an enum, the enum elements' 
> initializers run too.

Not true. Loading does not imply initialization, and in fact is forbidden to.

The initializers only run under specific circumstances, separately from 
loading.

I have cited the relevant JLS sections.

> If one of those calls System.exit(0) you could argue, theoretically, 
> that there's an ambiguity in what the spec says should be the behavior. 
> On the one hand, System.exit(0) should terminate the running VM instance 
> when invoked. On the other hand, that precludes "and then invoking the 
> method main in this specified class".

False premise, unreliable conclusion. Loading does not imply initialization.

> However, the observed behavior seems to be out of spec. The main 
> method's absence should prompt an error upon the attempt to invoke it, 

Indeed.

-- 
Lew

On 18/06/2012 3:47 PM, Lew wrote:
> Loading does not imply initialization, and in fact cannot.

Wrong. Loading and initialization go hand-in-hand.

> The JVM is forbidden to initialize a class except under specific
> circumstances, a

What?

>> Exactly. It loads the specified class, as part of which that class's
>> static initializer runs. And if it's an enum, the enum elements'
>> initializers run too.
>
> Not true. Loading does not imply initialization, and in fact is forbidden to.

Wrong. Loading and initialization go hand-in-hand.

> The initializers only run under specific circumstances, separately from
> loading.
>
> I have cited the relevant JLS sections.

You haven't cited anything except my own post, and your quotation of 
*that* was a jumbled mess with some sections repeated for some reason.

> False premise, unreliable conclusion.

On your part, Lew.

> Loading does not imply initialization.

Wrong. Loading and initialization go hand-in-hand.

>> However, the observed behavior seems to be out of spec. The main
>> method's absence should prompt an error upon the attempt to invoke it,
>
> Indeed.

And not before.

When invoking a static method of a non-loaded class, the standard 
procedure always has been:

Load the class.
Initialize the class.
Invoke the method.

In particular, the spec requires that in this:

class A {
     static int x;

     static { x = 100; }

     static int foo () { return x; }
}

a call to A.foo() should return 100, not 0. If it can attempt to invoke 
foo before the static initializer has executed that would be violated.

On the other hand, it complaining that a reflective call to A.bar() 
can't be resolved sooner than the loading and initializing of A as part 
of trying to resolve bar is equally anomalous. If it hasn't loaded and 
initialized A yet, how can it be sure whether or not it has a method 
bar? On the other hand, if it's a non-reflective call the code calling 
bar won't even compile.

-- 
public final class JSnarker
extends JComponent
A JSnarker is an NNTP-aware component that asynchronously provides 
snarky output when the Ego.needsPuncturing() event is fired in cljp.

On 18/06/2012 3:44 PM, Lew wrote:
> "A class or interface type T will be initialized immediately before the first occurrence of any one of the following:
>
> - T is a class and a static method declared by T is invoked.

This is the case that seems to be applicable here. It should not be 
erroring out trying to invoke main until after initialization, because 
the initialization must occur immediately *before* the invocation 
attempt (since it must have occurred if that attempt succeeds or again 
the spec is violated).

> You are saying that the first case applies, an instance is created because of
> the third case, a static field is assigned. But that assignment shouldn't happen
> yet because nothing has invoked the class legally, i.e., the sequence to invoke
> 'main()' didn't happen. It is, in fact, the invocation of 'main()' that is supposed to
> trigger the initialization.

That's backwards. Initialization must *precede* the invocation, not 
*follow* it. The JVM is required to initialize the class just *before* 
attempting to invoke the main method, and indeed up through Java 6 that 
is precisely what it did.

-- 
public final class JSnarker
extends JComponent
A JSnarker is an NNTP-aware component that asynchronously provides 
snarky output when the Ego.needsPuncturing() event is fired in cljp.

On 6/18/2012 11:46 AM, javax.swing.JSnarker wrote:
> What was the purpose of such a change? It now is a special case
> dissimilar to all other instances of JVM classloading.
>


Well no, you have the option to load a class without initializing it.

I assume that the change was to prevent bugs.  If parts of a real 
working application start up in a class initialization (not best 
practice, but still possible) which allocate resources and then those 
resources are not cleaned up when the whole app abruptly terminates, I 
could see how it could be considered a bug in the JVM's start-up 
procedure rather than the app itself.  I'm not sure I'd agree, but I 
could see someone making that case.

On Monday, June 18, 2012 12:57:53 PM UTC-7, javax.swing.JSnarker wrote:
> On 18/06/2012 3:47 PM, Lew wrote:
> > Loading does not imply initialization, and in fact cannot.
>=20
> Wrong. Loading and initialization go hand-in-hand.
>=20
> > The JVM is forbidden to initialize a class except under specific
> > circumstances, a
>=20
> What?

See JLS 12.4, which I cited upthread:
<http://docs.oracle.com/javase/specs/jls/se7/html/jls-12.html#jls-12.4>
"A class or interface type T will be initialized immediately before the fir=
st occurrence of any one of the following:

- T is a class and an instance of T is created.

- T is a class and a static method declared by T is invoked.

- A static field declared by T is assigned.

- A static field declared by T is used and the field is not a constant vari=
able (=A74.12.4).

- T is a top level class (=A77.6), and an assert statement (=A714.10) lexic=
ally nested within T (=A78.1.3) is executed.

A reference to a static field (=A78.3.1.1) causes initialization of only th=
e class or interface that actually declares it, even though it might be ref=
erred to through the name of a subclass, a subinterface, or a class that im=
plements an interface.

Invocation of certain reflective methods in class Class and in package java=
..lang.reflect also causes class or interface initialization.

A class or interface will not be initialized under any other circumstance."

>=20
> >> Exactly. It loads the specified class, as part of which that class's
> >> static initializer runs. And if it's an enum, the enum elements'
> >> initializers run too.
> >
> > Not true. Loading does not imply initialization, and in fact is forbidd=
en to.
>=20
> Wrong. Loading and initialization go hand-in-hand.

Not according to the JLS. What authority are you using?

> > The initializers only run under specific circumstances, separately from
> > loading.
> >
> > I have cited the relevant JLS sections.
>=20
> You haven't cited anything except my own post, and your quotation of=20
> *that* was a jumbled mess with some sections repeated for some reason.

Again, I quoted the section I re-quoted in this post. I provided the link=
=20
*and* quoted the relevant content. How can you say I didn't?

> > False premise, unreliable conclusion.
>=20
> On your part, Lew.
>=20
> > Loading does not imply initialization.
>=20
> Wrong. Loading and initialization go hand-in-hand.

Except according to the JLS.

> >> However, the observed behavior seems to be out of spec. The main
> >> method's absence should prompt an error upon the attempt to invoke it,
> >
> > Indeed.
>=20
> And not before.
>=20
> When invoking a static method of a non-loaded class, the standard=20
> procedure always has been:
>=20
> Load the class.
> Initialize the class.

Note - that is two steps, not one.

> Invoke the method.
>=20
> In particular, the spec requires that in this:
>=20
> class A {
>      static int x;
>=20
>      static { x =3D 100; }
>=20
>      static int foo () { return x; }
> }
>=20
> a call to A.foo() should return 100, not 0. If it can attempt to invoke=
=20
> foo before the static initializer has executed that would be violated.

It can attempt to call 'foo()' before the initializer has executed. This is=
=20
exactly one of the circumstances that causes the initializers to execute.

Read the JLS! I have referenced and quoted the relevant section twice now.

> On the other hand, it complaining that a reflective call to A.bar()=20
> can't be resolved sooner than the loading and initializing of A as part=
=20
> of trying to resolve bar is equally anomalous. If it hasn't loaded and=20

I haven't seen any examples of reflection in this thread. Regardless,=20
"certain reflective methods" invoked will cause initialization.

> initialized A yet, how can it be sure whether or not it has a method=20
> bar? On the other hand, if it's a non-reflective call the code calling=20
> bar won't even compile.

--=20
Lew

On Monday, June 18, 2012 1:01:41 PM UTC-7, javax.swing.JSnarker wrote:
> On 18/06/2012 3:44 PM, Lew wrote:
> > "A class or interface type T will be initialized immediately before the first occurrence of any one of the following:
> >
> > - T is a class and a static method declared by T is invoked.
> 
> This is the case that seems to be applicable here. It should not be 
> erroring out trying to invoke main until after initialization, because 
> the initialization must occur immediately *before* the invocation 
> attempt (since it must have occurred if that attempt succeeds or again 
> the spec is violated).
> 
> > You are saying that the first case applies, an instance is created because of
> > the third case, a static field is assigned. But that assignment shouldn't happen
> > yet because nothing has invoked the class legally, i.e., the sequence to invoke
> > 'main()' didn't happen. It is, in fact, the invocation of 'main()' that is supposed to
> > trigger the initialization.
> 
> That's backwards. Initialization must *precede* the invocation, not 

Invocation precedes initialization, in that it is one of the triggers for 
initialization, as described in the JLS.

The attempt to invoke causes initialization before invocation completes.

I've provided a link and citation of the relevant JLS section. Twice. 
Read it.

> *follow* it. The JVM is required to initialize the class just *before* 
> attempting to invoke the main method, and indeed up through Java 6 that 
> is precisely what it did.

No, it is initialized just before the method is invoked. The attempt is what 
triggers the initialization.

And initialization doesn't occur until such an attempt or one of the other 
triggering events. In particular, the class is not automatically initialized 
when loaded.

Read the JLS.

-- 
Lew

Lew <lewbloch@gmail.com> wrote:

 
> "Invocation of certain reflective methods in class Class and in
>  package java.lang.reflect also causes class or interface
>  initialization."

Might this be what is happening? The JLS doesn't seem to specify _how_
the main method should be invoked, so might not a Java implementation
do so through reflection and thus trigger the initialization of the
class?

-- 
Leif Roar Moldskred

Leif Roar Moldskred wrote:
> Lew wrote:
> > "Invocation of certain reflective methods in class Class and in
> >  package java.lang.reflect also causes class or interface
> >  initialization."
> 
> Might this be what is happening? The JLS doesn't seem to specify _how_
> the main method should be invoked, so might not a Java implementation
> do so through reflection and thus trigger the initialization of the
> class?

There was no 'main()' method in the example under discussion.

The JLS says that the JVM is started by invocation of a 'main()' method.

Without such an invocation, nothing should have been able to call any of the 
static methods of the 'enum' or otherwise triggered initialization of that class.

The class initialized anyway. 

Ergo the process didn't follow the JLS.

-- 
Lew

On 18/06/2012 4:31 PM, Lew wrote:
> On Monday, June 18, 2012 12:57:53 PM UTC-7, javax.swing.JSnarker wrote:
>> On 18/06/2012 3:47 PM, Lew wrote:
>>> Loading does not imply initialization, and in fact cannot.
>>
>> Wrong. Loading and initialization go hand-in-hand.
>>
>>> The JVM is forbidden to initialize a class except under specific
>>> circumstances, a
>>
>> What?
>
> See JLS 12.4, which I cited upthread:

Why did you write half a sentence and end it in mid-word, though?

>> Wrong. Loading and initialization go hand-in-hand.
>
> Not according to the JLS. What authority are you using?

The fact that initialization is required before use of a class 
(instantiation, invocation of a static method, whatever), and that 
loading is not required until the circumstances that permit and require 
initialization. Thus, loading will tend not to occur until right before 
use, and initialization will thus tend to occur right after loading.

>> You haven't cited anything except my own post, and your quotation of
>> *that* was a jumbled mess with some sections repeated for some reason.
>
> Again, I quoted the section I re-quoted in this post. I provided the link
> *and* quoted the relevant content. How can you say I didn't?

You didn't provide any link and you quoted some stuff from my post 
*twice*, for some reason. There seems to be a partial quote of it and a 
bit of inline commentary from you (criticisms, natch), followed by a 
second attribution line and then a quote of the entirety of my post, 
including the parts already quoted earlier.

>> Wrong. Loading and initialization go hand-in-hand.
>
> Except according to the JLS.

The fact that initialization is required before use of a class 
(instantiation, invocation of a static method, whatever), and that 
loading is not required until the circumstances that permit and require 
initialization. Thus, loading will tend not to occur until right before 
use, and initialization will thus tend to occur right after loading.

>> Load the class.
>> Initialize the class.
>
> Note - that is two steps, not one.

However, there is little point in doing the first step until right 
before the second step, so in practice they should occur back-to-back.

>> a call to A.foo() should return 100, not 0. If it can attempt to invoke
>> foo before the static initializer has executed that would be violated.
>
> It can attempt to call 'foo()' before the initializer has executed.

No, it generally can't. If the attempt succeeds and, as a consequence, 
foo() executes before the initializer has executed, then foo will 
incorrectly return 0. Therefore the attempt must not be made until the 
initializer has executed, except in the peculiar case that the attempt 
is known in advance to be guaranteed to fail. In which case there should 
have been a compile-time error earlier still.

> This is exactly one of the circumstances that causes the initializers
> to execute.

You are confused. You seem to be thinking the order is

Load class
Attempt to call foo
Initialize class

But this can only be guaranteed not to violate the semantic requirements 
if the attempt is known to be sure to fail. If the attempt to call foo 
might succeed, then the order MUST be

Load class
Initialize class
Attempt to call foo

so that if the third step succeeds and foo begins executing, foo does 
not encounter things still in an uninitialized state that the spec 
guarantees must have been initialized before foo begins executing!

> Read the JLS! I have referenced and quoted the relevant section twice now.

And I've replied to it once, and it clearly states that initialization 
must occur *before* any invocation of a static method. Your suggestion 
that it can invoke it first and *then* initialize the class simply 
cannot fly.

> I haven't seen any examples of reflection in this thread.

How is the main method invoked? It obviously isn't a statically-compiled 
call from another class, and the only other invocation mechanism is 
reflection; therefore it is called reflectively, by something that 
behaves analogously to 
Class.forName(argv[1]).getMethod("main",ARRAY_OF_JUST_THE_STRING_ARRAY_CLASS).invoke(null,convertRestOfArgv);.

>> initialized A yet, how can it be sure whether or not it has a method
>> bar? On the other hand, if it's a non-reflective call the code calling
>> bar won't even compile.
>

Why is the above quoted, but not responded to?

-- 
public final class JSnarker
extends JComponent
A JSnarker is an NNTP-aware component that asynchronously provides 
snarky output when the Ego.needsPuncturing() event is fired in cljp.

On 18/06/2012 5:18 PM, Lew wrote:
> Leif Roar Moldskred wrote:
>> Lew wrote:
>>> "Invocation of certain reflective methods in class Class and in
>>>   package java.lang.reflect also causes class or interface
>>>   initialization."
>>
>> Might this be what is happening? The JLS doesn't seem to specify _how_
>> the main method should be invoked, so might not a Java implementation
>> do so through reflection and thus trigger the initialization of the
>> class?
>
> There was no 'main()' method in the example under discussion.
>
> The JLS says that the JVM is started by invocation of a 'main()' method.
>
> Without such an invocation, nothing should have been able to call any of the
> static methods of the 'enum' or otherwise triggered initialization of that class.

There is such an invocation, though -- albeit an unsuccessful one, if no 
method of that name can be resolved by the reflection code.

> The class initialized anyway.

Because the two alternatives are:

initialize, then try to invoke method; and
try to invoke method, then initialize.

But in the second case, if the invocation succeeds the method runs and 
then the initializer instead of the other way around, and that's 
obviously wrong.

-- 
public final class JSnarker
extends JComponent
A JSnarker is an NNTP-aware component that asynchronously provides 
snarky output when the Ego.needsPuncturing() event is fired in cljp.

On 18/06/2012 4:22 PM, markspace wrote:
> On 6/18/2012 11:46 AM, javax.swing.JSnarker wrote:
>> What was the purpose of such a change? It now is a special case
>> dissimilar to all other instances of JVM classloading.
>
> Well no, you have the option to load a class without initializing it.
>
> I assume that the change was to prevent bugs.  If parts of a real
> working application start up in a class initialization (not best
> practice, but still possible) which allocate resources and then those
> resources are not cleaned up when the whole app abruptly terminates, I
> could see how it could be considered a bug in the JVM's start-up
> procedure rather than the app itself.  I'm not sure I'd agree, but I
> could see someone making that case.

If resources allocated by an app are not cleaned up when "the whole app 
abruptly terminates", then the bug is in the operating system, not the 
app OR the JVM.

-- 
public final class JSnarker
extends JComponent
A JSnarker is an NNTP-aware component that asynchronously provides 
snarky output when the Ego.needsPuncturing() event is fired in cljp.

On 18/06/2012 4:36 PM, Lew wrote:
> On Monday, June 18, 2012 1:01:41 PM UTC-7, javax.swing.JSnarker wrote:
>> On 18/06/2012 3:44 PM, Lew wrote:
>>> "A class or interface type T will be initialized immediately before the first occurrence of any one of the following:
>>>
>>> - T is a class and a static method declared by T is invoked.
>>
>> This is the case that seems to be applicable here. It should not be
>> erroring out trying to invoke main until after initialization, because
>> the initialization must occur immediately *before* the invocation
>> attempt (since it must have occurred if that attempt succeeds or again
>> the spec is violated).
>>
>>> You are saying that the first case applies, an instance is created because of
>>> the third case, a static field is assigned. But that assignment shouldn't happen
>>> yet because nothing has invoked the class legally, i.e., the sequence to invoke
>>> 'main()' didn't happen. It is, in fact, the invocation of 'main()' that is supposed to
>>> trigger the initialization.
>>
>> That's backwards. Initialization must *precede* the invocation, not
>
> Invocation precedes initialization, in that it is one of the triggers for
> initialization, as described in the JLS.

That's confused thinking. Invocation *cannot* precede initialization if 
initialization must have been done before the method's code starts 
running. It can't run the method *before* initialization.

The language of the spec does not say, however, that invocation will be 
followed by initialization. As you quoted it above, it clearly says that 
initialization will occur *immediately before invocation* in these 
cases. Initialization first, THEN invocation.

The trigger is not invocation itself, as it can't be as initialization 
would then happen one invocation too late. The trigger is that that 
invocation (attempt) is imminent, but has not yet already happened.

> The attempt to invoke causes initialization before invocation completes.

That also doesn't make sense. The attempt to invoke and the execution, 
if the attempt is successful, of the method are all one single thing. 
Initialization either happens before or after it -- and it cannot happen 
after. Therefore it happens before.

If I attempt to catch a ball and then put on my baseball glove, then the 
ball will land in my bare hand if the attempt succeeds. If I put on my 
baseball glove and then attempt to catch a ball, the ball will land in 
my gloved hand if the attempt succeeds. The spec says the ball should 
land in my gloved hand. So, I can wait until immediately before 
attempting to catch the ball to put the glove on, but I cannot wait 
until after the attempt. (And if the analogy with the JLS spec is 
continued, I mustn't put the glove on until immediately before the first 
such attempt.)

> I've provided a link and citation of the relevant JLS section. Twice.
> Read it.

I did. If anyone didn't read it it was you. It clearly said 
initialization *precedes* the first of any of a number of things done to 
a class, including method invocation. Your notion that method invocation 
can happen first and initialization later is based on nothing in the 
written text of the spec, and, furthermore, simply does not make sense.

>> *follow* it. The JVM is required to initialize the class just *before*
>> attempting to invoke the main method, and indeed up through Java 6 that
>> is precisely what it did.
>
> No, it is initialized just before the method is invoked.

There you are, then. *Before* the method is invoked. Not after. And 
certainly not during. (None of this stuff is thread-safe!) Initialize, 
then (attempt to) invoke method. Cannot be the other way around, or the 
ball will land in an ungloved hand if the attempt succeeds.

> And initialization doesn't occur until such an attempt or one of the other
> triggering events.

But then it occurs immediately *before*.

> In particular, the class is not automatically initialized when loaded.

No, but in practice it's not loaded until right before it would be 
initialized, because it would just be wasting memory during the interim.

> Read the JLS.

You read it. Or reread it. Obviously you missed something or got confused.

-- 
public final class JSnarker
extends JComponent
A JSnarker is an NNTP-aware component that asynchronously provides 
snarky output when the Ego.needsPuncturing() event is fired in cljp.

javax.swing.JSnarker wrote:
>  Lew wrote:
>> Read the JLS.
> 
> You read it. Or reread it. Obviously you missed something or got confused.

Not only did I not miss something nor am confused, I've encountered this in 
practice.

You argue that usually loading immediately precedes initialization. This is 
true. But not always.

You argue that loading must precede initialization. This is true, but it is 
not true that initialization must immediately follow loading.

For example, a reference to 'Foo.class' will load 'Foo', but not initialize it, 
if 'Foo' had not previously been loaded or initialized.

The big gaping flaw in your reasoning is that you leave out what triggers the 
cycle of load/initialize. Classes are loaded and initialized on demand in Java. 
That means the loading and initialization does not happen until there is 
a qualifying reference to the class.

I've encountered bugs in code that depended on initialization to occur 
immediately upon loading. What a surprise when that doesn't happen, 
as in fact does happen. 

Unless of course you understand the JLS.

I keep quoting and requoting the JLS, section 12.4.1. You should read it.
You obviously missed something or got confused.

-- 
Lew

On 18/06/2012 9:25 PM, Lew wrote:
> javax.swing.JSnarker wrote:
>>   Lew wrote:
>>> Read the JLS.
>>
>> You read it. Or reread it. Obviously you missed something or got confused.
>
> Not only did I not miss something nor am confused, I've encountered this in
> practice.
>
> You argue that usually loading immediately precedes initialization. This is
> true. But not always.

Why would it ever be done earlier? The class would just be taking up 
space in main memory but not accomplishing anything useful by being 
there right up until it was about to be used, at which time it would 
need to be initialized.

> The big gaping flaw in your reasoning is

nonexistent.

> I keep quoting and requoting the JLS, section 12.4.1. You should read it.
> You obviously missed something or got confused.

I did not. It is you that did. You seem to think it's possible for 
someone to wait until after they attempt to catch a ball to put their 
ball glove on, and yet have the ball land in a gloved hand if the catch 
is successful. That, right there, is all the evidence we need of your 
confused state.

-- 
public final class JSnarker
extends JComponent
A JSnarker is an NNTP-aware component that asynchronously provides 
snarky output when the Ego.needsPuncturing() event is fired in cljp.

On 18/06/2012 7:48 PM, javax.swing.JSnarker wrote:
> You are confused. You seem to be thinking the order is

Lew quoted the JLS. You ought to be arguing with its words, not his. I 
don't pretend to have dug into the issue far enough to argue it one way 
or another, but what matters isn't what any specific implementation 
does, nor what you or Lew or I thinks the semantics *ought* to be. What 
matters is what the JLS says.

If you start addressing the spec instead of Lew, I'll keep reading.

On 19/06/2012 8:07 AM, David Lamb wrote:
> On 18/06/2012 7:48 PM, javax.swing.JSnarker wrote:
>> You are confused. You seem to be thinking the order is
>
> Lew quoted the JLS. You ought to be arguing with its words, not his. I
> don't pretend to have dug into the issue far enough to argue it one way
> or another, but what matters isn't what any specific implementation
> does, nor what you or Lew or I thinks the semantics *ought* to be. What
> matters is what the JLS says.

And the JLS *clearly* says that initialization *precedes* invocation.

-- 
public final class JSnarker
extends JComponent
A JSnarker is an NNTP-aware component that asynchronously provides 
snarky output when the Ego.needsPuncturing() event is fired in cljp.

In article <jrnqo5$l2o$1@dont-email.me>, -@. says...

> It's just the order that things are done by default.
> 
> Before the code was:
> 
> 1. Load class with initialization.
> 2. Run 'main' method.
> 
> Now, they do the special step of loading without initialization:
> 
> 1. Load class without initialization.
> 2. Verify 'main' method, throw error if not present
> 3. Initialize class
> 4. Run 'main' method.
> 
> You can see how the new method takes more effort.

I'd rather see it as an extension of the bytecode validation mechanism, 
that has to exist anyway:

1. Load bytecode
2. Validate bytecode 
   (exits if there is no 'main' method for the main class)
3. Initialize class
4. Run 'main' method.

Kind regards,
Wanja

-- 
...Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

On 6/20/12 4:11 AM, Wanja Gayk wrote:
> In article<jrnqo5$l2o$1@dont-email.me>, -@. says...
>
>> It's just the order that things are done by default.
>>
>> Before the code was:
>>
>> 1. Load class with initialization.
>> 2. Run 'main' method.
>>
>> Now, they do the special step of loading without initialization:
>>
>> 1. Load class without initialization.
>> 2. Verify 'main' method, throw error if not present
>> 3. Initialize class
>> 4. Run 'main' method.
>>
>> You can see how the new method takes more effort.
>
> I'd rather see it as an extension of the bytecode validation mechanism,
> that has to exist anyway:
>
> 1. Load bytecode
> 2. Validate bytecode
>     (exits if there is no 'main' method for the main class)
> 3. Initialize class
> 4. Run 'main' method.
Actually, the way I understand it is that Loading is immediately 
followed by verification.

How I would expect this to work in reality.

1. Load class
2. get a reference to the static method "void main(String[])"
3. Attempt to execute that reference
    3.1 Causes class initialization before execution.
    3.2 actual execution occurs.

On 22/06/2012 3:54 PM, Daniel Pitts wrote:
> How I would expect this to work in reality.
>
> 1. Load class
> 2. get a reference to the static method "void main(String[])"
> 3. Attempt to execute that reference
>     3.1 Causes class initialization before execution.
>     3.2 actual execution occurs.

That has a problem, though, in that class initialization will happen on 
every method call, resulting in multiple initializations, if it's part 
of "attempt to execute the reference" rather than (as the spec says) 
something the JVM does immediately *before* the first such attempt (or 
other action that requires an initialized class for the action to begin).

I suppose you could change 3.1 to "see if the class is initialized, and 
if not, initialize it", but even that would add to *every method call* 
the overhead of a test-and-branch, and would still be dodgy at best on 
spec-adherence grounds.

-- 
public final class JSnarker
extends JComponent
A JSnarker is an NNTP-aware component that asynchronously provides 
snarky output when the Ego.needsPuncturing() event is fired in cljp.

javax.swing.JSnarker wrote:
> Daniel Pitts wrote:
>> How I would expect this to work in reality.
>>
>> 1. Load class
>> 2. get a reference to the static method "void main(String[])"
>> 3. Attempt to execute that reference
>>     3.1 Causes class initialization before execution.
>>     3.2 actual execution occurs.
> 
> That has a problem, though, in that class initialization will happen on 
> every method call, resulting in multiple initializations, if it's part 

That's not what happens.

> of "attempt to execute the reference" rather than (as the spec says) 
> something the JVM does immediately *before* the first such attempt (or 
> other action that requires an initialized class for the action to begin).

As the spec says, it happens upon the first attempt to execute a static method
(if the class has not already been initialized).

> I suppose you could change 3.1 to "see if the class is initialized, and 
> if not, initialize it", but even that would add to *every method call* 

That is what the spec says to do. As previously linked.

> the overhead of a test-and-branch, and would still be dodgy at best on 
> spec-adherence grounds.

No, it does what it does and adheres to the spec.

See the previously linked references for the details.

-- 
Lew

On 25/06/2012 3:59 PM, Lew wrote:
> javax.swing.JSnarker wrote:
>> Daniel Pitts wrote:
>>> How I would expect this to work in reality.
>>>
>>> 1. Load class
>>> 2. get a reference to the static method "void main(String[])"
>>> 3. Attempt to execute that reference
>>>      3.1 Causes class initialization before execution.
>>>      3.2 actual execution occurs.
>>
>> That has a problem, though, in that class initialization will happen on
>> every method call, resulting in multiple initializations, if it's part
>
> That's not what happens.

I'm not finished. Class initialization will happen on every method call, 
resulting in multiple initializations, *if it's part* of "attempt to 
execute the reference" rather than (as the spec says) something the JVM 
does immediately *before* the first such attempt (or other action that 
requires an initialized class for the action to begin).

> As the spec says, it happens upon the first attempt to execute a static method
> (if the class has not already been initialized).

No, the spec does not say "upon" it says "immediately before".

>> I suppose you could change 3.1 to "see if the class is initialized, and
>> if not, initialize it", but even that would add to *every method call*
>
> That is what the spec says to do. As previously linked.
>
>> the overhead of a test-and-branch, and would still be dodgy at best on
>> spec-adherence grounds.
>
> No, it does what it does and adheres to the spec.

No, what the spec says to do is to implement a statically-compiled call 
this way:

Class is loaded and initialized by statically-compiled code.
Method invocation is simply a bare invokestatic instruction

And a reflective/otherwise non-static call this way:

Check if class is loaded and if not load and verify it.
Check if class is initialized and if not initialize it.
Check if method exists and if not throw an exception, otherwise invoke it.

And this is apparently what earlier versions did.

Surely you aren't suggesting there's a whole raft of if 
(class_is_loaded), if (class_is_initialized), etc. tests before every 
method call in Java 7? Because that would make method calls much slower 
than before, unless you've got some cleverness in place to remove those 
tests from the code once the class is loaded. In other words, something 
more like expanding each call into

load_and_initialize_if_needed(X.class);
invokestatic...

where load_and_initialize_if_needed(X.class) strips out all instances of 
load_and_initialize_if_needed(X.class) from all loaded bytecode as part 
of its own behavior. But that would have all kinds of difficulties of 
its own. At least the JIT might be able to skip over it if X is already 
loaded and an instance is in code it's JITting.

-- 
public final class JSnarker
extends JComponent
A JSnarker is an NNTP-aware component that asynchronously provides 
snarky output when the Ego.needsPuncturing() event is fired in cljp.