Desktop Java and Linux
Casper Bang
Well first of all Java is generally considered large, clunky and not
exactly a high productivity tool. It really should be surprising to no
one if the typical grass root movement on the Linux platform prefers
something with less overhead and entropy associated.
Then there's the issue of the cross platform UI pipe dream. I've
mentioned it again and again, if desktop Java really were so great
then wouldn't we see Google Earth, Picasa, Firefox etc. written in
Java rather than multiple native versions? After all "Java is faster
than C" right?
Mono. Very successful, at least in the Gnome world, since it does not
try to go the Swing route and it's very easy to call native C
libraries (a nightmare to do in Java). Of course, Mono already has
closures etc. so it's attractive to people who do not care much about
JSR's but just want to write cool applications for their platform like
Tomboy, Banchee, Beagle, F-Spot etc.
Gray box syndrome of Java in Compiz. Continues to play games with
people, evidently leaving people not liking Java.
Swing is really hard and missing a lot of things, i.e. there's still
no freakin' DatePicker. Most of these issues relates directly or
indirectly to that of missing a proper component model.
/Casper
Rohan Ranade
>
> So why is desktop Java not winning Linux developers hearts?
>
> Well first of all Java is generally considered large, clunky and not
> exactly a high productivity tool. It really should be surprising to no
> one if the typical grass root movement on the Linux platform prefers
> something with less overhead and entropy associated.
>
> Then there's the issue of the cross platform UI pipe dream. I've
> mentioned it again and again, if desktop Java really were so great
> then wouldn't we see Google Earth, Picasa, Firefox etc. written in
> Java rather than multiple native versions? After all "Java is faster
> than C" right?
+1. I feel like laughing (and then crying) when I see the GTK LAF.
It's yuck. How can one expect sleek and professional apps to be
written this way? Just not done. I started exploring PyGTK (and
Python).
mbien
> Gray box syndrome of Java in Compiz. Continues to play games with
> people, evidently leaving people not liking Java.
but it doesn't happen any more.
Dick Wall
whining and fix the problems instead.
As for mono, the apps are great... on Linux. I don't know of a single
one that has crossed over to another platform though. Does banshee run
on windows or mac?
Peter Becker
For a long time Java has had many issues, both technical and political
and they will stick for a while. And the entry curve is still steep --
Swing is bloody hard and not very rich. I've never done much work in
GTK, but developing GUIs in Qt is just nicer with the tutorial
actually creating a little game[1]. I've done that tutorial with
highschool kids many years ago and it worked, they happily extended it
in the end. Despite Java being easier I can't see that working with
standard Swing libraries.
I think there will be a lot of adoption of server-side Java soon. Both
Debian and Ubuntu have set up Java taskforces, and I assume the other
distributions have similar structures. Tools like Tomcat will soon be
just an "apt-get install tomcat" call away, quite possibly even in the
core repositories. But if you ask an average Gnome dev about Java they
will still hate it and will continue to do so for a long time. KDE
might be a different story with the Jambi option.
If Sun would really care about the opinion on desktop Java, I'd
strongly propose fixing Swing. It still lacks basic features, not just
the smarter widgets like the aforementioned DatePicker, but even more
importantly an application framework to manage setup/teardown,
actions, session management and so on. What Hans Muller started looked
good, I hope it will continue soon. Little things like just adding
EDT-assertions all over the code would be good, too -- noone really
understands what exactly has to be on the EDT and what not, I
regularly see experienced developers arguing over it.
BTW: one of the technically most convincing Java apps in the Linux
world is FreeCol [2] -- not only does it not look like Java at all, it
also beats the SDL crowd of games with a full-screen mode that doesn't
screw up the keybindings of the window manager. Some people might say
"it's just a game", but I think it is quite convincing in terms of
what Java can look like. Acording to their history page they are fully
Java since 2003.
Peter
[1] http://doc.trolltech.com/4.4/tutorials-tutorial.html
[2] http://www.freecol.org/
Casper Bang
> but it doesn't happen any more.
for people though when you read the comments:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6429775
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6632124
> As for mono, the apps are great... on Linux. I don't know of a single
> one that has crossed over to another platform though. Does banshee run
> on windows or mac?
http://abock.org/blog-images/banshee-on-windows.jpg
Your next objection might then be that it's not write-once-run-
anywhere when you have to build and distribute platform specific
bundles. Where to I'd just like to point out that the few popular
desktop Java applications I am familiar with such as the Spark chat
client, Azureus torrent client and even NetBeans, are distributed this
way as well - even if in NetBeans case it's only to make up for a
missing System.restart() call.
> just an "apt-get install tomcat" call away, quite possibly even in the
> core repositories. But if you ask an average Gnome dev about Java they
> will still hate it and will continue to do so for a long time.
space's attitude towards Mono - which, like it or not, contains 90% of
what's being discussed for Java 7 and 8.
> If Sun would really care about the opinion on desktop Java, I'd
> strongly propose fixing Swing. It still lacks basic features, not just
> the smarter widgets like the aforementioned DatePicker,
been a core part of visual basic and Delphi, and I have yet to see a
corporate/business application which does not somehow involve the
manipulation of dates. Again, it's caused by the missing component
model which can also be witnessed inside Sun itself, they effectively
sponsor two independent yet similar hierarchical table components, one
through SwingLabs known as JXTreeTable and the other from OpenIDE
known as Outline. As someone with considerable investments into
JXTreeTable, this divide obviously scares me.
> but even more importantly an application framework to manage
It was not possibly for me to convince Hans into adding a restart
functionality such as to avoid the aforementioned native wrapper of
NetBeans. So now if you wish to change Locale in your application, say
change the language from English to German, you will require the user
to restart manually (due to the fact that Locale.setLocale() does not
broadcast any events like a UIManager.setLookAndFeel() call would). So
I don't see JSR-296 as a great time saver I'm sorry to have to say, a
NetBeans RCP based approach would be my recommendation after having
tried both.
/Casper
Mark Derricutt
Thankfully those days are behind us (on recent distro's anyway).
distributions have similar structures. Tools like Tomcat will soon be
just an "apt-get install tomcat" call away, quite possibly even in the
core repositories. But if you ask an average Gnome dev about Java they
"It is easier to optimize correct code than to correct optimized code." -- Bill Harlan
Peter Becker
[...]
>> just an "apt-get install tomcat" call away, quite possibly even in the
>> core repositories. But if you ask an average Gnome dev about Java they
>> will still hate it and will continue to do so for a long time.
>
> Perhaps. But then again, that's really no different than the Java
> space's attitude towards Mono - which, like it or not, contains 90% of
> what's being discussed for Java 7 and 8.
I guess so. I must admit that I haven't really tried Mono myself yet,
and that is due to previous experiences with MS as well as Gnome and
the way Miguel tends to write. So all personal and not technical :-)
>> If Sun would really care about the opinion on desktop Java, I'd
>> strongly propose fixing Swing. It still lacks basic features, not just
>> the smarter widgets like the aforementioned DatePicker,
>
> I don't think a DatePicker is a "smarter widget" in that it has always
> been a core part of visual basic and Delphi, and I have yet to see a
> corporate/business application which does not somehow involve the
> manipulation of dates.
It's smarter than most of the ones Swing comes with ;-)
> Again, it's caused by the missing component
> model which can also be witnessed inside Sun itself, they effectively
> sponsor two independent yet similar hierarchical table components, one
> through SwingLabs known as JXTreeTable and the other from OpenIDE
> known as Outline. As someone with considerable investments into
> JXTreeTable, this divide obviously scares me.
I don't really see the connection. In fact you call the two things
"hierarchical table components", so there is some notion of a
component, isn't it? ;-) I think the core problem here is that Sun
never expanded the basic widget set.
>> but even more importantly an application framework to manage
>> setup/teardown actions, session management and so on.
>
> It was not possibly for me to convince Hans into adding a restart
> functionality such as to avoid the aforementioned native wrapper of
> NetBeans. So now if you wish to change Locale in your application, say
> change the language from English to German, you will require the user
> to restart manually (due to the fact that Locale.setLocale() does not
> broadcast any events like a UIManager.setLookAndFeel() call would). So
> I don't see JSR-296 as a great time saver I'm sorry to have to say, a
> NetBeans RCP based approach would be my recommendation after having
> tried both.
That not only seems to be a feature way beyond the basic needs of your
average application, it also seems like the wrong thing to ask: if you
want to change the locale dynamically why don't you ask for the real
thing which would be swapping the locale in the running code.
I don't know what Hans' reason was to reject that feature, but my
first hunch is to follow his lead on that one. Too specific for a
first release when there is so much ground to cover in terms of
features most applications would use.
Peter
Ifnu bima
> no freakin' DatePicker. Most of these issues relates directly or
> indirectly to that of missing a proper component model.
i've recently take a loot at openswing[1] framework who offer a great
escape for JTable and databinding. It has it's own DataGrid
implementation, which is really cool, because you can create it using
visual development in netbeans. So i think Delphi and VB developer
will have good reason to migrate to java.
But, this is not in java standard distribution, so hopefully more
developer promote it to others
--
Marcelo Morales
It seems the link is broken. Maybe http://oswing.sourceforge.net/ ?
Ifnu bima
>> [1] openswing.sourceforge.net
>
> It seems the link is broken. Maybe http://oswing.sourceforge.net/ ?
oh, yes, thank you for the correction
--
Senior Engineer @ ArtiVisi Intermedia
Java Training Center
See our course @ artivisi.com
Casper Bang
> That not only seems to be a feature way beyond the basic needs of your
> average application, it also seems like the wrong thing to ask: if you
> want to change the locale dynamically why don't you ask for the real
> thing which would be swapping the locale in the running code.
world, catering to localization in your application is a major item.
Dynamic locale change would be the best, sure, but as I mentioned,
when you call Locale.setLocale there is no event firing in Swing (i.e.
no LocaleChangeEvent) that widgets, renders etc. could pick up on -
contrary to what we know from UIManager.setLookAndFeel which does
inform each and every component in the object graph that a new L&F has
been set. You can work around this to some degree by manually trying
to handle hooks in some custom LocaleRegistry but it does not work
consistently in practice and it's very hard to maintain, especially
with 3'rd part components which exercises their own view of the world.
> I don't know what Hans' reason was to reject that feature, but my
> first hunch is to follow his lead on that one. Too specific for a
> first release when there is so much ground to cover in terms of
> features most applications would use.
it's singletons (which is used pervasively) so there is just no way to
change locale once the application has been realized. Again, if it can
keep people from having to mess with native launchers (i.e. nb.exe on
windows) then I have a hard time understanding why this is too
specific. The only way I have been able to work around this is to
extend the framework myself and place a bootstrap launcher for an
application specific classloader in the launch method, however I was
never successful in getting this working in a web start scenario so
abandoned it.
I still think it's fair to ask a swing application framework to be
able to handle changing of Locale better than having to ask the user
to restart manually - which get's tricky when you're running in an
applet or webstart context.
/Casper
Peter Becker
>
> On Jul 28, 5:10 am, "Peter Becker" <peter.becker...@gmail.com> wrote:
>> That not only seems to be a feature way beyond the basic needs of your
>> average application, it also seems like the wrong thing to ask: if you
>> want to change the locale dynamically why don't you ask for the real
>> thing which would be swapping the locale in the running code.
>
> That's a common misnomer among english developers, in the rest of the
> world, catering to localization in your application is a major item.
I'm German ;-)
> Dynamic locale change would be the best, sure, but as I mentioned,
> when you call Locale.setLocale there is no event firing in Swing (i.e.
> no LocaleChangeEvent) that widgets, renders etc. could pick up on -
> contrary to what we know from UIManager.setLookAndFeel which does
> inform each and every component in the object graph that a new L&F has
> been set. You can work around this to some degree by manually trying
> to handle hooks in some custom LocaleRegistry but it does not work
> consistently in practice and it's very hard to maintain, especially
> with 3'rd part components which exercises their own view of the world.
Normally I expect an application to pick up the locale from my desktop
environment or OS correctly without me interfering at all. In the
applications I have written I tend to have an override option (e.g.
command line switch), but I don't really see the need for special GUI
features to make changing the locale easy since I would normally
expect a user to change the locale once the right one has been set.
Additionally: what stops you from writing your own application-level
event broker, where you can publish a LocaleChangedEvent that any
interested component can use to update itself?
>> I don't know what Hans' reason was to reject that feature, but my
>> first hunch is to follow his lead on that one. Too specific for a
>> first release when there is so much ground to cover in terms of
>> features most applications would use.
>
> Perhaps, but JSR-296 caches resources extremely aggressively through
> it's singletons (which is used pervasively) so there is just no way to
> change locale once the application has been realized. Again, if it can
> keep people from having to mess with native launchers (i.e. nb.exe on
> windows) then I have a hard time understanding why this is too
> specific. The only way I have been able to work around this is to
> extend the framework myself and place a bootstrap launcher for an
> application specific classloader in the launch method, however I was
> never successful in getting this working in a web start scenario so
> abandoned it.
>
> I still think it's fair to ask a swing application framework to be
> able to handle changing of Locale better than having to ask the user
> to restart manually - which get's tricky when you're running in an
> applet or webstart context.
I just fail to see the use case. Maybe I'm blind on one eye somehow,
but for me picking the locale is something to do only once, so it
don't see why you want to have that change made easier.
Peter
Casper Bang
Thought you might be, power to the Erdinger Weißbier ;)
> Normally I expect an application to pick up the locale from my desktop
> environment or OS correctly without me interfering at all. In the
> applications I have written I tend to have an override option (e.g.
> command line switch), but I don't really see the need for special GUI
> features to make changing the locale easy since I would normally
> expect a user to change the locale once the right one has been set.
hosted on a Citrix cluster or get's it's locale info from invoking
browser it's important to be able to specify locale explicitly, much
more anyway than the ability to change L&F which oddly enough has been
in place in Swing from day one.
> Additionally: what stops you from writing your own application-level
> event broker, where you can publish a LocaleChangedEvent that any
> interested component can use to update itself?
resources are loaded, you are stuck with these for good) and few 3'rd
part components allows the required hooks so it quickly becomes a
housekeeping nightmare with responsibilities scattered throughout your
code.
> I just fail to see the use case. Maybe I'm blind on one eye somehow,
> but for me picking the locale is something to do only once, so it
> don't see why you want to have that change made easier.
not going to agree on this one. It's a real requirement on the
applications I've worked on however, not something I make up just to
argue ;)
/Casper
Alexey Zinger
From: Casper Bang <caspe...@gmail.com>
Subject: [The Java Posse] Re: Desktop Java and Linux
To: "The Java Posse" <java...@googlegroups.com>
Date: Monday, July 28, 2008, 9:27 AM
> I just fail to see the use case. Maybe I'm blind on one eye somehow,
> but for me picking the locale is something to do only once, so it
> don't see why you want to have that change made easier.
I can't explain it any other way than I have, so I guess we're just
not going to agree on this one. It's a real requirement on the
applications I've worked on however, not something I make up just to
argue ;)
I have no horse in this race, but if one person says, "I don't see a use case," and another says, "I do," then provided the second is not completely off his/her rocker, the first person is wrong. As programmers, we should be weary of making assumptions, kinda like "By the time people will need 4 digits to express years, this software will not be in use."
Peter Becker
I totally disagree, that is the road to Wordiness. The development
team has to take care of the design of the user-facing aspects of the
product, which in case of an application is its UI (and the team
hopefully has one or more UI designers), in case of a library or
framework it is the API (and the team should have an experienced API
designer).
There is also a question of resource management. If you just do what
the loudest user wants you typically don't use your resources well and
you will probably never get into any mode where you truly innovate.
That's why I ask for use cases and tend to reject features without. A
use case (or even better "scenario" in the Cooper sense)
contextualizes a feature request and allows the designer of the UI or
API to integrate a user's needs into a consistent whole, instead of
just accumulating features. If a user can not provide that then I
consider it highly suspicious -- chances are that it will be a feature
that's not even going to be used.
From what Casper described his use case is that locales are broken in
his Citrix environment. That is a problem with that environment and
unless it is very common around the target group of the AppFramework I
would say it should have an extremely low priority. It sounds more
like a deployment issue than anything else.
Peter
Casper Bang
> his Citrix environment. That is a problem with that environment and
> unless it is very common around the target group of the AppFramework I
> would say it should have an extremely low priority. It sounds more
> like a deployment issue than anything else.
set the locale to his/her liking upon startup. I mentioned how
NetBeans ships with a native .exe wrapper for Windows JUST to be able
to restart itself, typically after an update. Not sure you could ask
for a better case. You are of course allowed to disagree, meanwhile I
am out of arguments.
/Casper
Peter Becker
You are still talking features here. The aspect I'm lacking is the
motivation in the story. You ask for a feature, but you don't really
explain why someone would need it. I could as well claim that a user
should be able to select an application-specific speed for the mouse
pointer on startup.
It's the motivational angle which distinguishes a good use case from a
plain feature request and it is what can make the difference in
creating something consistent instead of just collecting features.
Peter
paulo
addShutdownhook facility. It is needed for persistent state, however
it is also buggy (to this day) on every platform. Oh the ctrl-c gets
caught wonderfully, but when the user actually initiates shutdown, it
gets cancelled without actually having time to write anything. I know
that the given time is limited, but i'm sure all of us already saw
that funny "closing application" progress bar that appears when a
native application is being closed by the system as a result of user
shut down. That NEVER appears on a java application. Its like there is
a negotiation protocol that is never happening.
Windows goes "shut down" -> native application goes "I need more time"
-> Windows goes "ok"
Windows goes "shut down" -> java application goes "ok"
Casper Bang
> motivation in the story. You ask for a feature, but you don't really
> explain why someone would need it.
seen other people needing this, even Swing experts (your country-lady
Jeanette/Kleopatra from SwingLabs). After all, Java does define a
Locale singleton used to customize localization during an application
launch phase, and which is used successively by most Swing components
to control rendering, formating, input masking etc. I don't think it's
fair to compare such a common thing as localization to a hardware
device and mouse pointer speed. By your own logic, does the current
ability to change L&F lack a good use case as well then?
/Casper
Michael Neale
problem that exists. It will just break again soon in new and unusual
ways.
Peter Becker
>
>> You are still talking features here. The aspect I'm lacking is the
>> motivation in the story. You ask for a feature, but you don't really
>> explain why someone would need it.
>
> I am telling you that I have needed it on several occasions and I have
> seen other people needing this, even Swing experts (your country-lady
> Jeanette/Kleopatra from SwingLabs). After all, Java does define a
> Locale singleton used to customize localization during an application
> launch phase, and which is used successively by most Swing components
> to control rendering, formating, input masking etc. I don't think it's
> fair to compare such a common thing as localization to a hardware
> device and mouse pointer speed.
Localization is there, you are asking for a more dynamic way of changing it.
> By your own logic, does the current
> ability to change L&F lack a good use case as well then?
The use case would be a person trying to find the right L&F for them.
A preview would work (as most desktop environments do), but you don't
want them to restart the application just to find out how it would
look under a different L&F. The locale should not need experimenting.
But even then I would still not consider this high priority looking at
the general state of affairs in the Swing world.
Peter
Michael Neale
On Jul 28, 8:03 am, Dick Wall <dickw...@gmail.com> wrote:
> Ok, all fair points, but now it's open source, it's time to quit
> whining and fix the problems instead.
swing long ago. So I am not sure if abandoning swing is a suitable
fix ? I guess people have done a pretty good job so far, but I think
it took to long and the stench is still around.
>
> As for mono, the apps are great... on Linux. I don't know of a single
> one that has crossed over to another platform though. Does banshee run
> on windows or mac?
discount anything developer centric. For example, Azureus is
reasonably successful (interestingly it doesn't use swing). However,
on most platforms most users tend to move along to a native client
once they discover one as the experience is superior.
robilad
On Jul 27, 3:33 pm, "Peter Becker" <peter.becker...@gmail.com> wrote:
> I think there will be a lot of adoption of server-side Java soon. Both
> Debian and Ubuntu have set up Java taskforces, and I assume the other
> distributions have similar structures. Tools like Tomcat will soon be
> just an "apt-get install tomcat" call away, quite possibly even in the
> core repositories.
effects one can
see now that OpenJDK has made it into the big distributions, is an
increased amount
of Java software becoming part of core of distributions, and increased
interest by
upstreams on packaging their software to run on top of OpenJDK.
cheers,
dalibor topic
Peter Becker
> On Jul 27, 3:33 pm, "Peter Becker" <peter.becker...@gmail.com> wrote:
>
>> I think there will be a lot of adoption of server-side Java soon. Both
>> Debian and Ubuntu have set up Java taskforces, and I assume the other
>> distributions have similar structures. Tools like Tomcat will soon be
>> just an "apt-get install tomcat" call away, quite possibly even in the
>> core repositories.
>
> Tomcat has been in main since a while ;)
Ooops. I didn't even notice -- since I never wanted a GCJ or other
free Java stack I have always installed Java tooling manually. I
suppose I could have installed the Tomcat package this way and then
swapped the Java configuration around. I had been burned with these
approaches on SuSE before, so I got into the habit of just doing
anything Java manually.
So let's rephrase my statement: "soon you can run 'apt-get install
tomcat' and get a Tomcat running on the JDK you want without thinking
too much about it" :-)
Peter
Weiqi Gao
>
> Ooops. I didn't even notice -- since I never wanted a GCJ or other
> free Java stack I have always installed Java tooling manually. I
> suppose I could have installed the Tomcat package this way and then
> swapped the Java configuration around. I had been burned with these
> approaches on SuSE before, so I got into the habit of just doing
> anything Java manually.
Even in the bad old days of closed source Sun JDKs, the JPackage.org
project has made it possible to take the Sun JDK and meld it into
distribution specific RPM or apt packages. Such packages can
participate in the distribution's package dependency calculations just
as the GCJ packages can, thus given you a system where things are easily
managed. Here's my write up for JPackage back in 2004:
http://www.weiqigao.com/blog/2004/11/23/an_introduction_to_jpackage_org.html
However this approach turns out to be foreign and brutal for my Windows-
and/or Mac-oriented Java colleagues that when faced with the task of
setting up a Tomcat or JBoss server on a Linux machine, they'll try it
for five minutes and give up. They then proceed to do the manual
install of a whole bunch of Java stuff and run startUp.sh or some such
in a terminal after every reboot.
> So let's rephrase my statement: "soon you can run 'apt-get install
> tomcat' and get a Tomcat running on the JDK you want without thinking
> too much about it" :-)
Thanks to OpenJDK, Java life on Linux is getting better.
--
Weiqi Gao
weiq...@gmail.com
http://www.weiqigao.com/blog/
robilad
On Jul 28, 10:52 pm, "Peter Becker" <peter.becker...@gmail.com> wrote:
> So let's rephrase my statement: "soon you can run 'apt-get install
> tomcat' and get a Tomcat running on the JDK you want without thinking
> too much about it" :-)
push
to use it as a default dependency for new packages.
cheers,
dalibor topic
Brian Merrill
> So why is desktop Java not winning Linux developers hearts?
>
> Mono. Very successful, at least in the Gnome world, since it does not
> try to go the Swing route and it's very easy to call native C
> libraries (a nightmare to do in Java).
As enthusiastic as I am to see Java succeed on the Linux desktop, this
is one issue that continues to cause me a great deal of concern. The
diversity of shared libraries is one of Linux's greatest strengths.
However, Java seems to be in a particularly poor position to be able
to leverage these existing libraries on Linux efficiently particulary
when it comes to the desktop. Either a developer must write a JNI
wrapper to interface with the library or the functionality of that
library must be rewritten from scratch. JNI continues to be met with
a great deal of hostility and seems to be considered sort of
antithetical to Java. But on the other hand, re-writing perfectly
good C libraries such as ffmpeg or gstreamer for video playback or
encoding into a pure Java implementation is an overwhelming prospect
for what essentially amounts to reinventing a perfectly good wheel.
> Gray box syndrome of Java in Compiz. Continues to play games with
> people, evidently leaving people not liking Java.
Compiz comes along, Swing's window management must be fixed to support
it. I use Xfce + Compiz myself and I've had to submit a number of
Java Swing related "bugs" to the Xfce developers so that they can work
around Swing's quirky window management behavior. Not exactly
endearing to Linux desktop developers. Not to mention, if you want to
extend the functionality of your Gnome, KDE or Xfce desktop by
leveraging the libraries of those desktops, Java again does not appear
to be the right tool for the job either.
So as I see it, the question isn't really whether Java is good
technology or not. The real question is, within the context of the
Linux desktop, what exactly ARE the solutions that Java/Swing brings
to the Linux desktop that would make a developer consider it the
"right" tool for the job? From my perspective, it brings more
problems than it solves.