Now at http://www.gnustep.org
Week ending 10 June 2000
- gstep-base (Foundation)
-
Many changes for improved portability to non-unix systems.
- NSBundle - much updated to use NSFileManager rather than unix calls for handling files/directories.
- NSString - new indexOfString method, range comparison fencepost bugfix.
- NSByteOrder functions now used throughout for portability.
- Fix includes for WIN32 throughout
- gstep-gui (AppKit frontend)
-
- When loading a gmodel, call awakeFromNib if an object in the gmodel doesn't respond to awakeFromModel.
- gstep-xdps (DPS backend)
-
- Faster, simpler font initialization - only loads the fonts that are asked for.
- Better checking of NeXT extensions
- Image drawing improvments (images now draw twice as fast).
- tests (testsuite for base library)
-
- Added more tests for ranged comparisons of strings.
- Updated README file.
- documentation
-
- Nicola Pero has been working on tutorials - you can see his GNU make tutorial at http://gnustep.8m.com
- gstep-java (interface to Java language)
-
- Nothing in CVS yet but Nicola says -
Mainly, people will use the GNUstep Java Interface in one of two ways:
1) You can link a GNUstep application against the GNUstep Java Interface library and a Java Virtual Machine library of your choice. When you do this, you can then start a Java Virtual Machine inside your application simply invoking
[NSJavaVirtualMachine startDefaultVirtualMachine];
Then, you will be able to 'load' a java class (which should be in your classpath) inside the objective-C runtime, with some function or API still to be determined, but which could be something as easy as
[NSJavaVirtualMachine exposeJavaClass: @"myJavaClass"];
[This will dynamically create a class of proxy objects to myJavaClass, and all its superclasses, and insert them in the objc runtime]. At this point, you can create an object of class "myJavaClass" by simply using:
Class class = NSClassFromString (@"myJavaClass"); id obj = AUTORELEASE ([[class alloc] initWithString: @"Test"]);
This will create a proxy in the objc space to a java object of class myJavaClass. 'initWithString: @"Test"' will be translated into the java constructor myJavaClass ("Test");.
You will be able to use the proxy exactly as an objc object, and use all its java methods (with the reasonable automatic conversion of names). You can pass arguments and use return arguments as if it were a real GNUstep object.
There should be some mechanism, still to be determined, by which you can choose for each java class you want to expose, how objc selectors are going to be mapped to java methods [if you want to have a different mapping than the automatic one]. Probably some 'configuration' file somewhere in the GNUstep directory, in the form of a property list, which would be read by the library upon setting up the interface.
This first way of using the Java GNUstep Interface will be nice also because you don't need a shared libobjc to use it in this way.
2) [You need a shared libobjc to do this]. The GNUstep Java Interface provides some java classes (gnu.gnustep.base.NSObject and some other classes to access the interface functionality). You put these classes in your classpath, then you can simply create an object of these classes. Once you try to do it, a static initializer in these classes loads GNUstep and the GNUstep Java Interface as a native library, and sets all the interface up.
A simple interface to send message to objc objects of arbitrary classes will then be provided and accessible using the auxiliary interface java classes (gnu.gnustep.java.NSObjCRuntime, and others).
[There could still be some little technical tricks on the java side when loading multiple native libraries which need to talk to each other. Anyway, these will be sorted out (perhaps the solution could be as drastic as needing to load all the GNUstep libraries you want to access together), but since I have not yet done it, perhaps the following description will not be an accurate description of how the final version will work.]
At this point, any objective-C library which you have already wrapped in java will be accessible exactly as a java library. That is, you can simply instantiate objects of the class, and invoke methods, exactly as if it were a java class.
Wrapping an objective-C library will be very simple if you are only wrapping 'standard' things. We will have an automatic wrapper, as Apple has, but this is just the last cherry to put on the cake, in the sense that the real difficult part is the interface internals. Once they work reliably, writing the wrapper will be easy. Also, it will be perfectly possible to wrap libraries by hand. I am not assuming that anybody will do it by hand except me, but the first libraries I will try to interface will definitely be wrapped by hand, also because that will help me designing better the way a library needs to be wrapped.
The only trick in all this stuff is when you pass a pure java object to objc space as a weak reference.
Say that you have your java class called Controller. You use the GNUstep GUI from Java to write your GUI app. You want to set an object of your Controller class as the NSApplication delegate. Then, you would do:
NSApplication app = NSApplication.sharedApplication ();
app.setDelegate (myController);
This java code will crash later on, and there is nothing we can do to stop it crashing without some help from the programmer. [The problem is that setDelegate: is exceptional in that it does not retain its argument. When you pass myController to objc space, an autoreleased proxy is created; this proxy is then not retained by any objc object, and so it is released when the autorelease pool is emptied. This is all perfectly correct, if we do differently, we leak objects in normal situations.]
Apple bridge documentation instructs programmers to create an auxiliary objc NSArray, and to add to the array all objects that you need to pass as weak references into objc space (as in this case).
We can't improve much on this solution - but at least I think we should provide facilities to create the array internally and then the programmer would simply write:
NSApplication app = NSApplication.sharedApplication (); NSObjCRuntime.retain (myController); app.setDelegate (myController);
Before passing a java object to objc space as a weak reference (one that it is not retained on objc space) you would use NSObjCRuntime.retain (Object); - when you are finished, you use something like NSObjCRuntime.release (Object);.
I can think of a different solution, which could be completely opaque to the programmer (she would not see any difference between a method taking a normal argument or a weak argument), but would require the person wrapping the library to mark methods storing a weak reference to the argument as special, so that the wrapper can insert extra code to manage it (which would do a dirty job). It's a bit muddy to implement, and it's not worth thinking about it yet.
I hope to reach a good point with the java forwarding today, then I'll try to assemble all the pieces together in next days.
As soon as I can do something really exciting - manually wrap an objc library and/or use java libraries directly from objc in some interesting way, I'll start putting code on CVS. It should happen within a week I hope.
- Nothing in CVS yet but Nicola says -
Week ending 10 June 2000 gstep-base (Foundation) Many changes for improved portability to non-unix systems. NSBundle - much updated to use NSFileManager rather than unix calls for handling files/directories. NSString - new indexOfString method, range comparison fencepost bugfix. NSByteOrder functions now used throughout for portability. Fix includes for WIN32 throughout gstep-gui (AppKit frontend) When loading a gmodel, call awakeFromNib if an object in the gmodel doesn't respond to awakeFromModel. gstep-xdps (DPS backend) Faster, simpler font initialization - only loads the fonts that are asked for. Better checking of NeXT extensions Image drawing improvments (images now draw twice as fast). tests (testsuite for base library) Added more tests for ranged comparisons of strings. Updated README file. documentation Nicola Pero has been working on tutorials - you can see his GNU make tutorial at http://gnustep.8m.com gstep-java (interface to Java language) Nothing in CVS yet but Nicola says - Mainly, people will use the GNUstep Java Interface in one of two ways: 1) You can link a GNUstep application against the GNUstep Java Interface library and a Java Virtual Machine library of your choice. When you do this, you can then start a Java Virtual Machine inside your application simply invoking [NSJavaVirtualMachine startDefaultVirtualMachine]; Then, you will be able to 'load' a java class (which should be in your classpath) inside the objective-C runtime, with some function or API still to be determined, but which could be something as easy as [NSJavaVirtualMachine exposeJavaClass: @"myJavaClass"]; [This will dynamically create a class of proxy objects to myJavaClass, and all its superclasses, and insert them in the objc runtime]. At this point, you can create an object of class "myJavaClass" by simply using: Class class = NSClassFromString (@"myJavaClass"); id obj = AUTORELEASE ([[class alloc] initWithString: @"Test"]); This will create a proxy in the objc space to a java object of class myJavaClass. 'initWithString: @"Test"' will be translated into the java constructor myJavaClass ("Test");. You will be able to use the proxy exactly as an objc object, and use all its java methods (with the reasonable automatic conversion of names). You can pass arguments and use return arguments as if it were a real GNUstep object. There should be some mechanism, still to be determined, by which you can choose for each java class you want to expose, how objc selectors are going to be mapped to java methods [if you want to have a different mapping than the automatic one]. Probably some 'configuration' file somewhere in the GNUstep directory, in the form of a property list, which would be read by the library upon setting up the interface. This first way of using the Java GNUstep Interface will be nice also because you don't need a shared libobjc to use it in this way. 2) [You need a shared libobjc to do this]. The GNUstep Java Interface provides some java classes (gnu.gnustep.base.NSObject and some other classes to access the interface functionality). You put these classes in your classpath, then you can simply create an object of these classes. Once you try to do it, a static initializer in these classes loads GNUstep and the GNUstep Java Interface as a native library, and sets all the interface up. A simple interface to send message to objc objects of arbitrary classes will then be provided and accessible using the auxiliary interface java classes (gnu.gnustep.java.NSObjCRuntime, and others). [There could still be some little technical tricks on the java side when loading multiple native libraries which need to talk to each other. Anyway, these will be sorted out (perhaps the solution could be as drastic as needing to load all the GNUstep libraries you want to access together), but since I have not yet done it, perhaps the following description will not be an accurate description of how the final version will work.] At this point, any objective-C library which you have already wrapped in java will be accessible exactly as a java library. That is, you can simply instantiate objects of the class, and invoke methods, exactly as if it were a java class. Wrapping an objective-C library will be very simple if you are only wrapping 'standard' things. We will have an automatic wrapper, as Apple has, but this is just the last cherry to put on the cake, in the sense that the real difficult part is the interface internals. Once they work reliably, writing the wrapper will be easy. Also, it will be perfectly possible to wrap libraries by hand. I am not assuming that anybody will do it by hand except me, but the first libraries I will try to interface will definitely be wrapped by hand, also because that will help me designing better the way a library needs to be wrapped. The only trick in all this stuff is when you pass a pure java object to objc space as a weak reference. Say that you have your java class called Controller. You use the GNUstep GUI from Java to write your GUI app. You want to set an object of your Controller class as the NSApplication delegate. Then, you would do: NSApplication app = NSApplication.sharedApplication (); app.setDelegate (myController); This java code will crash later on, and there is nothing we can do to stop it crashing without some help from the programmer. [The problem is that setDelegate: is exceptional in that it does not retain its argument. When you pass myController to objc space, an autoreleased proxy is created; this proxy is then not retained by any objc object, and so it is released when the autorelease pool is emptied. This is all perfectly correct, if we do differently, we leak objects in normal situations.] Apple bridge documentation instructs programmers to create an auxiliary objc NSArray, and to add to the array all objects that you need to pass as weak references into objc space (as in this case). We can't improve much on this solution - but at least I think we should provide facilities to create the array internally and then the programmer would simply write: NSApplication app = NSApplication.sharedApplication (); NSObjCRuntime.retain (myController); app.setDelegate (myController); Before passing a java object to objc space as a weak reference (one that it is not retained on objc space) you would use NSObjCRuntime.retain (Object); - when you are finished, you use something like NSObjCRuntime.release (Object);. I can think of a different solution, which could be completely opaque to the programmer (she would not see any difference between a method taking a normal argument or a weak argument), but would require the person wrapping the library to mark methods storing a weak reference to the argument as special, so that the wrapper can insert extra code to manage it (which would do a dirty job). It's a bit muddy to implement, and it's not worth thinking about it yet. hope to reach a good point with the java forwarding today, then I'll try to assemble all the pieces together in next days. As soon as I can do something really exciting - manually wrap an objc library and/or use java libraries directly from objc in some interesting way, I'll start putting code on CVS. It should happen within a week I hope.
