On Fri, 4 Oct 2002, Dalibor Topic wrote: > That's true, full java 2 support with the tons of > classes included would require more memory, which is > unpleasant in the embedded setup. A JDK specific class
As a sorta-related issue, I note that Kaffe.org's version takes lots more space than the Transvirtual custom edition ever did. Part of it may be because they made off with things like serialization, but I'm wondering if anybody has an idea where most of the bloat is coming from, and if we can cut down on it? I'll try to look at that myself at some point, especially as I can't offhand remember the exact stats and compiling... it may be just having X-Windows interface instead of framebuffer contributes some. > handling different semantics (like some constants > being only available in Java 2, or differing > method/feature implementations) for different JDK > versions could be really ugly. JavaDoc already has its format for specifying which methods and constants were implemented in which version. I briefly thought it might be simple to just use those as indications of what should be stripped for specific level implementation. Unfortunately, I quickly reasoned that alone wouldn't do it ;) This doesn't mean we couldn't use some JavaDoc like system to mark up segments that are specific Java2 bloat. It wouldn't have to catch all Java2 additions, just the most resource-hungry (and possibly those needed because of totally cut-off classes - unless you want to use reflection a lot...) ones where somebody has bothered to do this (for obivious gains). Same format could be extended to provide automatic selection of class-files for the subsets, as well as defining subsets other than the obivious JDK version levels - such as the different JME profiles and possible custom sets. Problem is, what marking convention should we settle on? Suggestions? > runtime library for everyone's benefit. I wouldn't > object to putting AWT in its own jar, for example. > People compiling with awt would recompile awt.jar, the > rest would profit from a smaller rt.jar. What do you > think? That's a good idea, but see above... Altough for AWT we have fairly straight-forward selector concept in existence already (Just grab the awt subhierarchy). I can only speak for myself, ofcourse, but I think AWT is one of the less useful pieces to have separately, despite it being fairly large in all (with the native support included), because applications tend to rely on it anyway (embedded graphics) or else have resources to drag it along (Java servlets etc.). Doing clear-cut jar division on other aspects of Java API is harder, but see above. > I guess it depends on the situation: constructors are > unlikely to be manually inlined into other methods, so Good observation. So maybe this needs to go into a style-guide? > You could add a few lines saying that you are doing it > for performance reasons, though. If you are out for > maximum performance, you may want to consider using a > boolean array ACTIONKEY with isActionKey value for all Well, it's arguable, I mean that CPU load is going to be fairly keyboard-bound, and people can't type so far it'd make a major impact. Every bit counts, though, and I like to write tight code when there is no reason not to, and in this case I think the end-result is also cleaner to some standards (It just doesn't conform to single form). I did consider the array-alternative, mostly because that would've been the easiest way to match the responses with Sun's implementation, but the table would've taken prohibitively lot of space, even if you'd actually use all bits of the array. Maybe for the first 256 codes it might be manageable. > The implementation is fast, but eats up some memory. I > don't know how many legal keyCodes are possible, so I > can't tell. Whole Java integer-type is legal range for the keycode, in essence, but I think the highest one that's supposed to be a action-key is somewhere in the 15-bit range. > so this means that KeyEvents with a null source works > in kaffe when it should not? Yeah, but the exception in Sun comes from another class, which is why I didn't put it in this patch. > good to hear that xsmiles works with kaffe! Well, it worked quite fine back there, too, but since both Kaffe and X-Smiles keep getting changed, they eventually stop working at some point. During my summer vacation at least the Swing/KeyEvent part and HTTP file requests broke (patch to both submitted). This obiviously makes trying to match the Kaffe/X-Smiles releases rather hard, I have no idea right now if the latest X-Smiles release works with the latest Kaffe release for example. In theory it does. However, we're going to release a new version RSN, and that won't work without the submitted patches to Kaffe. Altough we might be persuaded to try to implement some sort of work-arounds in X-Smiles to get them to work - though I'm working part-time now, and just keeping the HEAD revisions working together is enough work not to have to worry about backwards compatibility ;) I'll ask around if it's something we want to do, though, but I'd suggest Kaffe try to live up to the "Release early, release often" model. -Jukka Santala _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
