Prev: What is the difference between Memory Usage and Heap Usage in my JVM Metrics ?
Next: Java Lead with GUI & SWT | CA | 10+ months
From: Thomas Pornin on 12 Feb 2010 04:43
According to markspace <nospam(a)nowhere.com>:
> True, but something like this should be acceptable, imo:
>
> class MyClass extends YourClass
> {
> public MyClass(int i)
> {
> if ( i > 0)
> {
> super(i);
> } else
> {
> super();
> }
> }
> ...

Actually it would be acceptable to the JVM. The JVM enforces a call to a
superclass constructor (only one call allowed) before accessing members;
it does so with a control-flow analysis which is very similar to the
analysis which figures out types for local variables, and whether local
variables may be accessed before being initialized. If your code could
be translated to bytecode then things would work.

But the Java compiler enforces the JLS rules, which basically guarantee
that whatever the compiler accepts will also be accepted by the JVM.
This is not a strict equality: in that matter, the JLS is stricter than
the JVM rules.

The bright side is that what you suggest would require only some changes
to the compiler, not the JVM and standard classes, and it would be
backward compatible with existing, deployed JVM.


--Thomas Pornin
From: Pitch on 12 Feb 2010 06:28
In article <hl1ao6$i80$2(a)news.albasani.net>, noone(a)lewscanon.com says...
>
> mscottschilling(a)hotmail.com says...
> >> Suppose the call to "super()" needn't be the first line of a constructor.
> >> Discuss the effect and/or legality of the following code:
> >>
> >> class MyClass extends YourClass
> >> {
> >> public MyClass(int i)
> >> {
> >> if ( i > 0)
> >> {
> >> super(i);
> >> }
> >> }
> >> ...
>
> Pitch wrote:
> > If you look at super() as just another method call it's perfectly ok.
>
> Constructor calls are not method calls. So that won't work.


No it won't, but if is was a method it would.

--
stirr your cofee properly
From: Pitch on 12 Feb 2010 06:32
In article <hl1ban$hes$1(a)news.eternal-september.org>,
mscottschilling(a)hotmail.com says...
>
> Pitch wrote:
> > In article <hkvi82$usn$1(a)news.eternal-september.org>,
> > mscottschilling(a)hotmail.com says...
> >>
> >> Suppose the call to "super()" needn't be the first line of a
> >> constructor. Discuss the effect and/or legality of the following
> >> code:
> >>
> >> class MyClass extends YourClass
> >> {
> >> public MyClass(int i)
> >> {
> >> if ( i > 0)
> >> {
> >> super(i);
> >> }
> >> }
> >> ...
> >
> > If you look at super() as just another method call it's perfectly ok.
>
> But it isn't "just another method call", which is the point of the example.
> It's the call that guarantees that the superclass, starting from a
> completely uninitialized state, has been fully initialized. It needs to be
> called precisely once, and that needs to be done before any instance methods
> are called or instance fields accessed.


I though we are talking about changes in the language so it doesn't
mater if it's not a method right now, or if it's allowed only once to be
called. If we are talking of possible changes to Java it could be just
another method and it could be called more than once, ok?

In that case your example works perfectly ok.



--
stirr your cofee properly
From: Patricia Shanahan on 12 Feb 2010 09:39
Pitch wrote:
....
> I though we are talking about changes in the language so it doesn't
> mater if it's not a method right now, or if it's allowed only once to be
> called. If we are talking of possible changes to Java it could be just
> another method and it could be called more than once, ok?
....

That would be the most dangerous possible type of change to the
language, one that changes the semantics of existing syntax.

Currently, the writer of a non-final class can count on exactly one
constructor call per object created, except for "this" calls in the
class code. Multiple constructor calls for the same object, especially
if parameters change between calls, may break invariants such as final
variables being initialized exactly once, and never changing.

Patricia
From: Pitch on 12 Feb 2010 09:59
In article <U5mdnVQN4rmk9ejWnZ2dnUVZ_qSdnZ2d(a)earthlink.com>,
pats(a)acm.org says...
>
> Pitch wrote:
> ...
> > I though we are talking about changes in the language so it doesn't
> > mater if it's not a method right now, or if it's allowed only once to be
> > called. If we are talking of possible changes to Java it could be just
> > another method and it could be called more than once, ok?
> ...
>
> That would be the most dangerous possible type of change to the
> language, one that changes the semantics of existing syntax.

Of course. I don't think this can be changed, I just want people to
agree this restricton should have not be introduced at all.


--
stirr your cofee properly
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12
Prev: What is the difference between Memory Usage and Heap Usage in my JVM Metrics ?
Next: Java Lead with GUI & SWT | CA | 10+ months