public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
* Newbie questions
@ 2000-04-01  0:00 Maury Markowitz
  2000-04-01  0:00 ` Tom Tromey
  0 siblings, 1 reply; 9+ messages in thread
From: Maury Markowitz @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

Hi,

  I'm an Obj-C developer (using gcc) over on the OS-X platform and  
I'm looking for migration and exit strategies for both myself and  
other developers in our market space.  Apple's "commitment" to Obj-C  
is, well, let's call it "unclear".  I'm both a compiler tech and Java  
newbie, so I'll ask for your forgiveness in advance if some of these  
questions are complete no-brainers.

  First and foremost I'm curious about the ability for gcj's  
compiled code to be used as libraries for Obj-C code on top.  IE, if  
I were to use gcj and it's associated libs, what sort of work effort  
would it be to have them work as Obj-C libraries?  Is library format  
an issue at all? (I'm assuming not, but I'll ask to be sure) Is the  
main issue going to be supplying a selection of wrappers in the form  
of .h files?  It "feels" like there is a runtime changed needed to  
Obj-C, and I'm curious if anyone could comment on the level of change  
needed, if any?

  The other question I have relates to extensions and the legality  
thereof.  We Obj-C developers have come to love the language's  
flexibility in terms of "weak" typing and notably in the form of  
categorization.  It seems to me that if you're going to  
native-compile code anyway, extensions like this to Java would no  
longer break it's security orientation.  Would it be possible to  
create a sub-standard, say "Obj-J", that would add in these features  
without ending up on someone's (like Sun's) *&%# list?

  This isn't quite as important to me, if I could use Obj-C over  
gcj's libs this may be a non-issue anyway.  I ask simply because  
there may be uses who wish to stay completely in the Java syntax (for  
good reasons) but sill have access to some of the power of  
categorization, proxies, etc.

  BTW, kudos to all involved in this project.  This is exactly the  
sort of practical response to the Java hype that I think the market  
needs.  I'm still experimenting, but I think gcj's potential for  
mixing my compiled code against bytecode and compiled libs may be  
just the solution I'm (and I think many others) are looking for.

Maury

^ permalink raw reply	[flat|nested] 9+ messages in thread
* Re: Objective-C vs. gcj (was: Re: Newbie questions)
@ 2000-04-01  0:00 Maury Markowitz
  2000-04-01  0:00 ` Jon Olson
  2000-04-01  0:00 ` Jeff Sturm
  0 siblings, 2 replies; 9+ messages in thread
From: Maury Markowitz @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: java-discuss

> with GCC in the gcc/objc directory) and is useless without it.  It 
> handles all the method dispatching and dynamic binding required by the 
> Obj-C language.

  Right.  That method dispatching and dynamic binding is rather  
similar to Obj-C's though, and not by coincidence.

> These two libraries can probably coexist in one address space, but that 
> isn't very useful unless Obj-C code can call Java code, which it can't 

  Exactly.

> strongly suspect the answer has mostly to do with the popularity of C++ 
> and relative obscurity of Obj-C, though there may be technical  
issues as
> well.

  And of course the popularity of Java and "impopularity" of Obj-C  
is why I'm here.

> some other language could share the libgcj runtime.  If the Obj-C
> frontend is to have a meaningful existence in the future, it should 
> probably abandon its current runtime and embrace libgcj.

  Right, this is exactly what I am interested in.  Essentially if a  
little bit of API was added to the libgcj runtime I think you'd have  
enough support to also run Obj-C code with the same runtime.  Now you  
have a lib that works on two languages.  This would need some  
changes in the Apple base class, NSObject, but I'd want to do that  
anyway to take advantage of reflection and gc, which is LONG overdue  
in Obj-C anyway.

  But what exactly would this entail?  I'm not a compiler guy  
although my boss is pretty good at this, and is pretty excited by  
these prospects as well.  What I'm trying to fathom is just what  
level of effort would be required.  If I can get a good list of  
"here's the tasks", I can take that and start working.

  A guess right now...

1) Obj-C has a "2nd guess" attempt to deliver messages to objects.   
This is done via a combination of support in Obj-C's runtime and some  
minor support in the root object.  Essentially when a method is  
called on an object it does a lookup in the same way that Java does.  
If that method is not supported the runtime then creates a new object  
(in Obj-C this is an NSInvocation object) and then passes that  
invocation back into the original object, calling "forwardInvocation"  
I believe.  NSObject's default behaviour is to raise a "method not  
supported" exception, but if you override that method you get the  
invocation (which is a wrapper of the name of the method and the  
types of arguments) so you can break it out and do something with it,  
like forward it to another object.

2) Obj-C includes categories.  This would require a new function in  
the runtime to allow function pointers in the method lookup table to  
be replace with new function pointers, and the addition of new  
methods into the dispatch table.

3) Obj-C includes the concept of a "Selector" (type SEL) which is a  
unique string associated with any particular method.  This is used   
to uniquely identify object/message names.

4) Obj-C allows for one object to replace some other.  This would  
require API in the runtime to deal with this.  Essentially it means  
that all calls to "MyObject" simply get forwarded to "MyOtherObject".

5) One missing piece from both runtimes is the ability to re-link  
objects at runtime.  All this means is that you want to be able to  
push a class out and then back in at runtime (Java kinda supports  
this already).  Combined with some support at the IDE level, this  
allows for "link and go", you recompile just that object and keep  
running your app - this makes debugging a lot more fun!

  Changes to the Obj-C compiler would also be needed, to call any  
different API in the runtime, and the Apple object set would likely  
need some updates to support it.  However one thing I would want was  
a re-write of these classes to make sure they are directly callable  
from Java anyway.

> handy.  The Object class differs somewhat from java.lang.Object, but 
> that could be possibly be remedied by making Object a subclass of
> java.lang.Object, or maybe even introduce a new root class.

  Actually for my needs I'd be changing NSObject, although I see the  
benefit here.  I'm curious though, does anyone outside the OS-X  
world actually use Obj-C for deployed apps any more?

> He means Objective-C doesn't do any compile-time binding or even
> checking of method invocations.  Every instance variable can be  
declared
> as "id" which is equivalent to Java's java.lang.Object class.  If a 

  Although this has very practical reasons for existing. It makes  
the creation of interactive GUI editors far easier for instance.

> Note that the Java _language_ is strongly typed though bytecode is 
> not... all names are dynamically resolved from bytecode, just as in 
> Obj-C.

  Which is interesting if you think about it.

> categories.  It's not the same as inheritance, somehow.  Sort of like 
> peer objects, as in java.awt, only more transparent.

  Exactly.  The functionality is doable with Java, but it's simply  
WAY easier and invisible under Obj-C.

> Objective-C has a neat feature which makes it extremely simple to write 
> delegate classes.  The runtime attempts to dispatch a method invocation 
> [snip]
> Similar tricks could be performed with Java reflection, I'd guess. 

  That's interesting.  Ahhh, do you mean that we could use the  
reflection API in the runtime to see if the method is there and then  
re-dispatch?  Hmmm, that might be a "better" (as in leveraging  
existing functionality) solution that Obj-C's in fact.

Maury

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2000-04-01  0:00 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-04-01  0:00 Newbie questions Maury Markowitz
2000-04-01  0:00 ` Tom Tromey
2000-04-01  0:00   ` Objective-C vs. gcj (was: Re: Newbie questions) Jeff Sturm
2000-04-01  0:00     ` Per Bothner
2000-04-01  0:00     ` Kresten Krab Thorup
2000-04-01  0:00       ` [OFFTOPIC] " Joerg Brunsmann
  -- strict thread matches above, loose matches on Subject: below --
2000-04-01  0:00 Maury Markowitz
2000-04-01  0:00 ` Jon Olson
2000-04-01  0:00 ` Jeff Sturm

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).