91–100 of 277 posts
Unlikely as it is, I wish Apple would upstream that code to Oracle.
I guess there's potentially still SWT on top of a ported, open source Java7 from Unix/Linux if you need to do non-X11 UI on Mac.
Well, some Googling suggests that might work anyway...
Earlier quoted context omitted.
Clang/LLVM is BSD while GCC is GPL. That means Apple can extend them all they want without ever giving you, or their competition, any sources. If they ever perceive a threat from their competition, Clang/LLVM provides a lot more maneuvering space than GCC ever would. And yes, GCC is a very hard thing to integrate into tools and it's that way by design.
And yes, GCC is a very hard thing to integrate into tools and it's that way by design. Any reference for that claim? This would seem to be an absurd design decision. It's more work to design this way but the benefits are enormous.
I can't find a citation for this at the moment, but RMS has said on several occasions that GCC has to be difficult to integrate into other tools just for the sake of pushing the GPL. For example, this was his explanation for why improvements to GCC's intermediate representation formats (GIMPLE and friends) were refused for a long time.
So then what's the best way to do cross-platform development? For all its faults, Java does deliver something that resembles the "write once, run anywhere" dream. Any idea for a high-performance, cross-platform, native UI development stack? Is C++/Objective-C still the best option?
Earlier quoted context omitted.
I use SmartSVN, wouldn't call it ugly.
But this seems to be AWT. And the GUI just doesn't feel as snappy as native Cocoa. Actually, I wonder why that is. I always thought that it is Java itself which makes Java applications feel slow. But I haven't noticed this in Cyberduck. So maybe it is just AWT. I wonder why that might be. Maybe because AWT does all the drawing itself, which is much slower compared to the native toolkit?
My belief is that apart form some overhead in AWT against native toolkit, 90% of the laggish experience in java apps is due to poor coding.
In turn, this is probably a byproduct of the java platform/language (abuse threads cause they are easier than an event loop, abuse locking cause synchronized is more obvious than util.concurrent, avoid thinking of memory management cause you have a GC, do not pay attention to proper data structures cause you can get away with builtin collections etc)
Earlier quoted context omitted.
However it isn't just the Cocoa bindings that are important. AFAIK SoyLatte's Swing/AWT elements run through X11. Apple's Java allows for Java GUIs without starting X11.
X11 is horrible on OSX. Applications that use it (e.g. The GIMP on OSX), are terrible and have many usability flaws, such as no clipboard between an X11 application and a normal application.
Earlier quoted context omitted.
X11 is horrible on OSX. Applications that use it (e.g. The GIMP on OSX), are terrible and have many usability flaws, such as no clipboard between an X11 application and a normal application.
True, but would you rather not have it at all?
So then what's the best way to do cross-platform development? For all its faults, Java does deliver something that resembles the "write once, run anywhere" dream. Any idea for a high-performance, cross-platform, native UI development stack? Is C++/Objective-C still the best option?
Earlier quoted context omitted.
But this seems to be AWT. And the GUI just doesn't feel as snappy as native Cocoa. Actually, I wonder why that is. I always thought that it is Java itself which makes Java applications feel slow. But I haven't noticed this in Cyberduck. So maybe it is just AWT. I wonder why that might be. Maybe because AWT does all the drawing itself, which is much slower compared to the native toolkit?
many SWT apps, using native look and feel, still feel slowish (think azureus/vuze if not eclipse). Some AWT apps are perfectly snappy e.g. jedit opens a file faster than macvim on my box. My belief is that apart form some overhead in AWT against native toolkit, 90% of the laggish experience in java apps is due to poor coding. In turn, this is probably a byproduct of the java platform/language (abuse threads cause the…
Specific examples from your experience?
Earlier quoted context omitted.
> Their move from GCC to clang is no coincidence. Erm... what? Clang has already been ported to Windows (and other platforms). Their move from GCC to clang comes from GCC sucking goat's balls at error reporting and being integrated into an IDE. You might want to note Apple produces an IDE so that's kind-of a big deal for them, and a big reason for the existence of LLVM and related technologies (Clang, LLDB, ...) is v…
Clang/LLVM is BSD while GCC is GPL. That means Apple can extend them all they want without ever giving you, or their competition, any sources. If they ever perceive a threat from their competition, Clang/LLVM provides a lot more maneuvering space than GCC ever would. And yes, GCC is a very hard thing to integrate into tools and it's that way by design.
It mostly means that they can use the libraries without having to open-source Xcode itself. A compiler is not exactly a competitive advantage for a company as big as Apple.
> And yes, GCC is a very hard thing to integrate into tools and it's that way by design.
Uh yes and?
Maybe the fact WebObjects was removed from Snow Leopard Server means they don't depend on it internally as much? It seems like they've been cooling off on Java development and support over the last few years.
I don't believe this is an immediate issue, but one that people doing long term planning should consider. If you want to write/run Java code, have at it. If you want to write something that will be widely distributed, you may want to think carefully.