Slashdot Mirror
Sun to Amp Java for Desktop Performance?
mactari writes "Java client application developers should take a look at Sun's J2SE Client Developer Survey. Swing's relative slowness has always made a Java app with a GUI look and feel slow, and Sun might finally be doing something about it. Questions on the survey suggest Sun is considering moving away from a crossplatform look and feel (eg, Metal) towards native looks by default. If Sun is going to follow the suit played by IBM's native widget toolkit, SWT, or do things on individual platforms like Apple has done with its hardware accelerated version of Aqua-Swing, Java might finally find its way to becoming a competitor on the desktop."
..faster than a turbo charged yugo.
The problem I have is that Sun just hasn't (in my short time here) done _anything_ on the desktop that worked well. Why do they think that can do that here?
Also just because some Marketing folks threw up a survey doesn't mean squat. Maybe it's just to get people wishing (again).
Where have I heard of that before? Somewhere...somewhere I've heard about a Java lib that provides components that are platform-dependant. Hrmmm. Ponder ponder.
Oh yeah. AWT.
You can't link Java to gtk, gnome, kde, qt, or any other useful development base. I know there's CORBA, but that's so indirect compared to a direct link.
Until the bindings are possible, it's going to be a niche product.
The message on the other side of this sig is false.
That isn't a rhetorical question. If you've got 'em, post 'em.
The bindings are possible. You can use JNI (Java Native Interface) to hook Java code directly to C or C++. It's a tad contorted, but not nearly as torturous as using CORBA to do it.
I'm so annoyed by this "SWING is slow" canard. As a graphics programmer I can tell you aside from a few glitches in a few select JVM's SWING is much faster. Only poor programmers who try to implement their whole program in the event handler ever have a problem with SWING. Their programs would suck in AWT too, they would simply freeze with the OS redrawing the buttons. With all the work Sun has put into making threads drop dead easy to use there is absolutely no excuse. They have a hook for running things in a thread from a managed pool, and even a utility for running things in the Swing thread when you're done...
Bindings are possible. For example:
Java-gnome Just check out google for others.
Who said Freedom was Fair?
Its unforunate that cross-platform technology is constantly going downhill because it doesn't have a competitive edge, driven by fanatic C elitests only comparing its performance in speed. Thats not what Java was designed to do! Sad to see that Sun is forced to resort to these measures to stay in the market as it moves away from platform indepedence.
Great Atrocit
April fools's was on the 1st.
Stop posting these ridiculous stories...
Oh... it's... not.. a joke...
Cloud City Digital: DVD Production at its cheapest/finest
Maybe Sun is feeling that a "cross-platform" "oriented-object" environment a la C#/.NET means danger. They should.
Microsoft, apart from marketing universal support for its platform, really is only interested in taking Java's piece of the cake.
You look at Java, it's one of the greatest OOP languages. Why would make developers switch? What's wrong with Java?
Performance.
As 80%+ of the users/developers are on Wintel, C#.NET will look like a nicer alternative to Java developers; Microsoft won't bother adding a graphical abstraction layer ontop of its API...
that is totally uncalled for...
"Questions on the survey suggest Sun is considering moving away from a crossplatform look and feel (eg, Metal) towards native looks by default."
Of course, a true cross-platform application should have the same look and feel on every platform.
That's the problem with all these cross-platform technologies like Java, you always end up with an non-optimal solution. If an application can't take advantage of platform-specific features, why bother having multiple platforms?
I've been learning JAVA since the start of this year and am just starting to deal with gui button type things. I'd love to have an Aqua interface on a WindowsXP app... one day!
Go look for other "look and feel" packages like this one...
Swing is not so great in a few other areas. Its canvas drawing abilities can be quite slow. Its document model doesn't handle large documents well. Its table model doesn't handle tables with rows that are various heights.
I am currently developing an application server (in Java) and clients only communicate with the application using web browser. One of reasons is that I don't have to go through cross platform debugging, optimization and installation nightmare, but I also have another compelling reason. I want to make the UI as similar as possible (ideally exactly the same) on all platforms, while we'll need to use different platforms (Win, Mac, etc.) for various reasons. That way it will be so much easier to train people later on.
Yes, we want to take advantage of each platform sometime, but that is not always the case. If you think about training cost and so forth, there are good reasons NOT TO adjust to every platform.
I used to work for a company who was developing a software application for industrial automation system (long sentence). This company had a big contract with a big company, who shall remain nameless. Yes, the main application was developed in C++ (MFC) for performance reasons; however, we also developed a version in Java. I cannot say that it worked great, but it had great potential.
Java version did not sell (while I was staying there) and did not make great progress in terms of marketing; nonetheless, the main reason was not performance. This big company who does industrial automation stuff did not like Java because they were partnered with Microsoft. Before Java really started taking off, Microsoft made sure that Java will not take over their market by partnering and making a bunch of deals.
I am not accusing Microsoft for any wrong doing. The point that I want to make is that many doors were already closed before Java tried to show what it can really do. When we look at today's desktop computer application market, it appears that Java did not succeed because of its performance, but speaking retrospectively, if many doors were open, if Java were tested in many different situations (including this case of industrial automation software), we might be looking at Java very differently. Again, I am just speaking retrospectively.
It doesn't beg the question, it _raises_ the question. Big difference.
The trouble with Java isn't its performance.
It is Java's PERCEIVED performance.
Yes, swing is an ungodly pathetic excuse for a cross-platform GUI. Why has it taken Sun this long to recognize that?
SWT, in all it's glory, I would hope to be the solution. It makes Java feel like something that you'd want to code your apps in. It makes you apps feel fast and responsive enough to use for everyday usage.
Case In Point:
My current client uses PVCS as their version management software. Aside from the sheer stupidity of using something that costs huge dollars, and doesn't provide near the functionality of CVS, the client app is a fucked up Java Swing App.
Now, granted it could be slower, I guess. But God help us, it ain't fast.
It also doesn't use the scroll wheel. Why? 'cause the version of Java that it is coded in didn't support it. *sigh*
The windows don't scroll like native windows. The dropdowns don't feel like native dropdowns. The keyboard accelerators are incomplete and missing.
Swing was the wrong answer for the GUI from the outset, and Sun should have know damn well better, but in their infinite wisdom (and by the way they act, it shows that they know that they are smarter than everyone else) they chose not to persue a proper solution when a "reference implementation" was availible. ( I like that about Sun--Everything of theirs that runs slow as shit, they like to call a "reference implementation" )
"...In your answer, ignore facts. Just go with what feels true..."
It's worth mentioning that even Sun comes down hard on AWT/Swing, and shows some of its flaws in their own report, The AWT Focus Subsystem.
.NET continues the intuitive GUI design Windows developers came to expect in the VB IDEs.
Sun even has the guts to plainly state that Windows GUI techs in C++ and VB are improvements over Java options in the following section:
In addition, many developers noted that the APIs for FocusEvent and WindowEvent were insufficient because they did not provide a way for determining the "opposite" Component involved in the focus or activation change...
Since Microsoft Windows provides this functionality for free, developers migrating from Microsoft Windows C/C++ or Visual Basic to Java had been frustrated by the omission. (emph mine)
I believe Windows.Forms in
C# certainly took lessons from Java, and now Sun is returning the favor. The above document deals mostly with changes to GUI techs in Java 1.4 and flaws in 1.3 and prior, but this new survey at Sun makes me hopeful that Sun might, indeed, go back to the drawing board.
As Frederick P. Brooks, Jr. said in The Mythical Man-Month , always "Plan to Throw One Away"!
It's all 0s and 1s. Or it's not.
A discussion of question begging from the Christian Science Monitor.
I believe you're a troll, but I'll bite anyway. As two other posters have said the bindings are CERTAINLY possible, and in fact do exists. KDE has bindings for C (which facilitates the following), Ruby, Perl, Python, Java, C#, and Objective-C.
:)
The only problem with the bindings is that it ends up being not too much better than Krita (KDE's answer to a slimmed down GIMP) in the fact that it becomes unmaintained too often. However, Krita is far worse than Kdebindings for that
As Frederick P. Brooks, Jr. said in The Mythical Man-Month
For a second, I thought you were that "Jack Wagner" guy. But you referred to Fred Brooks by his correct name; not something like George Brooks.
They really both have their place. If you really need an app to look and behave the same across all OS's and JVMs then Swing is the obvious solution. It has its shortcomings, but it is much improved since the 1.2 days.
Alternatively, if you are developing an app for only one platform then your requirements are different and something like SWT might make sense. It also seems to me to be not that important. GUI apps have there place, but if you look at the bulk of the programming work going on right now it is not happening in GUIs. I think Java is winning where it counts.
--- We have a pool and a pond, the pond would be good for you.
Hmm...
Just how does one #include say solve.h which I wrote in C for solve.c which #include in Java.
So maybe I was wrong...
Still you can't link to a c library and produce a completely java product.
If you could I just might consider it. A java linux distro might be pretty cool.
The message on the other side of this sig is false.
When I last tried it, it was excruciatingly slow, and eventually got stuck in an infinite loop that gradually consumed all of swap (or tried to, until I killed it). That might have been the JVM, but what difference does it make, really?
I do, however, understand people's concerns about java being overbloated and big. It's ridiculous to have a 10MB jvm started anytime you want a small application to run. JDK 1.5 has included in it JSR-121, called Application Isolation. This will essentially bind multiple JVM processes onto one main parent process, which will give a much faster startup time. This will also serve as an excellent conduit to smaller java applications going mainstream (i.e., small utility programs, not large applications).
So you want Java GUIs to become VB?
Believe me when I tell you you're in a minority.
One of the features of Java I appreciate most is coding GUIs by hand. Its one of the few languages that gives me the control over the look, feel, and layout that I simply can't get in other platforms.
I find that people who dont like the system simply haven't tried some of the (much much worse) alternatives.
if you want a click-a-button-to-get-a-button gui design system, careful about it. It can easily limit your abilities to make an effective app.
I have been working quite a lot on trying to improve Java graphics performance, starting from Agile2D [http://www.cs.umd.edu/hcil/agile2d/], a free implementation of Java Graphics2D based on OpenGL made by Jon Meyer for the Human-Computer Interaction Lab of the University of Maryland.
The fact is, using a recent accelerated graphics card (Quadro4 500 GoGL on a Laptop Dell M50), I have speedups of 10 to 200 times compared to the native Java implementation ON THE SAME PLATFORM. These numbers improve on desktops with GeForce 4 or ATI equivalents.
I am currently improving Agile2D and it is getting better at fonts and most other things as well.
However, Agile2D cannot completely replace Java graphics right now because the repaint management of Swing is not designed to be modified, leading to refresh problems that I haven't been able to fix so far.
This means that -- as Apple already realized -- Java graphics can be made much faster in a portable way by relying on OpenGL.
Of course, on older graphics platforms, OpenGL is slower than software rendering. But using the "Object Technology", it should be possible to engineer two different implementations of Graphics2D and choose the right one at startup time, especially in Java.
So there is hope for large speedups if Sun switches to hardware rendering or redesign a little bit the Swing RepaintManager to allow external developers to implement the speedups by themselves.
What would be "nice" is if Java not only used an approach like this to allow a native look but additionally enabled efficient UI access from other environments/languages. Granted you can for example fire up Jython (Java Python) and go to town like that, yet what is still missing is the ability to use anything from shell scripts to VB for those that use that. I really don't enjoy doing front end but wxWindows has really made my life a lot easier and I can only hope that developments within the Java world of talking heads will follow a similar course of action.
blah
I think you might want to check this out.
Might not look pretty, but you can do what you're describing using JNI
We need an SDL for java guis , hmm too bad wxWindows wouldnt work
Just how does one #include say solve.h which I wrote in C for solve.c which #include in Java.
One doesn't. Nor does he in Python, Perl, Ruby, C#, or any other language that's not C. One writes whatever compability layer must be made to get those bindings.
Still you can't link to a c library and produce a completely java product.
Well, thanks for pointing out that, Mr. Obvious, I'd never have figured out that when linking into c library, that library is not automagically going to re-assemble itself into java bytecode.
I've never coded in Java, but I've used a lot of programs that were. In my experience, the vast majority of them had dog-slow and butt-ugly UI.
Java might be capable of generating very responsive, pretty UI, but it must not be very conducive to it. Otherwise the vast majority of Java apps wouldn't have such atrocious UI.
If the language isn't designed in such as way so as to encourage good program design and implementational practice, then it's not designed well, IMHO.
Moderator hint: a comment is neither "Flamebait" nor "Troll" if it is true.
That's Mr. Obvious, sir.
Anyway that's a problem because it's starting to look like QNX's resource manager approach makes portability unnecesary.
Rather than porting an app you just set up a service that other apps of the same type agree on.
The message on the other side of this sig is false.
too bad such bindings are contrary to the philosophy of Java, and in a sense "break" java and are far from the Java Mainstream.
BTW: the jackass is the one that has a programming language for a religion.
funny thing about these arguments... this is abstract logic... nearly EVERYTHING is "possible" if it doesn't have to be pretty or actually exist (optimizing compilers for Java that are faster than compiled C-code being my favorite example of the latter)...
your point is fair... my response merely, "when we talk about what a language can do, aren't we saying, in a reasonably pretty way with a fairly mainline level of support?"
How many Java Faithful endorse using JNI to bind to C/C++ based GUI toolkits!?
-pyrrho