Production version of Java 6 on Mac OS X has been released
7 views
Skip to first unread message
Ricardo
Apr 29, 2008, 7:09:16 PM4/29/08
to The Java Posse
From the Apple site:
http://www.apple.com/support/downloads/javaformacosx105update1.html
Java for Mac OS X 10.5 Update 1 adds support for Java SE 6
Last Modified on: April 29, 2008
Article: 307403
This update provides Java SE 6 version 1.6.0_05.
This release does not change the default version of Java. This release
is only for Mac OS X v10.5.2 and later, and should not be installed on
earlier versions of Mac OS X. This release is for 64-bit Intel-based
Macs only and cannot run on PowerPC-based or 32-bit Intel-based Macs.
Software developers can visit the Java Reference Library for
information on this release's features
Note: Only works on 64-bit Intel Macs running OS X 10.5
-Richard
http://www.apple.com/support/downloads/javaformacosx105update1.html
Java for Mac OS X 10.5 Update 1 adds support for Java SE 6
Last Modified on: April 29, 2008
Article: 307403
This update provides Java SE 6 version 1.6.0_05.
This release does not change the default version of Java. This release
is only for Mac OS X v10.5.2 and later, and should not be installed on
earlier versions of Mac OS X. This release is for 64-bit Intel-based
Macs only and cannot run on PowerPC-based or 32-bit Intel-based Macs.
Software developers can visit the Java Reference Library for
information on this release's features
Note: Only works on 64-bit Intel Macs running OS X 10.5
-Richard
Mark Derricutt
Apr 29, 2008, 7:13:40 PM4/29/08
to java...@googlegroups.com
I vote this be the Java Posse's "java app of the week", or is that "jvm of the week".
--
"It is easier to optimize correct code than to correct optimized code." -- Bill Harlan
On Wed, Apr 30, 2008 at 11:09 AM, Ricardo <richar...@gmail.com> wrote:
From the Apple site:
http://www.apple.com/support/downloads/javaformacosx105update1.html
"It is easier to optimize correct code than to correct optimized code." -- Bill Harlan
zorro2b
Apr 29, 2008, 8:54:19 PM4/29/08
to The Java Posse
We still can't run Eclipse or any Eclipse RCP apps on it though, as it
uses Carbon not Cocoa:
http://www.eclipsezone.com/eclipse/forums/t97750.html
I presume this is why they haven't made it the default JVM.
On Apr 30, 9:13 am, "Mark Derricutt" <m...@talios.com> wrote:
> I vote this be the Java Posse's "java app of the week", or is that "jvm of
> the week".
>
uses Carbon not Cocoa:
http://www.eclipsezone.com/eclipse/forums/t97750.html
I presume this is why they haven't made it the default JVM.
On Apr 30, 9:13 am, "Mark Derricutt" <m...@talios.com> wrote:
> I vote this be the Java Posse's "java app of the week", or is that "jvm of
> the week".
>
Nigel
Apr 30, 2008, 4:35:40 AM4/30/08
to The Java Posse
wow, the thread http://www.eclipsezone.com/eclipse/forums/t97750.html
has been locked down because they didn't like people telling them that
SWT was a bad idea....
has been locked down because they didn't like people telling them that
SWT was a bad idea....
Chris Adamson
Apr 30, 2008, 5:07:38 AM4/30/08
to The Java Posse
I think you have that backwards. Apple's JVM has been Cocoa-based for
a while now (since 1.4). SWT is Carbon-based. And even that wasn't a
deal-breaker before. The real problem seems to be that:
* The new JVM is 64-bit Intel-only
* You can't mix 64-bit and 32-bit code in an OSX process
* Carbon is 32-bit only and apparently will remain that way
* SWT is Carbon-based
For what it's worth, QuickTime for Java won't work on the Mac's Java 6
for exactly the same reason. Carbon is de facto (but not de jure)
deprecated, and therefore any Java libraries that use Carbon are in
big trouble.
--Chris
a while now (since 1.4). SWT is Carbon-based. And even that wasn't a
deal-breaker before. The real problem seems to be that:
* The new JVM is 64-bit Intel-only
* You can't mix 64-bit and 32-bit code in an OSX process
* Carbon is 32-bit only and apparently will remain that way
* SWT is Carbon-based
For what it's worth, QuickTime for Java won't work on the Mac's Java 6
for exactly the same reason. Carbon is de facto (but not de jure)
deprecated, and therefore any Java libraries that use Carbon are in
big trouble.
--Chris
Jess Holle
Apr 30, 2008, 7:05:12 AM4/30/08
to java...@googlegroups.com
whose time has come and gone. Swing works quite nicely at this point.
[This point meaning recent Java 6 updates, especially update 10.] SWT
was certainly a great kick in Sun's pants to fix Swing, but now seems to
have no point. It may well be that SWT's underlying native
implementation is much cleaner than that of the JRE's AWT layer, as
stated in recent podcasts. Unless/until this is used to clean up the
JRE itself, though, it's not relevant to me as Swing provides what I
need, works well, is built-in, and the ugliness of AWT is irrelevant to
my work.
At this point Eclipse's use of SWT is a reason for me to avoid Eclipse.
Why? Because if/when I throw some time into writing a plug-in, I want
to use the same GUI toolkit that works everywhere else (all platforms,
applets, web start, etc) with no native component deployment. It also
clearly reduces the portability of Eclipse both in absolute terms and in
terms of heavily customizing the look-and-feel to each platform -- which
is an issue when needing to support and occasionally work directly upon
many different platforms.
Does the "Swing on SWT" stuff [I forgot the name] allow Eclipse to run
on Java 6 on the Mac?
--
Jess Holle
Jess Holle
Apr 30, 2008, 7:12:38 AM4/30/08
to java...@googlegroups.com
Jess Holle wrote:
> have no point. It may well be that SWT's underlying native
> implementation is much cleaner than that of the JRE's AWT layer, as
> stated in recent podcasts. Unless/until this is used to clean up the
> JRE itself, though, it's not relevant to me as Swing provides what I
> need, works well, is built-in, and the ugliness of AWT is irrelevant to
> my work.
>
P.S. I also don't see any need to have SWT as a whole integrated into > have no point. It may well be that SWT's underlying native
> implementation is much cleaner than that of the JRE's AWT layer, as
> stated in recent podcasts. Unless/until this is used to clean up the
> JRE itself, though, it's not relevant to me as Swing provides what I
> need, works well, is built-in, and the ugliness of AWT is irrelevant to
> my work.
>
the JRE itself. If someone uses the ideas therein to improve
upon/replace the current "behind the scenes" implementation of AWT,
that's well and good, but AWT is irrelevant except as base classes to
Swing classes 99% of the time at this point.
Reinier Zwitserloot
Apr 30, 2008, 9:45:08 AM4/30/08
to The Java Posse
I was a great fan of SWT a long time ago and I'm a lot more
comfortable writing SWT code than AWT/Swing simply because I have so
much more experience with SWT.
However, I Agree: SWT has outlived its usefulness.
Here's my letter to the java/eclipse foundation wish fairy:
1. Take a couple of good ideas from SWT and move them to AWT/Swing.
Here's a non-exhaustive list:
A. AFAIK, AWT/Swing does not throw an exception if you try to
fiddle with the GUI outside of the EDT. This causes an endless stream
of questions on e.g. ##java where we have to ~edt (ask the bot
to explain the edt) a couple of times A DAY. Why in #@*$)#(@*$ name
doesn't swing do a runtime thread check like SWT does? It can't
possibly be 'because it adds slowness' - SWT cared a lot more about
speed (yet another principle that is no longer very relevant)
and it's had that thread check since day #1. Add it. I'm not even
gonna say please.
edt stands for Event Dispatch Thread. I'm not sure if that's the
official name.
B. Apparently, SWT is a bit cleaner under the hood and is somewhat
easier to port around; swing works on more platforms only because sun
spends
a lot more time on it. Possibly swing needs to work on top of
SWT instead of AWT. However, the amount of effort required to pull
this off
in comparison to the gains don't quite seem to be worth it.
Thus, perhaps take the principle that in SWT only the bare minimum of
JNI code is
used and the rest is done in java, because java in general is a
lot more maintainable, especially amongst a big camp of java
programmers.
C. Add methods that allow you to write the local OS's widgets. I'm
not sure if this should be added on to AWT (because as I understand
it, swing
pretty much does all the painting), or preferably its a
LookAndFeel choice, but from time to time you want to write a very
simple app that just
integrates well with the OS you're on. I believe swing currently
tries to implement this by emulating the styles of various OSes (e.g.
the way
I understand it, the mac os look and feel works on windows too).
That seems a heck of a lot of effort and doesn't look like it'll ever
work quite right.
2. The Eclipse Foundation should take the swt on swing project a lot
more seriously and officially start end-of-lifing SWT. Because
rewriting eclipse
seems almost impossible, eclipse (and RCP apps) will continue to
run on swt-on-swing perhaps forever.
I wonder if the Eclipse crowd is willing to make that jump. Perhaps
java can take the high road and explicitly pick up a bunch of SWT
ideas for swing as an open invitation.
comfortable writing SWT code than AWT/Swing simply because I have so
much more experience with SWT.
However, I Agree: SWT has outlived its usefulness.
Here's my letter to the java/eclipse foundation wish fairy:
1. Take a couple of good ideas from SWT and move them to AWT/Swing.
Here's a non-exhaustive list:
A. AFAIK, AWT/Swing does not throw an exception if you try to
fiddle with the GUI outside of the EDT. This causes an endless stream
of questions on e.g. ##java where we have to ~edt (ask the bot
to explain the edt) a couple of times A DAY. Why in #@*$)#(@*$ name
doesn't swing do a runtime thread check like SWT does? It can't
possibly be 'because it adds slowness' - SWT cared a lot more about
speed (yet another principle that is no longer very relevant)
and it's had that thread check since day #1. Add it. I'm not even
gonna say please.
edt stands for Event Dispatch Thread. I'm not sure if that's the
official name.
B. Apparently, SWT is a bit cleaner under the hood and is somewhat
easier to port around; swing works on more platforms only because sun
spends
a lot more time on it. Possibly swing needs to work on top of
SWT instead of AWT. However, the amount of effort required to pull
this off
in comparison to the gains don't quite seem to be worth it.
Thus, perhaps take the principle that in SWT only the bare minimum of
JNI code is
used and the rest is done in java, because java in general is a
lot more maintainable, especially amongst a big camp of java
programmers.
C. Add methods that allow you to write the local OS's widgets. I'm
not sure if this should be added on to AWT (because as I understand
it, swing
pretty much does all the painting), or preferably its a
LookAndFeel choice, but from time to time you want to write a very
simple app that just
integrates well with the OS you're on. I believe swing currently
tries to implement this by emulating the styles of various OSes (e.g.
the way
I understand it, the mac os look and feel works on windows too).
That seems a heck of a lot of effort and doesn't look like it'll ever
work quite right.
2. The Eclipse Foundation should take the swt on swing project a lot
more seriously and officially start end-of-lifing SWT. Because
rewriting eclipse
seems almost impossible, eclipse (and RCP apps) will continue to
run on swt-on-swing perhaps forever.
I wonder if the Eclipse crowd is willing to make that jump. Perhaps
java can take the high road and explicitly pick up a bunch of SWT
ideas for swing as an open invitation.
Jess Holle
Apr 30, 2008, 9:58:46 AM4/30/08
to java...@googlegroups.com
Reinier Zwitserloot wrote:
> I was a great fan of SWT a long time ago and I'm a lot more
> comfortable writing SWT code than AWT/Swing simply because I have so
> much more experience with SWT.
>
> However, I Agree: SWT has outlived its usefulness.
>
> Here's my letter to the java/eclipse foundation wish fairy:
>
> 1. Take a couple of good ideas from SWT and move them to AWT/Swing.
> Here's a non-exhaustive list:
> A. AFAIK, AWT/Swing does not throw an exception if you try to
> fiddle with the GUI outside of the EDT. This causes an endless stream
> of questions on e.g. ##java where we have to ~edt (ask the bot
> to explain the edt) a couple of times A DAY. Why in #@*$)#(@*$ name
> doesn't swing do a runtime thread check like SWT does? It can't
> possibly be 'because it adds slowness' - SWT cared a lot more about
> speed (yet another principle that is no longer very relevant)
> and it's had that thread check since day #1. Add it. I'm not even
> gonna say please.
> edt stands for Event Dispatch Thread. I'm not sure if that's the
> official name.
>
Agreed! I've heard this requested a good number of times from folk > I was a great fan of SWT a long time ago and I'm a lot more
> comfortable writing SWT code than AWT/Swing simply because I have so
> much more experience with SWT.
>
> However, I Agree: SWT has outlived its usefulness.
>
> Here's my letter to the java/eclipse foundation wish fairy:
>
> 1. Take a couple of good ideas from SWT and move them to AWT/Swing.
> Here's a non-exhaustive list:
> A. AFAIK, AWT/Swing does not throw an exception if you try to
> fiddle with the GUI outside of the EDT. This causes an endless stream
> of questions on e.g. ##java where we have to ~edt (ask the bot
> to explain the edt) a couple of times A DAY. Why in #@*$)#(@*$ name
> doesn't swing do a runtime thread check like SWT does? It can't
> possibly be 'because it adds slowness' - SWT cared a lot more about
> speed (yet another principle that is no longer very relevant)
> and it's had that thread check since day #1. Add it. I'm not even
> gonna say please.
> edt stands for Event Dispatch Thread. I'm not sure if that's the
> official name.
>
ranging from experts to rookies.
This could be done via assertions -- that way you can check for this
during development and suffer no performance penalty during normal
execution.
> B. Apparently, SWT is a bit cleaner under the hood and is somewhat
> easier to port around; swing works on more platforms only because sun
> spends
> a lot more time on it. Possibly swing needs to work on top of
> SWT instead of AWT. However, the amount of effort required to pull
> this off
> in comparison to the gains don't quite seem to be worth it.
> Thus, perhaps take the principle that in SWT only the bare minimum of
> JNI code is
> used and the rest is done in java, because java in general is a
> lot more maintainable, especially amongst a big camp of java
> programmers.
>
It's not Swing that's the issue for porting here -- it's AWT and its
mounds of native code.
Anything the Sun guys can learn from SWT here, e.g. deprecating
non-Swing AWT components and reworking most Component and Container (the
AWT base classes actually used by Swing) in a really clean manner
targeted just at supporting Swing, would be good.
> C. Add methods that allow you to write the local OS's widgets. I'm
> not sure if this should be added on to AWT (because as I understand
> it, swing
> pretty much does all the painting), or preferably its a
> LookAndFeel choice, but from time to time you want to write a very
> simple app that just
> integrates well with the OS you're on. I believe swing currently
> tries to implement this by emulating the styles of various OSes (e.g.
> the way
> I understand it, the mac os look and feel works on windows too).
> That seems a heck of a lot of effort and doesn't look like it'll ever
> work quite right.
>
I guess that might be important in the consumer space. For
enterprise/business apps this only seems important when Sun louses up
JFileChooser on Windows.
--
Jess Holle
Brice
Apr 30, 2008, 10:01:36 AM4/30/08
to The Java Posse
I could be entirely wrong, but I think this only applies to running
Eclipse in 64-bit mode, which hasn't been the default. I haven't
grabbed the latest release, but the prior beta releases defaulted to
32-bit mode, and I believe I was able to run Eclipse just fine
(because you don't run into a mixed-mode environment). From within
Eclipse, running in Java6-32bit, you can still define JREs that run in
64-bit, to run your app or your app server (I was able to run JBoss in
64-bit mode just fine).
So, since I don't see a TON of reason to actually run Eclipse in 64-
bit mode (need more than 2GB heap allocated?), I'm not sure this is
such a big issue?
Eclipse in 64-bit mode, which hasn't been the default. I haven't
grabbed the latest release, but the prior beta releases defaulted to
32-bit mode, and I believe I was able to run Eclipse just fine
(because you don't run into a mixed-mode environment). From within
Eclipse, running in Java6-32bit, you can still define JREs that run in
64-bit, to run your app or your app server (I was able to run JBoss in
64-bit mode just fine).
So, since I don't see a TON of reason to actually run Eclipse in 64-
bit mode (need more than 2GB heap allocated?), I'm not sure this is
such a big issue?
Marcelo Fukushima
Apr 30, 2008, 2:11:20 PM4/30/08
to java...@googlegroups.com
im guessing the problem is that the official apple java is 64bits
only, witch means youd have to run eclipse in 64bits but because of
SWT, you cant
only, witch means youd have to run eclipse in 64bits but because of
SWT, you cant
--
[]'s
Marcelo Takeshi Fukushima
Juan Marín Otero
Apr 30, 2008, 3:49:11 PM4/30/08
to java...@googlegroups.com
Can someone clarify this?. I am waiting for my new Apple laptop to be delivered, can I or can I not use Eclipse with Java 5/6 on Leopard?.
--
Juan Marín Otero
Ingeniero de Montes
Consultor SIG
-------Visita mis blog en---------------------
http://programacionsig.blogspot.com
---------------------------------------------------
http://guachintoneando.blogspot.com
---------------------------------------------------
--
Juan Marín Otero
Ingeniero de Montes
Consultor SIG
-------Visita mis blog en---------------------
http://programacionsig.blogspot.com
---------------------------------------------------
http://guachintoneando.blogspot.com
---------------------------------------------------
2008/4/30 Marcelo Fukushima <take...@gmail.com>:
zorro2b
Apr 30, 2008, 4:44:04 PM4/30/08
to The Java Posse
You can ONLY run Eclipse on Java 5 on the Mac. You can define Java 6
as an available JVM and launch you apps from it under Java 6, but
Eclipse itself will only run under Java 5.
On May 1, 5:49 am, "Juan Marín Otero" <juan.marin.ot...@gmail.com>
wrote:
> ---------------------------------------------------
>
> 2008/4/30 Marcelo Fukushima <takesh...@gmail.com>:
as an available JVM and launch you apps from it under Java 6, but
Eclipse itself will only run under Java 5.
On May 1, 5:49 am, "Juan Marín Otero" <juan.marin.ot...@gmail.com>
wrote:
> Can someone clarify this?. I am waiting for my new Apple laptop to be
> delivered, can I or can I not use Eclipse with Java 5/6 on Leopard?.
>
> --
> Juan Marín Otero
> Ingeniero de Montes
> Consultor SIG
>
> -------Visita mis blog en---------------------http://programacionsig.blogspot.com
> ---------------------------------------------------http://guachintoneando.blogspot.com
> delivered, can I or can I not use Eclipse with Java 5/6 on Leopard?.
>
> --
> Juan Marín Otero
> Ingeniero de Montes
> Consultor SIG
>
> -------Visita mis blog en---------------------http://programacionsig.blogspot.com
> ---------------------------------------------------
>
> 2008/4/30 Marcelo Fukushima <takesh...@gmail.com>:
Reinier Zwitserloot
Apr 30, 2008, 5:08:24 PM4/30/08
to The Java Posse
Just to assuage your fears: What zorro2b said is correct. Eclipse runs
on java5, and any code you write with eclipse can run under java6. In
fact you can use the debugger and everything (fortunately the debugger
connects to a different running java process). Unless that code uses
SWT or an SWT derived platform such as RCP.
on java5, and any code you write with eclipse can run under java6. In
fact you can use the debugger and everything (fortunately the debugger
connects to a different running java process). Unless that code uses
SWT or an SWT derived platform such as RCP.
Brice
Apr 30, 2008, 5:21:08 PM4/30/08
to The Java Posse
You can most definitely run Eclipse on Leopard, using Java 5. I do it
day in, day out. And frankly, until Eclipse core or a plugin you
depend on requires Java 6, its probably not a big deal that the
current incarnation of Java 6 on Leopard *cannot* run Eclipse. I say
current, because its always possible that Apple is still working on
the 32-bit support in Java 6.
Does anyone know of any Eclipse requirements (core or plugins) for
Java 6?
As others have posted - you can certainly configure Java 6 as a
runtime in Eclipse and debugging / running / launching app servers is
all just fine with Java 6, so long as Eclipse was launched with Java 5
(in 32-bit mode, the default for Java 5 on Leopard).
Cheers,
Brice
On Apr 30, 2:49 pm, "Juan Marín Otero" <juan.marin.ot...@gmail.com>
wrote:
> ---------------------------------------------------
>
> 2008/4/30 Marcelo Fukushima <takesh...@gmail.com>:
day in, day out. And frankly, until Eclipse core or a plugin you
depend on requires Java 6, its probably not a big deal that the
current incarnation of Java 6 on Leopard *cannot* run Eclipse. I say
current, because its always possible that Apple is still working on
the 32-bit support in Java 6.
Does anyone know of any Eclipse requirements (core or plugins) for
Java 6?
As others have posted - you can certainly configure Java 6 as a
runtime in Eclipse and debugging / running / launching app servers is
all just fine with Java 6, so long as Eclipse was launched with Java 5
(in 32-bit mode, the default for Java 5 on Leopard).
Cheers,
Brice
On Apr 30, 2:49 pm, "Juan Marín Otero" <juan.marin.ot...@gmail.com>
wrote:
> Can someone clarify this?. I am waiting for my new Apple laptop to be
> delivered, can I or can I not use Eclipse with Java 5/6 on Leopard?.
>
> --
> Juan Marín Otero
> Ingeniero de Montes
> Consultor SIG
>
> -------Visita mis blog en---------------------http://programacionsig.blogspot.com
> ---------------------------------------------------http://guachintoneando.blogspot.com
> delivered, can I or can I not use Eclipse with Java 5/6 on Leopard?.
>
> --
> Juan Marín Otero
> Ingeniero de Montes
> Consultor SIG
>
> -------Visita mis blog en---------------------http://programacionsig.blogspot.com
> ---------------------------------------------------
>
> 2008/4/30 Marcelo Fukushima <takesh...@gmail.com>:
Brice
Apr 30, 2008, 5:30:32 PM4/30/08
to The Java Posse
I suppose you would be hosed if you're writing RCP apps that require
Java 6, but otherwise, you should be fine.
And for all the fuss that folks are making about this, I'd have to
just add one more thought: this boils down to nothing more than native
libraries that aren't compatible with a "new" platform on Java. That's
always been a known problem with native libraries, whether its SWT, or
a native Oracle driver, or whatever. The solution is for SWT to be
ported to 64-bit, which unfortunately means SWT has to use Cocoa, not
Carbon. Again, not really anything you can complain about ... Carbon's
deprecated and not supported for 64-bit, so that's that. These are the
headaches that native library builders have to live with (or not, if
they choose not to update), unfortunately, which is why many folks
don't write native code ...
Cheers,
Brice
Java 6, but otherwise, you should be fine.
And for all the fuss that folks are making about this, I'd have to
just add one more thought: this boils down to nothing more than native
libraries that aren't compatible with a "new" platform on Java. That's
always been a known problem with native libraries, whether its SWT, or
a native Oracle driver, or whatever. The solution is for SWT to be
ported to 64-bit, which unfortunately means SWT has to use Cocoa, not
Carbon. Again, not really anything you can complain about ... Carbon's
deprecated and not supported for 64-bit, so that's that. These are the
headaches that native library builders have to live with (or not, if
they choose not to update), unfortunately, which is why many folks
don't write native code ...
Cheers,
Brice
Peter Becker
Apr 30, 2008, 7:03:37 PM4/30/08
to java...@googlegroups.com
I've been doing that for my Swing code for a while: every method that I expect to be run on the EDT starts with an assertion that we are in fact on the EDT. That not only notifies people if something is wrong, it also seems more successful as documentation than JavaDoc schemes.
If the basic Swing components would do that with a decent error message, a lot of Swing issues would be caught much earlier (assuming people use the -ea of course).
> B. Apparently, SWT is a bit cleaner under the hood and is somewhatIt's not Swing that's the issue for porting here -- it's AWT and its
> easier to port around; swing works on more platforms only because sun
> spends
> a lot more time on it. Possibly swing needs to work on top of
> SWT instead of AWT. However, the amount of effort required to pull
> this off
> in comparison to the gains don't quite seem to be worth it.
> Thus, perhaps take the principle that in SWT only the bare minimum of
> JNI code is
> used and the rest is done in java, because java in general is a
> lot more maintainable, especially amongst a big camp of java
> programmers.
>
mounds of native code.
Anything the Sun guys can learn from SWT here, e.g. deprecating
non-Swing AWT components and reworking most Component and Container (the
AWT base classes actually used by Swing) in a really clean manner
targeted just at supporting Swing, would be good.
While I can see some more @deprecated in the AWT code I find it hard to see Sun drop support for any of it. Not that it wouldn't be the right thing to do, it's just not Sun.
> C. Add methods that allow you to write the local OS's widgets. I'mI guess that might be important in the consumer space. For
> not sure if this should be added on to AWT (because as I understand
> it, swing
> pretty much does all the painting), or preferably its a
> LookAndFeel choice, but from time to time you want to write a very
> simple app that just
> integrates well with the OS you're on. I believe swing currently
> tries to implement this by emulating the styles of various OSes (e.g.
> the way
> I understand it, the mac os look and feel works on windows too).
> That seems a heck of a lot of effort and doesn't look like it'll ever
> work quite right.
>
enterprise/business apps this only seems important when Sun louses up
JFileChooser on Windows.
Being a Linux user myself I still have my hopes up that some day Linux gets relevant. I know it is relevant for some people in the enterprise world (there are large deployments of Linux desktops in some places), but I agree that the market is still too small. But it is growing: (K)Ubuntu seems to be doing very well.
The mismatch with the file chooser is really bad under KDE. I never really noticed the problem under Windows that much, but the KDE file chooser is so good for keyboard junkies like me that I rarely use the mouse for file operations. Having a JFileChooser hits you really hard when you are in that state of mind. And even with the mouse things are quite different, e.g. the lack of a bread-trail is quite obvious once you had that for a while. And KDE defaults to single-click for open, which you get used to.
But live isn't much better when using SWT on KDE: you get the Gnome file chooser, which is either not as good as the KDE one or just too different -- I certainly notice it when I get it. Fortunately the only SWT application I use is Eclipse, in which I rarely use the file chooser. And the KDE-Gnome integration is good enough nowadays not to notice otherwise (they can share most look and feel settings).
I think personally I'd probably be most happy with a really powerful JFileChooser mostly independent of the underlying OS, though. As I user I have to use different platforms every now and then and would prefer the consistency. As a developer I rather know what the user gets. If the file chooser is different for each platform I really have to keep that in mind when developing, particularly if I have an accessory such as extra save options or a preview -- something like that can look very different in the different file choosers.
What I would like is that Swing supports more look and feel notions of the underlying desktop environment, most noticably the double click (there is no double click in Swing, you have to emulate it but you don't get the information what settings are used and have to make up your own double-click threshold), but also higher-level abstractions such as "select" and "open" as mouse operations to abstract from the single-click vs. double-click question.
Peter
Neil Bartlett
May 1, 2008, 4:54:09 AM5/1/08
to The Java Posse
> Does anyone know of any Eclipse requirements (core or plugins) for
> Java 6?
Eclipse runs fine on Java 1.4. In fact most of the core bundles work
> Java 6?
on Java 1.3 for compatibility with JavaME. The big debate in
Eclipseland at the moment is whether and how to introduce dependencies
on Java 5, since doing so would break compatibility with mobile
platforms. The idea of introducing a Java 6 dependency into core
Eclipse is pretty much inconceivable.
The JDT debugger has some support for Java 6 features, but they
require Java 6 only in the target runtime, not in the IDE.
Anybody who has a requirement for SWT on Java 6 on Mac OS should
consider helping with the <a href="http://www.eclipse.org/swt/
cocoaport.php">SWT Cocoa port</a>. They can already run Eclipse on
Cocoa, but it is not very stable at present.
Neil
Will
May 3, 2008, 6:53:23 AM5/3/08
to The Java Posse
On May 1, 6:21 am, Brice <bdr...@gmail.com> wrote:
> As others have posted - you can certainly configure Java 6 as a
> runtime in Eclipse and debugging / running / launching app servers is
> all just fine with Java 6, so long as Eclipse was launched with Java 5
> (in 32-bit mode, the default for Java 5 on Leopard).
Ummm... sorry to ask a stupid question, but where the hell is Java 6
> As others have posted - you can certainly configure Java 6 as a
> runtime in Eclipse and debugging / running / launching app servers is
> all just fine with Java 6, so long as Eclipse was launched with Java 5
> (in 32-bit mode, the default for Java 5 on Leopard).
installed to? I'm trying to set up Java 6 as a runtime in Eclipse, but
I don't know where to point it.
Thanks in advance for your help.
Will.
David Linsin
May 3, 2008, 6:55:50 AM5/3/08
to java...@googlegroups.com
Hey Will,
check out /System/Library/Frameworks/JavaVM.framework/
with kind regards,
David Linsin
- - - - - - - - - - - - - - - - - - - - - - - -
email: dli...@gmail.com
blog: http://dlinsin.blogspot.com
Will
May 3, 2008, 7:06:32 AM5/3/08
to The Java Posse
Thanks!!
On May 3, 7:55 pm, David Linsin <dlin...@gmail.com> wrote:
> Hey Will,
>
> check out /System/Library/Frameworks/JavaVM.framework/
>
> with kind regards,
>
> David Linsin
> - - - - - - - - - - - - - - - - - - - - - - - -
> email: dlin...@gmail.com
On May 3, 7:55 pm, David Linsin <dlin...@gmail.com> wrote:
> Hey Will,
>
> check out /System/Library/Frameworks/JavaVM.framework/
>
> with kind regards,
>
> David Linsin
> - - - - - - - - - - - - - - - - - - - - - - - -
Reply all
Reply to author
Forward
0 new messages