«

Hi,

I'm in the process of writing a custom compiler for my own language
that will target the JVM. I'm just getting started but I've got a
ClassInfo file successfully streamed. I have a question for anyone who
knows.

Apparently I have to define my own constructor, even if it doesn't do
anything. I seem to need to define an <init> method with signature
"()V", otherwise myClass.newInstance() throws InstantiationException.

Anyway, there's nothing in <init> except a return statement. So I get
this exception:

java.lang.VerifyError: (class: Dan, method: <init> signature: ()V)
Constructor must call super() or this()

So apparently I have to call Object.<init>() too. Makes sense, but I
thought you could never call <init> yourself. Is there a trick here?

Thanks.
Dan

"daniel.w.gelder" <> wrote:

[I don't have much knowledge to offer. Instead, let me
play potted plant here and see if it helps.]

> Apparently I have to define my own constructor,
> even if it doesn't do anything.

That shouldn't be the case, if you don't explicitly
define a parameterless void constructor, the system
creates a default one for you which calls super()
and returns. In fact, creating such a constructor
and making it private so it can't be invoked is one
frequently seen trick to prevent the system from
supplying such a default constructor unbeknownst to
you and having it invoked where you had no such
intention.

> I seem to need to define an <init> method with signature
> "()V", otherwise myClass.newInstance() throws InstantiationException.

1) Are those angle brackets a literal part of the name "<init>"?
Is that some template parameter naming, or what?

2) What does the "V" in "()V" mean? "Void return?"

> Anyway, there's nothing in <init> except a return statement. So I get
> this exception:

> java.lang.VerifyError: (class: Dan, method: <init> signature: ()V)
> Constructor must call super() or this()

Is that a compile time error, or a run time error? It looks
like a runtime invocation of MyClass.init() has encountered
a problem with a constructor for MyClass being missing, but
as noted above, one should be created (and then invoked) by
default if you don't prevent that happening.

> So apparently I have to call Object.<init>() too. Makes sense, but I
> thought you could never call <init> yourself. Is there a trick here?

I'm still confused by those angle brackets, but it isn't "init"
that you are being told to call, you are being told, at a default
invocation of MyClass.init() at startup time, that you haven't
yet instantiated an object from MyClass, thus there is no object
whose instance (as opposed to static) method init() can be invoked.

A common pattern is to have your main routine inherit from
applet, to instance applet in main(...), then to invoke init()
from that instance.

class MyClass extends applet
{
private static MyClass mc = null;

public MyClass() // constructor
{
super();
}
void main(...) // must exist in some class of your app
{
mc = new MyClass();
mc.init(); // yes, you _can_ call init() yourself
// ... do more stuff
}
void init()
{
// initialize stuff for instance object mc of MyClass.
}
}

Or something vaguely like that. Until I figure out how
to boot Debian Linux using grub on and from an external
drive (to leave the internal drive's MS-Windows garbage
unmolested) on my replacement laptop, I'm temporarily
out of the Java business.

FWIW

xanthian.


--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Yeeeeeaaahhhkaayyyy.....try re-reading my first sentence.

Thanks anyway though for replying.
Dan

wrote:

> Apparently I have to define my own constructor, even if it doesn't do
> anything.

Yup. There has to be a constructor or there's nothing there for other code to
call.


> I seem to need to define an <init> method with signature
> "()V", otherwise myClass.newInstance() throws InstantiationException.

That's correct.


> So apparently I have to call Object.<init>() too. Makes sense, but I
> thought you could never call <init> yourself. Is there a trick here?

"Rules change in the reaches"[*]. I.e. this is bytecode land -- a high-level,
mostly-dynamic, mostly-OO programming language with an interesting hybrid
static/dynamic type system. The rules you learned in Java are only a rough
approximation to the rules which apply here.

In this case you are correct. You have to supersend <init> (or use some other
flavour of <init>). BTW, if you do supersend then it has to be an
invokespecial instruction, invokevirtual isn't allowed here.

The JVM spec is irritatingly incomplete, occasionally ambiguous, and even
within those limits, not especially well-written, but it does cover this stuff.
You should probably read the whole thing at least once (if you haven't
already). Much of it is a non-normative (and largely irrelevant) rehashing of
the JLS. Resign yourself to the idea that you are going to be reading the
/other/ bits over and over again

-- chris
[*] Or, if you prefer, "You're not in Kansas anymore". Or even, "Welcome to
the /real/ world"

I seem to have gotten it at last. I'm kind of surprised how much actual
bytecode javac always had to make for

public class Test {
}

It uses a lot more space than the original file, that's for sure. Oh
well. Time to optimize my compiler frontend and do a little coding.

Dan

Kent Paul Dolan wrote:
> "daniel.w.gelder" <> wrote:
>
> [I don't have much knowledge to offer. Instead, let me
> play potted plant here and see if it helps.]
>
>
>>Apparently I have to define my own constructor,
>>even if it doesn't do anything.
>
>
> That shouldn't be the case, if you don't explicitly
> define a parameterless void constructor, the system
> creates a default one for you which calls super()
> and returns. In fact, creating such a constructor
> and making it private so it can't be invoked is one
> frequently seen trick to prevent the system from
> supplying such a default constructor unbeknownst to
> you and having it invoked where you had no such
> intention.
....

I think Daniel is using bytecode, rather than Java, as his target
language, so there will be things a Java compiler would do automatically
that he needs to do explicitly.

However, this does suggest a procedure for solving his problem:

1. Write a Java class with no specified superclass and no constructor
declaration.

2. Compile it.

3. Examine the bytecode. See what the compiler generates to represent
the default constructor. It will contain a call to the Object constructor.

4. Make the new compiler generate the same thing.

Patricia

<> wrote in message
news: ups.com...
> Hi,
>
> I'm in the process of writing a custom compiler for my own language
> that will target the JVM. I'm just getting started but I've got a
> ClassInfo file successfully streamed. I have a question for anyone who
> knows.

I know (obviously) nothing about your language, but I'm wondering:

Might it be easier to use Java as an intermediate language? That is,
generate Java from your language and then use javac to compile that?

As Chris points out, the JVM spec is irritatingly incomplete about the
precise requirements for bytecode, while the JLS and assorted other books
are far better at explaining Java. And should you run into trouble, you'll
have a much easier time debugging your generated Java than debugging
bytecode directly.

Mike Schilling wrote:

> Might it be easier to use Java as an intermediate language? That is,
> generate Java from your language and then use javac to compile that?

Or maybe an intermediate level technology like Javassist.

Just mentioning options; personally I'd pop a beer and get stuck right into the
bytecode

-- chris

In addition to the JVM spec, you can also check Bill Venners's "Inside
the JVM". It's out of print, but you might find a copy in your library.

Dimitar

In addition to the JVM spec, you can also check Bill Venners's "Inside
the JVM". It's out of print, but you might find a copy in your library.

Dimitar