JavaFX
oryngo
(with 2 days of GWT experience) that JavaFX could be integrated or
replace Javascript/Ajax in the framework.
My point being, should my organization go down the path of GWT with a
revolutionary (if hype is believed) UI enhancement on the way?
What do you think?
TIA,
mike
Jason Essington
death of anything ...
Even the demos seem to indicate that it is more a replacement for
flash with the added annoyance of jnlp (web start)
We'll see if JavaFX gains any traction, but I won't be placing any
bets on it just yet.
-jason
oryngo
Andrés Testi
replacement.
;)
Robert Hanson
It's easy for Sun to say that they have created the ultimate cure, but it another thing to actually prove it.
One good indicator I think are the number of developer posts in the forum. The GWT dev forum opened on May 16th of last year, and on May 17th there were in excess of 170 messages, and in that month (which was only half a month) there were 2750 messages (about 180 per day).
http://groups.google.com/group/Google-Web-Toolkit/about
We will have to see how the JavaFX forums fare, but as of now there are only 5 messages.
https://openjfx.dev.java.net/servlets/ProjectForumView
As for a technology, I think that if you need image perfect interface with rich media, then Flash is the way to go. They have been doing it a long time and have a huge market share. If you are trying to build a complex DHTML/Ajax app, then I would stick with GWT. Or, if you need something in the middle, combine GWT with Flash to get the best of both.
As for where JavaFX fits in, I think it is too early to say, and that is if it takes off they way Sun expects. I do wish them the best of luck though, even if I don't really see the need it fills.
Trivia: Does anyone remember the name of the VB to Java compiler Sun announced at JavaOne last year?
Rob
Michael Neale
Still, JavaFX as a language is interesting to watch. If it does take off, its a nice UI builder language - no reason why GWT couldn't compile it as an alternative to java source.
At least these are not boring times we live in ;)
Michael.
syaskin
able to run on desktop, in the browsers and in mobile devices. So
basically it is a thick client technology and as such requires Java
1.5 or higher installed on the workstations. Before JavaFX developers
had to write code for Desktop, Swing and mobile devices separately.
With JavaFX the code will be the same for all target devices, but who
needs that code on the client side that runs inside JVM? With GWT we
don't run Java on the clients at all....
On May 10, 8:32 am, "Michael Neale" <michael.ne...@gmail.com> wrote:
> Yeah semplice it was called.
>
> Still, JavaFX as a language is interesting to watch. If it does take off,
> its a nice UI builder language - no reason why GWT couldn't compile it as an
> alternative to java source.
>
> At least these are not boring times we live in ;)
>
> Michael.
>
> On 5/10/07, Robert Hanson <iamroberthan...@gmail.com> wrote:
>
>
>
>
>
> > +1 hype.
>
> > It's easy for Sun to say that they have created the ultimate cure, but it
> > another thing to actually prove it.
>
> > One good indicator I think are the number of developer posts in the
> > forum. The GWT dev forum opened on May 16th of last year, and on May 17th
> > there were in excess of 170 messages, and in that month (which was only half
> > a month) there were 2750 messages (about 180 per day).
> >http://groups.google.com/group/Google-Web-Toolkit/about
>
> > We will have to see how the JavaFX forums fare, but as of now there are
> > only 5 messages.
> >https://openjfx.dev.java.net/servlets/ProjectForumView
>
> > As for a technology, I think that if you need image perfect interface with
> > rich media, then Flash is the way to go. They have been doing it a long
> > time and have a huge market share. If you are trying to build a complex
> > DHTML/Ajax app, then I would stick with GWT. Or, if you need something in
> > the middle, combine GWT with Flash to get the best of both.
>
> > As for where JavaFX fits in, I think it is too early to say, and that is
> > if it takes off they way Sun expects. I do wish them the best of luck
> > though, even if I don't really see the need it fills.
>
> > Trivia: Does anyone remember the name of the VB to Java compiler Sun
> > announced at JavaOne last year?
>
> > Rob
>
> > On 5/9/07, Jason Essington <jason.essing...@gmail.com> wrote:
>
> > > I don't see any reason to believe that JavaFX is going to be the
> > > death of anything ...
>
> > > Even the demos seem to indicate that it is more a replacement for
> > > flash with the added annoyance of jnlp (web start)
>
> > > We'll see if JavaFX gains any traction, but I won't be placing any
> > > bets on it just yet.
>
> > > -jason
>
> > > On May 9, 2007, at 1:47 PM, oryngo wrote:
>
> > > > So, how does Suns announcement of JavaFX affect GWT? It seems to me
> > > > (with 2 days of GWT experience) that JavaFX could be integrated or
> > > > replace Javascript/Ajax in the framework.
>
> > > > My point being, should my organization go down the path of GWT with a
> > > > revolutionary (if hype is believed) UI enhancement on the way?
>
> > > > What do you think?
>
> > > > TIA,
> > > > mike- Hide quoted text -
>
> - Show quoted text -
tahir akhtar
oranges. In fact its like saying since now we have microwave oven, who
is going to need a toaster?
Still excitement generated by JavaFX have led many people to proclaim
the death of AJAX. I have written a blog entry here to dispel this
impression. I hope anyone who has experience of supporting Applet on
large scale websites will agree with me
http://tahirakhtar.name/index.php/2007/05/09/javafx-vs-ajax/
Ryan Dewsbury
much tackled.
The real value in Flash is with its GUI tools. It's easy for graphic
desiginers to create rich interfaces that would otherwise be very
complex if written in code. JavaFX seems to be a response to
Silverlight, which boast good language support in the browser. But
again, Flash is great because of the GUI tools for designers.
To get a high performance interface product in the browser you need
speed, distribution, and good GUI design tools. Using GWT/JavaScript
has distribution since its based on browser standards, but it lacks
speed. Flash has all three of these. Silverlight lacks distribution
at this point and I believe it will have good tools. I think if JavaFX
were to succeed in the browser it would need to focus on a great tool
for designers, (GUI, not programmatic)
Also, it would be nice if GWT had Canvas/SVG support so that we
wouldn't need flash for simple low performance things like graphs.
oryngo
However, if JavaFX can do what Javascript can do, but better (i.e.
security, reliability, etc) then it is comparable and worth looking at
seriously.
Basically, it appears that we're moving towards a rich client with JIT
code delivery rather than a thin client. Might not be bad idea if
done correctly. Is this statement an oversimplification?
Thanks for your input and taking the time to blog about it. I see
your arguments, but I think that the advancement or broadband and
"automatic" updates does mitigate the JRE issues. 3 years ago with my
dial up account, if someone had asked me to download a JRE, I would
have been upset. Now it only takes 10 seconds. No harm done. Also,
my Windoze gets an new update every other day, so keeping the JRE up
to date is a no brainer (granted JRE's don't through windows update,
but the possibility exists as well as Java updaters).
GarryKelly
Just my opinion on this but I would see going with GWT as a safer
choice with the JavaFX announcement...
Why...
Well if JavaFX succeeds (and it will be at least a few years before
anyone can say it succeeds) most of your bespoke logic will be in Java
if you use GWT. Better than in javascript... i know it wont move
straight across but ....
if JavaFX fails, nothing lost... I cant imagine Microsoft rushing
to have the JavaFX runtime bundled with the next xp/vista service
pack :) MS have their own Flash alternative coming out....
The great thing about GWT or an existing AJAX library is theres
nothing anyone can do to stop your application working. As its
downloaded as javascript it is already supported by browsers without
downloading new runtimes...
if youre looking at using GWT, i put a few pages together based on my
experiences so far. http://devblog.glowday.com/2007/05/tech-review-google-web-toolkit.html
hope that helps, Garry
Robert Hanson
There is also interest in adding drawing support into core GWT, but I think Java 1.5 support is planned to happen first.
Rob
Reinier Zwitserloot
Apparently it runs on a full blown JRE. Not a j2me remixed for browser
use with multimedia capabilities.. nono. Standard JRE.
What is sun thinking, exactly? I mean, they burned themselves on this
stone once before when their otherwise brilliant 'applet' plan went
down in flames, and now they're going to burn themselves on the exact
same stone all over again? I must be missing something.
A watered down 'consumer' JRE will be released mid-2008 which should
offer less baggage and ostensibly a far smaller footprint, but that's
a bit late, and I'd like to see it before I believe it. Even heard of
flash 'booting up'?
Looking at the entirety of silverlight, Flex, and JavaFX, I don't
think any of them are a serious threat to the hegemony of open crappy
standards (Javascript, html, css, hack stacked on hack stacked on
hack... the lot that GWT basically compiles to). Yes, I mean, you'd
think it'll be easy to do better than what we got now, but the point
is: The implementation isn't it. Clearly. The fact that flash isn't
everywhere (it's in fact almost nowhere if you look at web2 apps, just
to give an example) and the fact that applets failed should tell you
something.
The one thing that might actually upset a couple of things is
silverlight. It would take a killer app, kind of like how gmail
launched XmlHttpRequest into every other browser out there; Opera even
went so far as to release a new version early just to satisfy the vast
masses of opera users clamouring for gmail support, and I totally get
why that happend.
However, I -seriously- doubt any web2 shop will be caught dead
pandering to microsoft, but they drive web innovation right now, which
leaves the question: If silverlight needs a killer app to get there,
who is going to build it? Microsoft sure doesn't look like they have
the stones to do so. They are mostly building train wrecks right now.
The startup crowd won't be doing it either.
Let me highlight that opinion with some backup: Right now, web
development is driven by young naive children who dare think they can
upend the existing industry, patch something together in 6 months, get
some people to use it, and then sell it for 600 million. As ludicrous
as what I just said sounds, that's the reality of today. I'm one of
em, in fact. Yahoo is hanging in there, but they aren't all that
loved, and aside from YUI-EXT, they are just buying lots of existing
property, not creating all that much new stuff themselves. Even if
microsoft buys them, I don't expect them to write the killer app
needed to launch silverlight.
That startup/web2.0 crowd has a couple of very obscure principles at
work, and one of them is street cred. To become succesfull you
absolutely NEED to become popular. To become popular you absolutely
NEED early adopters. Early adopters are the key. Without it, no
sustained community. Without a sustained community, no site. Even if
you do have some users, without a community, well, it's not hard to
build a webapp, and without a community there's nothing keeping your
users from flocking en masse to something else.
Early Adopters are weird. Less than 15% of them use Internet Explorer.
In fact, over a quarter use a mac and most of those use safari. Opera
holds at least 5%. Firefox controls the bulk. They are rather
sensitive about the direction your service appears to be going. If it
looks or feels a bit too commercial they will build their own
alternative before you can so much as start talking to google or
seqoia. Nothing quite like pioneering silverlight to give yourself
that gleam of scary that'll make your users run for the hills. It has
to be a bloody revelation in order to be accepted - it would have to
be something absolutely unreproducable using the current stack + flash
widgets (kind of like how youtube uses flash just for video play.
That's begrudgingly accepted.) I can't imagine right now what that
revelation is going to be.
In short: Your best investment right now is more GWT.
wojciech.ha...@gmail.com
and is pretty easy to use IMHO.
Ian deSouza
I've been a long time Swing as well as J2EE developer. I started
looking at GWT as well, for "lightweight client" development for the
web.
But the scripting declarative model appeals to me. Also the device
agnostic approach is really appealing. JavaFX isn't an true applet
replacement, nor a web start replacement, nor a J2ME replacement...
its a font end for those technologies.
I like what I see and am going to give it a try. I don't think I've
seen something this major since the advent of Java itself. Its
attempting to solve a very big question of the day; namely the device
independence of your presentation layer. I'm still to understand a lot
of things but will be focusing on learning the communication
mechanisms etc.. but hopefully it will be like Java itself (class-
wise) although with the less strict typing issues (IMHO a good thing).
Architecturally, I like it better than GWT in skinning the Web2 on
multiple devices problem. My two cents is being thrown into the JavaFX
pot (at least for now).
charlie...@gmail.com
comparable to GWT, as one other poster said "apples and oranges."
Those things are all plugin based, not native to the browser. Native
to the browser matters - that is a large part of the point of GWT, and
something Bruce and Joel always hammer when they do a presentation
(users like bookmarks, the back button, super fast page loads without
proprietary add-ons, etc).
Sure HTML/JavaScript/CSS have issues as standards, and a lot of
architectural "challenges" (as RZ noted in this thread), but they are
what we have in terms of the Internet and browsers. Until browsers
change (and new specs are underway) to get more sophisticated
themselves, Ajax will matter. And of course GWT is a great way to
"do" Ajax.
JavaFX is notable for the declarative markup it provides and the ease
of making UI stuff work, but the whole premise of write once run on
desktop/web/mobile - while admirable - is flawed. JavaFX is a way to
make applets, if we are talking about the "web" part, and let's face
it, applets have issues and do not really compete with Ajax (for a
host of reasons, another discussion). I think Chris Oliver's work is
very valuable in many respects, but the current state of things is
hardly a "Flash killer", or a challenge to GWT. The innovation in GWT
is the fact that it compiles to HTML/JavaScript - JavaFX on the other
hand is a different way to write Swing apps and applets (arguably a
better way, but the result is the same).
Now if Sun would follow the GWT lead, and think about maybe leveraging
some GWT stuff to make JavaFX capable of itself popping out either a
desktop Swing app, a mobile app, OR an HTML/JavaScript version (rather
than an applet) - that would be ideal. I think a few years from now
lot's of folks will likely be taking the path GWT is blazing, rather
than trying to improve their respevtive plugins, just work within what
the browser gives you.
Ian deSouza
theory work within the HTML/JavaScript/AJAX framework if the JavaFX
was on the server (and a corresponding JavaFX engine sat along side it
there).
Thats what's why its advantageous. When high band width pipes come
along, run it one way, if you're in a limited device, use the same app
in another way. Its just an abstraction of the presentation and since
we can't (currently) run Swing on our mobile phones, we interpret the
JavaFX to work within that constraint. If running stand alone, use
with a Swing desktop. If running on the web, use the locally cached
JVM and JavaFX.
With GWT, you're still stuck within the GWT environment generating a
simulated presentation layer in JavaScript.. and you don't have the
freedom of developing presentation and communication classes outside
of the GWT design. If I write in JavaFX, the application exists for
future devices/architectures, not just the JavaScript model (which
won't run on my cell phone).
charlie...@gmail.com
still think it's a different ballgame.
Specifically "With GWT, you're still stuck within the GWT environment
generating asimulated presentation layer in JavaScript.. " actually
no, the entire APP is run in a browser, the whole thing, not just the
presentation layer, and it's not "simulated." Yes, it is JavaScript
- but that is an advantage, not a drawback - thats what makes it a
"native" browser app.
You can use it for just presentation, but that is not the "canonical"
design or point of GWT. And it does have to talk to a server backend
to persist/sync the model, but in that regard it's no different from
any other full blown desktop app.
You are absolutely right though about the "outside the GWT design"
part. GWT is built for making rich apps INSIDE web browsers, and
distrubuting those apps so they run on the client (not the view built
on the server and pushed to the client with each page like server side
web apps)- it will not address using the same code base on a mobile
device and on a server and on a desktop, fair enough (well, unless the
mobile device does run a full on browser and has JavaScript - which
might be feasible at some point, at least as feasible as Java itself
on same said device).
Ian deSouza
and gets cheaper, this all may be a mute point (eventually), but for
the next few years anyway, having an app run on various hardware
(presentation with underlying logic) "run" without change in coding,
is handy.
Plus, I just like the idea of interpreting (not generating) code
directly on the runtime environment, whether that be a browser or J2SE
or J2EE... ( etc.?). In that sense writing a script that will run on
these various runtime "platforms" instead of using a generator with a
single design framework out of your hands seems limiting. But there
are still some questions I have with JavaFX that I'm still trying to
determine ... (going through the language reference now, and soon will
be trying it out the various features it has -- like how will it
communicate back to a server, capability for reflection, etc), but
thus far, I'm intrigued, if not infatuated with it.
On May 16, 6:11 pm, "charlie.coll...@gmail.com"
Ian deSouza
Reinier Zwitserloot
Creating a single version in a single distribution format with a
single GUI definition that works well enough on all platforms to be
worth it, can't be done.
The compile cycle of GWT would be completely unacceptable for standard
java development. For JS development it's bearable because there are
practical size limits on a project anyhow, AND the alternative
(megabytes worth of files to download) is much worse than waiting for
the GWT compiler to do its thing.
Any serious and usable GUI designed for your average desktop just
won't work well on a mobile phone. The input method, output screen
size, and usual use case are all completely different between the two;
a single interface that works equally well on all types and sizes of
machines is a pipe dream from a usability viewpoint. Add to this that
it's annoying from a software engineering standpoint as well and you
have your conclusion: It'll never work.
Not to rain on JavaFX - I've seen the F3 stuff (JavaFX is the new name
I think) and it's absolutely great. Having the same language for
different platforms also useful. But "write once run anywhere" doesn't
fly with GUIs, and never will.
Ian deSouza
> java development. For JS development it's bearable because there are
> practical size limits on a project anyhow, AND the alternative
> (megabytes worth of files to download) is much worse than waiting for
> the GWT compiler to do its thing.
I agree that if there's a heavy additional jar files to download (on
top of the existing J2SE base) it would be annoying (especially on
dialup). However, if you assume the J2SE runtime is already there,
comparable to other plug-ins like acrobat, windows media player, etc,
and all you have to pull from the server is JavaFX Script, I think its
going to be pretty fast and dynamic and a good user experience (still
to try out my own stuff, but the demos convince me this is the case --
I already have J2SE 6 loaded on my machine however).
>
> Any serious and usable GUI designed for your average desktop just
> won't work well on a mobile phone. The input method, output screen
> size, and usual use case are all completely different between the two;
> a single interface that works equally well on all types and sizes of
> machines is a pipe dream from a usability viewpoint. Add to this that
> it's annoying from a software engineering standpoint as well and you
> have your conclusion: It'll never work.
I think what you are referring to is the ratio of widgets to screen
total area. If in fact, the buttons, etc can be squeezed down and
still be readable in the same proportion as the desktop GUI, I don't
think this will be an issue. Haven't done a lot of research on the
feasibility of this yet however.
> Not to rain on JavaFX - I've seen the F3 stuff (JavaFX is the new name
> I think) and it's absolutely great. Having the same language for
> different platforms also useful. But "write once run anywhere" doesn't
> fly with GUIs, and never will.
>
I think a lot of people were saying that about Java on multiple
desktop OS systems, and I think that for the large part its been
proven to work on multiple OS just fine (it can be done wrong however
(not using layout managers, etc) in which case we may want to point
the finger to the developer.
Reinier Zwitserloot
> top of the existing J2SE base) it would be annoying (especially on
> dialup). However, if you assume the J2SE runtime is already there,
> comparable to other plug-ins like acrobat, windows media player, etc,
> and all you have to pull from the server is JavaFX Script, I think its
> going to be pretty fast and dynamic and a good user experience (still
> to try out my own stuff, but the demos convince me this is the case --
> I already have J2SE 6 loaded on my machine however).
Fortunately Sun has realized the notion that you may safely assume a
JRE, let alone the latest version, is very much flawed. The open
sourcing should take care of *BSD and linux, and they are hard at work
making the windows version easier than ever to install. Let's hope
they get it right this time.
Regardless, even flash is STILL disliked today, and it's not just
because flash isn't open source. I fear the idea of applets (in the
sense that JavaFX is no different) will not be accepted nearly as
readily.
> I think what you are referring to is the ratio of widgets to screen
> total area. If in fact, the buttons, etc can be squeezed down and
> still be readable in the same proportion as the desktop GUI, I don't
> think this will be an issue. Haven't done a lot of research on the
> feasibility of this yet however.
>
If the desktop GUI can be shrunk completely automatically to the size
of a mobile phone screen, you have 2 options:
1. The app was extremely trivial and by no means a reasonable use
case.
2. The design was horrible.
How would you compress the standard view of del.icio.us? How about
gmail? How about gcal? 95% of the blogs out there? None of them 'just
compress' very well. That was my point. There are exceptions, sure.
google groups will probably fare more or less allright, though 'reply
+ reply to author + forward + rate this post + star icons' is already
getting on the lengthy side of a standard 'vertically oriented' mobile
phone screen, and wrapped it wouldn't look that great.
Assuming desktops are 1024x768 at the very least is normal for web
apps these days; 800x600 is the absolute bare minimum these days.
Mobile phones aren't remotely close to those resolutions, and even if
they were, you couldn't read the text.
>
> I think a lot of people were saying that about Java on multiple
> desktop OS systems, and I think that for the large part its been
> proven to work on multiple OS just fine (it can be done wrong however
> (not using layout managers, etc) in which case we may want to point
> the finger to the developer.
I wasn't one of those people. Though if we look back, I think I was
wrong, actually: There are almost no desktop java apps out there. The
two most used java desktop apps are Azureus and Eclipse (pure
conjecture, if I'm wrong do let me know), which are both actually SWT
based. Of course, there are almost no desktop apps out there written
in anything but the platform's native language (C on linux, C++ on
windows, ObjC on macs), so this is hardly java's fault. I think the
Write Once Run Anywhere paradigm fell on its arse when things that you
clearly wanted to do in desktop apps but clearly couldn't be done in a
platform agnostic way were simply made IMPOSSIBLE without jumping
through lots of nasty JNI-based hoops, instead of just supplying
libraries that only worked on one platform. I refer to e.g. changing
ownerships or timestamps of files, changing user privileges (tomcat
still can't run on port 80 on linux without doing lots of vague
gruntwork. Jetty has taken the considerable trouble of shipping a
large array of .so files for a number of POSIX OSes to do it, but it
really wasn't easy), and more.
Python and Ruby and the like got this right: They are generally
platform independent, but there are also 'posix', 'win32', etc
libraries.
Shame java is still not moving anywhere near implementing such things.
I'd actually love a java-based norton commander clone that I could use
on my debian servers, my mac desktop, and when I'm fixing some
problems, on other people's windows machines just by pinging a
webstart page.
Ian deSouza
> JRE, let alone the latest version, is very much flawed. The open
> sourcing should take care of *BSD and linux, and they are hard at work
> making the windows version easier than ever to install. Let's hope
> they get it right this time.
I agree. I think they are aware of the time its takes to background
load the JRE the first time and that they are working on some sort of
incremental load to streamline the JRE setup. After its loaded
however, all JavaFX (light weight compared to Swing) should load fast.
> Regardless, even flash is STILL disliked today, and it's not just
> because flash isn't open source. I fear the idea of applets (in the
> sense that JavaFX is no different) will not be accepted nearly as
> readily.
>
I think its a matter of the right tool for the job. In some case Flash
may be the right tool. I think JavaFX should be easier to develop some
of these kinds of apps.
> If the desktop GUI can be shrunk completely automatically to the size
> of a mobile phone screen, you have 2 options:
>
> 1. The app was extremely trivial and by no means a reasonable use
> case.
> 2. The design was horrible.
>
> How would you compress the standard view of del.icio.us? How about
> gmail? How about gcal? 95% of the blogs out there? None of them 'just
> compress' very well. That was my point. There are exceptions, sure.
> google groups will probably fare more or less allright, though 'reply
> + reply to author + forward + rate this post + star icons' is already
> getting on the lengthy side of a standard 'vertically oriented' mobile
> phone screen, and wrapped it wouldn't look that great.
>
> Assuming desktops are 1024x768 at the very least is normal for web
> apps these days; 800x600 is the absolute bare minimum these days.
> Mobile phones aren't remotely close to those resolutions, and even if
> they were, you couldn't read the text.
You may be right on this. But it you did have two displays >>sizes<<
you could use one JavaFX script for the smaller screen and another for
the larger screen. But you wouldn't have to care if its Swing based
(J2SE) or J2ME based.
>
> > I think a lot of people were saying that about Java on multiple
> > desktop OS systems, and I think that for the large part its been
> > proven to work on multiple OS just fine (it can be done wrong however
> > (not using layout managers, etc) in which case we may want to point
> > the finger to the developer.
>
> I wasn't one of those people. Though if we look back, I think I was
> wrong, actually: There are almost no desktop java apps out there. The
> two most used java desktop apps are Azureus and Eclipse (pure
> conjecture, if I'm wrong do let me know), which are both actually SWT
> based. Of course, there are almost no desktop apps out there written
> in anything but the platform's native language (C on linux, C++ on
> windows, ObjC on macs), so this is hardly java's fault. I think the
> Write Once Run Anywhere paradigm fell on its arse when things that you
> clearly wanted to do in desktop apps but clearly couldn't be done in a
> platform agnostic way were simply made IMPOSSIBLE without jumping
> through lots of nasty JNI-based hoops, instead of just supplying
> libraries that only worked on one platform. I refer to e.g. changing
> ownerships or timestamps of files, changing user privileges (tomcat
> still can't run on port 80 on linux without doing lots of vague
> gruntwork. Jetty has taken the considerable trouble of shipping a
> large array of .so files for a number of POSIX OSes to do it, but it
> really wasn't easy), and more.
In JDK 6.0 its there... (I agree something take a while to get there,
but they do come). Besides there was always the possibility to do this
with Runtime and issue a shell cmd depending on the OS (with out
having to resort to JNI).
http://java.sun.com/javase/6/docs/api/java/io/File.html#setExecutable(boolean)
http://java.sun.com/javase/6/docs/api/java/io/File.html#setWritable(boolean)
http://java.sun.com/javase/6/docs/api/java/io/File.html#setLastModified(long)
> Python and Ruby and the like got this right: They are generally
> platform independent, but there are also 'posix', 'win32', etc
> libraries.
>
> Shame java is still not moving anywhere near implementing such things.
> I'd actually love a java-based norton commander clone that I could use
> on my debian servers, my mac desktop, and when I'm fixing some
> problems, on other people's windows machines just by pinging a
> webstart page.
With Java 6, you can write in Python and Ruby with all the power of
Java to call into from those scripts.
http://java.sun.com/developer/technicalArticles/J2SE/Desktop/scripting/
Best of both worlds... and now with JavaFX to add to the list.
Juha
Firstly, the way GWT builds the graphical system is the old way, in
the manner of AWT and Swing.That's not enough improvement. The JavaFX
way is much better, but I don't think GWT should adopt it directly.
The way I think GWT should take is by replacing Java with Groovy,
which could be regarded as a dynamic form of Java. One notable
addition you get is the SwingBuilder. Programming a GUI with the
SwingBuilder is very much like doing it with JavaFX, but the rest of
the environment is full Java, and not so limited as with JavaFX.
What GWT then should do is generate the GUI into any viable browser
environment: JavaScript, JavaFX, or perhaps Flash. Like it's done now
with JavaScript.
The most important of the effects that JavaFX can do can be simulated
in JavaScript, so I think that should be the first ones added to GWT.
The result of utilizing Groovy would be to keep all of the current
GWT, but add the SwingBuilder for building the GUI. Emulate JavaFX in
that environment, and regard JavaFX as one alternative target for code
generation.
-- Juha
Reinier Zwitserloot
Nobody is stopping you!