Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #15252 > unrolled thread

"Small" Program Challenge.

Back to article view | Back to comp.lang.java.programmer

Contents

  "Small" Program Challenge. Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-06-13 13:45 -0700
    Re: "Small" Program Challenge. Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-06-13 13:52 -0700
      Re: "Small" Program Challenge. Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-06-13 16:17 -0700
        Re: "Small" Program Challenge. glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-06-14 00:16 +0000
      Re: "Small" Program Challenge. Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-06-13 16:19 -0700
        Re: "Small" Program Challenge. Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-06-13 16:24 -0700
      Re: "Small" Program Challenge. markspace <-@.> - 2012-06-13 17:40 -0700
    Re: "Small" Program Challenge. "javax.swing.JSnarker" <gharriman@boojum.mit.edu> - 2012-06-13 21:28 -0400
    Re: "Small" Program Challenge. Roedy Green <see_website@mindprod.com.invalid> - 2012-06-13 20:52 -0700
      Re: "Small" Program Challenge. "Hiram Hunt" <hiramhunt@verizon.net> - 2012-06-14 08:23 -0400
        Re: "Small" Program Challenge. "Hiram Hunt" <hiramhunt@verizon.net> - 2012-06-14 08:30 -0400
      Re: "Small" Program Challenge. Arne Vajhøj <arne@vajhoej.dk> - 2012-06-17 21:17 -0400
    Re: "Small" Program Challenge. Paul Cager <paul.cager@googlemail.com> - 2012-06-14 02:32 -0700
    Re: "Small" Program Challenge. Bent C Dalager <bcd@pvv.ntnu.no> - 2012-06-14 11:29 +0000
    Re: "Small" Program Challenge. Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-06-14 12:50 -0700
    Re: "Small" Program Challenge. Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-06-14 15:49 -0500
    Re: "Small" Program Challenge. Gene Wirchenko <genew@ocis.net> - 2012-06-14 14:56 -0700
    Re: "Small" Program Challenge. Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-06-14 17:02 -0700
    Re: "Small" Program Challenge. Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-06-14 17:09 -0700
    Re: "Small" Program Challenge. Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2012-06-15 22:13 -0700
      Re: "Small" Program Challenge. Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-06-16 12:11 -0700
    Re: "Small" Program Challenge. Wanja Gayk <brixomatic@yahoo.com> - 2012-06-17 15:22 +0200
      Re: "Small" Program Challenge. Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-06-17 15:24 -0700
        Re: "Small" Program Challenge. "javax.swing.JSnarker" <gharriman@boojum.mit.edu> - 2012-06-17 18:25 -0400
          Re: "Small" Program Challenge. Arne Vajhøj <arne@vajhoej.dk> - 2012-06-17 20:31 -0400
            Re: "Small" Program Challenge. "javax.swing.JSnarker" <gharriman@boojum.mit.edu> - 2012-06-17 20:55 -0400
              Re: "Small" Program Challenge. Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-06-17 20:40 -0700
                Re: "Small" Program Challenge. "javax.swing.JSnarker" <gharriman@boojum.mit.edu> - 2012-06-17 23:43 -0400
                Re: "Small" Program Challenge. Lew <noone@lewscanon.com> - 2012-06-17 21:25 -0700
                  Re: "Small" Program Challenge. "javax.swing.JSnarker" <gharriman@boojum.mit.edu> - 2012-06-18 00:45 -0400
                    Re: "Small" Program Challenge. Lew <lewbloch@gmail.com> - 2012-06-18 12:47 -0700
                      Re: "Small" Program Challenge. "javax.swing.JSnarker" <gharriman@boojum.mit.edu> - 2012-06-18 15:57 -0400
                        Re: "Small" Program Challenge. Lew <lewbloch@gmail.com> - 2012-06-18 13:31 -0700
                          Re: "Small" Program Challenge. Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-06-18 16:05 -0500
                            Re: "Small" Program Challenge. Lew <lewbloch@gmail.com> - 2012-06-18 14:18 -0700
                              Re: "Small" Program Challenge. "javax.swing.JSnarker" <gharriman@boojum.mit.edu> - 2012-06-18 19:50 -0400
                          Re: "Small" Program Challenge. "javax.swing.JSnarker" <gharriman@boojum.mit.edu> - 2012-06-18 19:48 -0400
                            Re: "Small" Program Challenge. David Lamb <dalamb@cs.queensu.ca> - 2012-06-19 08:07 -0400
                              Re: "Small" Program Challenge. "javax.swing.JSnarker" <gharriman@boojum.mit.edu> - 2012-06-19 15:26 -0400
                  Re: "Small" Program Challenge. Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-06-18 09:04 -0700
                    Re: "Small" Program Challenge. "javax.swing.JSnarker" <gharriman@boojum.mit.edu> - 2012-06-18 13:09 -0400
                      Re: "Small" Program Challenge. markspace <-@.> - 2012-06-18 11:06 -0700
                        Re: "Small" Program Challenge. "javax.swing.JSnarker" <gharriman@boojum.mit.edu> - 2012-06-18 14:46 -0400
                          Re: "Small" Program Challenge. markspace <-@.> - 2012-06-18 13:22 -0700
                            Re: "Small" Program Challenge. "javax.swing.JSnarker" <gharriman@boojum.mit.edu> - 2012-06-18 19:51 -0400
                        Re: "Small" Program Challenge. Wanja Gayk <brixomatic@yahoo.com> - 2012-06-20 13:11 +0200
                          Re: "Small" Program Challenge. Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-06-22 12:54 -0700
                            Re: "Small" Program Challenge. "javax.swing.JSnarker" <gharriman@boojum.mit.edu> - 2012-06-22 18:30 -0400
                              Re: "Small" Program Challenge. Lew <lewbloch@gmail.com> - 2012-06-25 12:59 -0700
                                Re: "Small" Program Challenge. "javax.swing.JSnarker" <gharriman@boojum.mit.edu> - 2012-06-25 16:49 -0400
                    Re: "Small" Program Challenge. Lew <lewbloch@gmail.com> - 2012-06-18 12:44 -0700
                      Re: "Small" Program Challenge. "javax.swing.JSnarker" <gharriman@boojum.mit.edu> - 2012-06-18 16:01 -0400
                        Re: "Small" Program Challenge. Lew <lewbloch@gmail.com> - 2012-06-18 13:36 -0700
                          Re: "Small" Program Challenge. "javax.swing.JSnarker" <gharriman@boojum.mit.edu> - 2012-06-18 20:01 -0400
                            Re: "Small" Program Challenge. Lew <lewbloch@gmail.com> - 2012-06-18 18:25 -0700
                              Re: "Small" Program Challenge. "javax.swing.JSnarker" <gharriman@boojum.mit.edu> - 2012-06-18 22:01 -0400
                              Re: "Small" Program Challenge. Gene Wirchenko <genew@ocis.net> - 2012-06-18 19:04 -0700
                                Re: "Small" Program Challenge. "javax.swing.JSnarker" <gharriman@boojum.mit.edu> - 2012-06-18 22:12 -0400
                                  Re: "Small" Program Challenge. Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-06-19 12:36 +0000
                                    Re: "Small" Program Challenge. "javax.swing.JSnarker" <gharriman@boojum.mit.edu> - 2012-06-19 15:28 -0400
                                  Re: "Small" Program Challenge. Gene Wirchenko <genew@ocis.net> - 2012-06-19 09:12 -0700
                                    Re: "Small" Program Challenge. "javax.swing.JSnarker" <gharriman@boojum.mit.edu> - 2012-06-19 15:30 -0400
                                      Re: "Small" Program Challenge. Gene Wirchenko <genew@ocis.net> - 2012-06-19 15:04 -0700
                                        Re: "Small" Program Challenge. "javax.swing.JSnarker" <gharriman@boojum.mit.edu> - 2012-06-19 18:23 -0400
                                          Re: "Small" Program Challenge. Gene Wirchenko <genew@ocis.net> - 2012-06-19 15:32 -0700
                                            Re: "Small" Program Challenge. "javax.swing.JSnarker" <gharriman@boojum.mit.edu> - 2012-06-19 19:09 -0400
                                          Re: "Small" Program Challenge. "javax.swing.JSnarker" <gharriman@boojum.mit.edu> - 2012-06-19 19:10 -0400
                                      Re: "Small" Program Challenge. Lew <lewbloch@gmail.com> - 2012-06-19 17:19 -0700
                                        Re: "Small" Program Challenge. "javax.swing.JSnarker" <gharriman@boojum.mit.edu> - 2012-06-19 20:42 -0400
                                          Re: "Small" Program Challenge. Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-06-19 20:01 -0500
                                            Re: "Small" Program Challenge. "javax.swing.JSnarker" <gharriman@boojum.mit.edu> - 2012-06-19 21:12 -0400
                                              Re: "Small" Program Challenge. Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-06-19 20:32 -0500
                                                Re: "Small" Program Challenge. Lew <noone@lewscanon.com> - 2012-06-19 22:01 -0700
                                                  Re: "Small" Program Challenge. "javax.swing.JSnarker" <gharriman@boojum.mit.edu> - 2012-06-20 21:15 -0400
                                                Re: "Small" Program Challenge. "javax.swing.JSnarker" <gharriman@boojum.mit.edu> - 2012-06-20 21:05 -0400
                                                  Re: "Small" Program Challenge. Wanja Gayk <brixomatic@yahoo.com> - 2012-06-23 13:42 +0200
                                                    Re: "Small" Program Challenge. "javax.swing.JSnarker" <gharriman@boojum.mit.edu> - 2012-06-23 12:12 -0400
                                                      Re: "Small" Program Challenge. Wanja Gayk <brixomatic@yahoo.com> - 2012-06-23 23:10 +0200
                                                        Re: "Small" Program Challenge. "javax.swing.JSnarker" <gharriman@boojum.mit.edu> - 2012-06-23 17:14 -0400
                                            Re: "Small" Program Challenge. Lew <noone@lewscanon.com> - 2012-06-19 22:15 -0700
                                              Re: "Small" Program Challenge. Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-06-20 10:34 +0000
                                                Re: "Small" Program Challenge. Lew <lewbloch@gmail.com> - 2012-06-20 10:45 -0700
                                                  Re: "Small" Program Challenge. Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-06-21 08:13 +0000
                                                    Re: "Small" Program Challenge. "javax.swing.JSnarker" <gharriman@boojum.mit.edu> - 2012-06-21 17:18 -0400
                                                      Re: "Small" Program Challenge. Lew <lewbloch@gmail.com> - 2012-06-21 15:30 -0700
                                                        Re: "Small" Program Challenge. "javax.swing.JSnarker" <gharriman@boojum.mit.edu> - 2012-06-21 20:28 -0400
                                                Re: "Small" Program Challenge. "javax.swing.JSnarker" <gharriman@boojum.mit.edu> - 2012-06-20 21:22 -0400
                                              Re: "Small" Program Challenge. "javax.swing.JSnarker" <gharriman@boojum.mit.edu> - 2012-06-20 21:19 -0400

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#15334

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.

[toc] | [prev] | [next] | [standalone]

#15359

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

[toc] | [prev] | [next] | [standalone]

#15361

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.

[toc] | [prev] | [next] | [standalone]

#15362

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.

[toc] | [prev] | [next] | [standalone]

#15367

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

[toc] | [prev] | [next] | [standalone]

#15368

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.

[toc] | [prev] | [next] | [standalone]

#15370

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).

[toc] | [prev] | [next] | [standalone]

#15371

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.

[toc] | [prev] | [next] | [standalone]

#15372

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

[toc] | [prev] | [next] | [standalone]

#15373

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.

[toc] | [prev] | [next] | [standalone]

#15387

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

[toc] | [prev] | [next] | [standalone]

#15388

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.

[toc] | [prev] | [next] | [standalone]

#15392

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:
<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 first 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 variable (§4.12.4).

- T is a top level class (§7.6), and an assert statement (§14.10) lexically nested within T (§8.1.3) is executed.

A reference to a static field (§8.3.1.1) causes initialization of only the class or interface that actually declares it, even though it might be referred to through the name of a subclass, a subinterface, or a class that implements 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."

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

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

> > False premise, unreliable conclusion.
> 
> On your part, Lew.
> 
> > Loading does not imply initialization.
> 
> 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.
> 
> 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.

Note - that is two steps, not one.

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

It can attempt to call 'foo()' before the initializer has executed. This is 
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() 
> 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 

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

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

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#15394

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

[toc] | [prev] | [next] | [standalone]

#15396

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

[toc] | [prev] | [next] | [standalone]

#15399

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.

[toc] | [prev] | [next] | [standalone]

#15398

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.

[toc] | [prev] | [next] | [standalone]

#15411

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.

[toc] | [prev] | [next] | [standalone]

#15424

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.

[toc] | [prev] | [next] | [standalone]

#15379

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.

[toc] | [prev] | [next] | [standalone]

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web