Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #15252 > unrolled thread
| Started by | Daniel Pitts <newsgroup.nospam@virtualinfinity.net> |
|---|---|
| First post | 2012-06-13 13:45 -0700 |
| Last post | 2012-06-20 21:19 -0400 |
| Articles | 20 on this page of 88 — 17 participants |
Back to article view | Back to comp.lang.java.programmer
"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 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | "javax.swing.JSnarker" <gharriman@boojum.mit.edu> |
|---|---|
| Date | 2012-06-18 13:09 -0400 |
| Message-ID | <jrnnc5$j6n$2@speranza.aioe.org> |
| In reply to | #15379 |
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.
[toc] | [prev] | [next] | [standalone]
| From | markspace <-@.> |
|---|---|
| Date | 2012-06-18 11:06 -0700 |
| Message-ID | <jrnqo5$l2o$1@dont-email.me> |
| In reply to | #15382 |
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.
[toc] | [prev] | [next] | [standalone]
| From | "javax.swing.JSnarker" <gharriman@boojum.mit.edu> |
|---|---|
| Date | 2012-06-18 14:46 -0400 |
| Message-ID | <jrnt1j$2hb$1@speranza.aioe.org> |
| In reply to | #15383 |
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.
[toc] | [prev] | [next] | [standalone]
| From | markspace <-@.> |
|---|---|
| Date | 2012-06-18 13:22 -0700 |
| Message-ID | <jro2lm$cin$1@dont-email.me> |
| In reply to | #15384 |
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.
[toc] | [prev] | [next] | [standalone]
| From | "javax.swing.JSnarker" <gharriman@boojum.mit.edu> |
|---|---|
| Date | 2012-06-18 19:51 -0400 |
| Message-ID | <jroeu9$cs8$3@speranza.aioe.org> |
| In reply to | #15390 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Wanja Gayk <brixomatic@yahoo.com> |
|---|---|
| Date | 2012-06-20 13:11 +0200 |
| Message-ID | <MPG.2a4bce255b35099098970d@202.177.16.121> |
| In reply to | #15383 |
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 ---
[toc] | [prev] | [next] | [standalone]
| From | Daniel Pitts <newsgroup.nospam@virtualinfinity.net> |
|---|---|
| Date | 2012-06-22 12:54 -0700 |
| Message-ID | <c44Fr.19147$8b4.8802@newsfe08.iad> |
| In reply to | #15507 |
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.
[toc] | [prev] | [next] | [standalone]
| From | "javax.swing.JSnarker" <gharriman@boojum.mit.edu> |
|---|---|
| Date | 2012-06-22 18:30 -0400 |
| Message-ID | <js2rlu$1uq$1@speranza.aioe.org> |
| In reply to | #15523 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2012-06-25 12:59 -0700 |
| Message-ID | <8ac53825-c606-4839-8758-43c99555af85@googlegroups.com> |
| In reply to | #15534 |
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
[toc] | [prev] | [next] | [standalone]
| From | "javax.swing.JSnarker" <gharriman@boojum.mit.edu> |
|---|---|
| Date | 2012-06-25 16:49 -0400 |
| Message-ID | <jsais7$bh8$1@speranza.aioe.org> |
| In reply to | #15586 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2012-06-18 12:44 -0700 |
| Message-ID | <c4f82855-8df5-492a-a26d-a8bcebcfcaf1@googlegroups.com> |
| In reply to | #15379 |
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ø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.
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 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
How, exactly?
> 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.
Java never required initialization upon load, and in fact was very specific about
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 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, and an assert statement (§14.10) lexically nested within T is executed.
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."
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.
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 solution.
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 also violate
Java 6, and that it worked was a bug.
Perhaps if you could quote the exact differences in wording to which you refer?
--
Lew
[toc] | [prev] | [next] | [standalone]
| From | "javax.swing.JSnarker" <gharriman@boojum.mit.edu> |
|---|---|
| Date | 2012-06-18 16:01 -0400 |
| Message-ID | <jro1f5$edb$1@speranza.aioe.org> |
| In reply to | #15386 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2012-06-18 13:36 -0700 |
| Message-ID | <c5fbd690-1af5-4427-844f-744ad0991c53@googlegroups.com> |
| In reply to | #15389 |
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
[toc] | [prev] | [next] | [standalone]
| From | "javax.swing.JSnarker" <gharriman@boojum.mit.edu> |
|---|---|
| Date | 2012-06-18 20:01 -0400 |
| Message-ID | <jrofgk$ec6$1@speranza.aioe.org> |
| In reply to | #15393 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2012-06-18 18:25 -0700 |
| Message-ID | <cbe27a00-af3b-48f0-82c3-c0f8ab30e1d4@googlegroups.com> |
| In reply to | #15401 |
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
[toc] | [prev] | [next] | [standalone]
| From | "javax.swing.JSnarker" <gharriman@boojum.mit.edu> |
|---|---|
| Date | 2012-06-18 22:01 -0400 |
| Message-ID | <jromhk$qq9$1@speranza.aioe.org> |
| In reply to | #15402 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Gene Wirchenko <genew@ocis.net> |
|---|---|
| Date | 2012-06-18 19:04 -0700 |
| Message-ID | <o9nvt71lop4bii7haes51im3884d2ts03k@4ax.com> |
| In reply to | #15402 |
On Mon, 18 Jun 2012 18:25:13 -0700 (PDT), Lew <lewbloch@gmail.com>
wrote:
[snip]
>I keep quoting and requoting the JLS, section 12.4.1. You should read it.
>You obviously missed something or got confused.
javax.swing.JSnarker:
Either Lew is correct here, or he is not.
If he is correct, then you should listen to him.
If he is not and since he is a fairly on-the-ball sort, then it
is a confusing area, and you would be better off to not code in such a
way as to depend on such a confusing area.
The C equivalent of your argument is someone arguing that void
main() works on his system. (main() is defined in the C standard as
returning int on a hosted system (i.e. running under an OS).)
Sincerely,
Gene Wirchenko
[toc] | [prev] | [next] | [standalone]
| From | "javax.swing.JSnarker" <gharriman@boojum.mit.edu> |
|---|---|
| Date | 2012-06-18 22:12 -0400 |
| Message-ID | <jron75$s6k$1@speranza.aioe.org> |
| In reply to | #15404 |
On 18/06/2012 10:04 PM, Gene Wirchenko wrote: > On Mon, 18 Jun 2012 18:25:13 -0700 (PDT), Lew <lewbloch@gmail.com> > wrote: > > [snip] > >> I keep quoting and requoting the JLS, section 12.4.1. You should read it. >> You obviously missed something or got confused. > > javax.swing.JSnarker: > > Either Lew is correct here, or he is not. > > If he is correct, then you should listen to him. > > If he is not and since he is a fairly on-the-ball sort, then it > is a confusing area, and you would be better off to not code in such a > way as to depend on such a confusing area. > > The C equivalent of your argument is someone arguing that void > main() works on his system. (main() is defined in the C standard as > returning int on a hosted system (i.e. running under an OS).) Void main() is not supported by the C specification. However, the quoted section of the JLS clearly states that initialization precedes invocation (which is also just plain common sense). -- 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]
| From | Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> |
|---|---|
| Date | 2012-06-19 12:36 +0000 |
| Message-ID | <slrnju0sie.u9l.avl@gamma.logic.tuwien.ac.at> |
| In reply to | #15405 |
javax.swing.JSnarker <gharriman@boojum.mit.edu> wrote:
> However, the quoted
> section of the JLS clearly states that initialization precedes
> invocation (which is also just plain common sense).
Obviously, the JVM can determine availability of a static method
in a class that is loaded, but not yet initialized. Thus, during
bootstrapping the application, it *can* load the specified class,
notice lack of an appropriate main method, and skip initialization,
as it would be obviously futile for the resulting task of throwing
an exception.
Your parable about catching a ball with or without gloves falls
flat, because the JVM can freeze the ball mid-air, while calculating
its chances to catch it and then put the gloves on only in positive
case.
I must admit, I liked the old behaviour for the sake of really simple
almost boilerplate-lean way of testing some trivial bits of code.
class Test { static { /* code */ } }
(admittedly, the enum-approach never occurred to me)
I wouldn't even care for the method-lookup exception in those cases.
Otoh, I can also understand that this doesn't win over the bare fact
that non-existence of a static method can be detected without initia-
lizing the class, and thus still doing so is against the spirit of
lazy initialization.
[toc] | [prev] | [next] | [standalone]
| From | "javax.swing.JSnarker" <gharriman@boojum.mit.edu> |
|---|---|
| Date | 2012-06-19 15:28 -0400 |
| Message-ID | <jrqjt6$e2b$2@speranza.aioe.org> |
| In reply to | #15412 |
On 19/06/2012 8:36 AM, Andreas Leitgeb wrote: > javax.swing.JSnarker <gharriman@boojum.mit.edu> wrote: >> However, the quoted >> section of the JLS clearly states that initialization precedes >> invocation (which is also just plain common sense). > > Obviously, the JVM can determine availability of a static method > in a class that is loaded, but not yet initialized. Not relevant. > Thus, during bootstrapping the application, it *can* load the > specified class, notice lack of an appropriate main method, and skip > initialization, as it would be obviously futile for the resulting > task of throwing an exception. The spec doesn't specify any such behavior. Checking for existence of a method is part of invoking a method (when the invocation is reflective rather than compiled), and invoking a method follows initialization. > Your parable about catching a ball with or without gloves falls > flat, You are incorrect. > Otoh, I can also understand that this doesn't win over the bare fact > that non-existence of a static method can be detected without initia- > lizing the class, and thus still doing so is against the spirit of > lazy initialization. Even were the spec to allow it, optimizing for the rare case (main method not found) rather than for the common case is always premature optimization, and premature optimization is the root of all evil. -- 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]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.lang.java.programmer
csiph-web