Comments made in any post are personal opinion, and are in no-way representative of any commercial entity unless specifically stated as such. ---- http://codebench.co.uk
always good to see when developers works step by step and reach their goals. will be -very- interesting to test. i follow blog from begining and its all done good: native aos shared libs and co. should be fast and nice imho
Don't keep your hopes up on the first version though...
I'm going to disable my very slow debug outputs, but it still is the ordinary interpreted version compiled in. Haven't touched the JIT or looked at any of the other optimizations available. But in coming version I will of course see into that.
Don't keep your hopes up on the first version though...
I'm going to disable my very slow debug outputs, but it still is the ordinary interpreted version compiled in. Haven't touched the JIT or looked at any of the other optimizations available. But in coming version I will of course see into that.
IMHO, having a fully working JVM is more important than speed. In fact, I'd rather have working AWT & Swing before JIT, as there's only so much that can be done without the GUI toolkits. JIT can come later.
Hans wrote: IMHO, having a fully working JVM is more important than speed. In fact, I'd rather have working AWT & Swing before JIT, as there's only so much that can be done without the GUI toolkits. JIT can come later.
I agree. Get everything working first, and then optimise for speed.
kas1e wrote: Btw, is there ppc jit for java done already and only need adapting ? Or its need to be done from scratch ?
JamVM has PPC JIT already, so in the best case it should be enoguh to enable a flag in config.h. My plan is to get thefirst usable beta out of the way, and finish the bounty. Then I'll look into stuff like JIT, see what kind of other important applications we don't have that will work with the current version has support for. Swing and AWT is, I fear, a rather big thing to get done. I should be able to use QT, I think. As for AWT, its relatively seldom used, and we'd actually be better of with something like SWT which is used in Eclipse and NetBeans IIRC. Furthermore, before putting huge amounts of efforts into GNU Classpath, I'd prefer to focus on OpenJDK,which would give us Java 8 amd beyound, where GNU CP only has Java 5, and development is low (much due to OpenJDK). Any work done on JamVM and JIT benefits both OpenJDK and GNU CP.
1. The speed of the current beta isn't too bad. You're going to need reasonable hardware to benefit from Java anyway, so I doubt this is going to be much of an issue. 2. I don't think I've seen a Java app on any platform that actually looks native. 3. There are going to be bugs anyway. 4. This is an OS problem, not really a Qt one.
It will be much less work to port an existing Qt-using AWT/Swing/whatever. Whilst it might not be the best solution in the long run, for an initial version it absolutely is. Creating a custom one that direct uses Intuition can come later.
Sure, but we talk about final users expedience. And as QT use a lot of big fat sobjs which is not really shared because of how they done, its still will give in end slower loading of java as well. Will you use it if for running some swing based app it will take 20-30 seconds ? Jaokim already made all of his work with native libs and co, so re-use QT with slow sobjes loading will kill pluses of how Jaokim's work done, and will put it on the same way of slow software which only brave will use.
Currently QT is not ready to be used as it, do not saying that if something will be based on top of it, it will be unusable in end.
kas1e wrote: Sure, but we talk about final users expedience. And as QT use a lot of big fat sobjs which is not really shared because of how they done, its still will give in end slower loading of java as well. Will you use it if for running some swing based app it will take 20-30 seconds ? Jaokim already made all of his work with native libs and co, so re-use QT with slow sobjes loading will kill pluses of how Jaokim's work done, and will put it on the same way of slow software which only brave will use.
Currently QT is not ready to be used as it, do not saying that if something will be based on top of it, it will be unusable in end.
AFAIK, the Swing toolkit renders its own gadgets, and hence has no need for Qt in the first place. What it needs is native implementations for the base windowing and 2D graphics classes (e.g., JWindow, Graphics2D). Both of those items could easily be implemented using OS4 libraries.**
AWT, on the other hand, uses the native gadgets. Given its age and limits, it should have no trouble using the native GUI toolkit (Reaction or MUI). In fact, this is what the original JAmiga project did. It had a partial AWT implementation, as can be seen in its screenshots.
Hans
IIRC, the native implementations that Swing depends on are mostly part of the AWT library. For example, Graphics2D is an AWT component, and JWindow is a child-class of AWT's Window class.
jaokim wrote: Swing and AWT is, I fear, a rather big thing to get done. I should be able to use QT, I think. As for AWT, its relatively seldom used, and we'd actually be better of with something like SWT which is used in Eclipse and NetBeans IIRC.
As I told kas1e, Swing renders its own gadgets using the Java 2D API. AFAIK, it is 100% Java, with no native components. A partial AWT implementation (just the windowing and 2D graphics classes) should be enough to get it up and running.
Qt is a poor fit for this; you're better off using native OS4 libraries.
As for SWT, it's entirely your call whether Swing or SWT have a higher priority. Having said that, my understanding is that SWT is an Eclipse team project, and not an official part of Java.
Quote:
Furthermore, before putting huge amounts of efforts into GNU Classpath, I'd prefer to focus on OpenJDK,which would give us Java 8 amd beyound, where GNU CP only has Java 5, and development is low (much due to OpenJDK). Any work done on JamVM and JIT benefits both OpenJDK and GNU CP.
I agree. Classpath made sense before OpenJDK came along. Now it's better to switch. There's no point in doing lots of work on Classpath native implementations if they're going to be dumped when switching to OpenJDK.
Hans wrote: As for SWT, it's entirely your call whether Swing or SWT have a higher priority. Having said that, my understanding is that SWT is an Eclipse team project, and not an official part of Java.
Yes you are perfectly right SWT is an Eclipse project, but more and more projects adopt it because instead of going full Java (like AWT and Swing) it's using the underlying OS gadgets facilities. Due to that it gains more speed and reactivity and as it's already available on all three major OSes people assume it's portable.
IMHO SWT is only required if one is developing a Desktop application that needs to compete with native applications user wise and with native look. And if you think AWT and Swing are huge tasks then SWT is way above that. That's because more aspects needs to be tied to the native libraries and it's almost certain that our current toolkits will miss some capabilities that we have to be emulated somehow (which in the end defeats the goal of using native components...)
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
