RE: [Jxcl-devel] RE: So what's the status of JXCL

[King D. <dal...@th...>]

> -----Original Message-----
> From: Jim Dixon [mailto:jd...@di...]
> 
> On Sat, 28 Feb 2004, King Dale wrote:
> 
> > > > You'll see that I submitted a patch that fixes the class path
> > > > handling to work on Windoze.
> > >
> > > ? I haven't seen any patch.  Where did you send it?
> >
> > I uploaded it as a patch on Sourceforge:
> >
> > http://sourceforge.net/tracker/?group_id=92728&atid=601791
> 
> No files were attached.  There was no patch.
> 
> I would be very interested in seeing your proposed changes.  Can you
> attach the patch to a reply to this email?

Oops, apparently, I forgot to actually click the little box that said attach
the file. I've deleted it off my machine here at work. I'll upload it
tonight at home.

I'm interested to hear your thoughts on the ability to mark code as
unreachable.

I've been studying the code and think I have a grasp. I think we can fix the
try-finally problems. It appears one problem is that the Eclipse compiler
generates something entirely different than the Sun compiler. I think what
javac generates has also changed from one version to another. Looking at
this old article from 1997 it describes the code that Eclipse generates:

http://www.javaworld.com/javaworld/jw-02-1997/jw-02-hood.html

So something has changed in javac land. What I see from javac duplicates the
code from the finally clause in multiple places if it is small and uses a
subroutine if it is longer. Eclipse seems to always use the subroutine. When
javac uses the jsr, it duplicates the jsr in all paths that exit the try
block gracefully then does a goto to the code after the try. Eclipse moves
the jsr to the end and has all those paths do a goto to the jsr which then
falls through to the code after the try.

I'll try to do a bug search in the bug database to see if I can learn more.
I'm guessing that they did this to make life easier for HotSpot to figure
things out, which makes like more complicated for those trying to figure out
control flow with the output of other compilers.
-- 
 Dale King