dotgnu-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DotGNU]Java compiler , more news


From: Rhys Weatherley
Subject: Re: [DotGNU]Java compiler , more news
Date: Sat, 26 Apr 2003 06:42:02 +1000
User-agent: KMail/1.4.3

On Saturday 26 April 2003 03:51 am, Gopal V wrote:
> Hi,
>       I'm uploading my patches for the java compiler to:

More good news!  Hooray!

> Also in case I forget , I am using __in__ and __out__ for the System.in
> field for the java.lang class. Replace in assembly code with SED :-(.
> Terribly uportable, I need Rhys's advice here.

I assume that the problem is writing C# code that exports/uses the "in" and 
"out" definitions.  And hassles occur because they are keywords in C#.

The C# language already has a solution for this: use "@in" instead of "in".  
i.e. any keyword can be turned into a normal identifier by prefixing it with 
"@".

> Last but not least, an unsolvable issue. All exceptions are inherited from
> System.Exception , All java classes from java.lang.Object .. and no
> multiple inheritance (which is a good thing ;-) . So currently

It may be possible to work around this using wrappers.  e.g.

- java.lang.Object inherits from System.Object
- java.lang.Throwable inherits from java.lang.Object
- When an exception is thrown, it is wrapped in a System.Exception
  using a "JavaExceptionHelper" class as follows:

public class JavaExceptionHelper : Exception
{
    public java.lang.Throwable e;
    public JavaExceptionHelper(java.lang.Throwable e) { this.e = e; }
};

This wrapper object is thrown, and picked up using the normal mechanisms.

The drawback is that you'll need to do the catch logic yourself in the 
compiler.  You'll need to catch "JavaExceptionHelper", unpack the wrapper, 
filter it yourself to see if it applies to any of the catch clauses, and use 
"rethrow" if it doesn't to pass it further up the stack.  (It's messy, but 
not impossible to implement).

Does anyone know how Microsoft's J# handles this?  Or if they do at all?

Anyway, we can solve this problem later.  Let's get the rest of the language 
in place first.

> I think it's ripe for inclusion into cvs ... I'll try to show up for
> tomorrow's first meet and talk it out with Rhys and others concerned.

Looking forward to it.

> Also I'm pleased to
> note that ilrun is offering similar performance to kaffe in Total
> Execution Time for the SieveBenchmark I ported off pnetmark.

Fantastic!  I was hoping that the CVM/unroller system would give reasonable 
performance comparable with JVM's, completely undoing the effect of the 
polymorphic IL instruction set.  And this confirms it.

Cheers,

Rhys.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]