Google - missing the point?
2 views
Skip to first unread message
Jess Holle
Jun 27, 2009, 11:27:56 AM6/27/09
to java...@googlegroups.com
I concur with Dick in one respect here:
Google seems to be working really hard to use Java to author client software while avoiding actually using it on the client -- at least with GWT.
While GWT is really cool for those who want to write Java, not JavaScript, it is essentially a giant workaround. The real solution is better Java Plug-In penetration and just using it. Java 6 Update 10 and later are actually rather good.
GWT predates Java 6 Update 10 and I can understand that even now Google may feel the Plug-In is not a feasible alternative (i.e. that they really can't help drive this into clients despite Chrome, etc). I do sometimes wonder whether Google even wants Java on the client -- as they have more influence and traction in the [D]HTML space. In any event, I believe Google could expend a little of their influence to help Java (and JavaFX) become a real force on the client -- but they clearly have chosen not to attempt that.
Then there's Android. I have to really applaud Google here in one respect -- Java ME is a throwback to ancient Java history and is just begging to be by-passed. Specifically, there's no support for Java 5 language features in ME and no plans whatsoever to add these! On the other hand, Google went a lot further to develop their own set of client libraries rather than using any existing client libraries -- and thus is creating another splinter UI platform space like SWT did before it.
--
Jess Holle
Google seems to be working really hard to use Java to author client software while avoiding actually using it on the client -- at least with GWT.
While GWT is really cool for those who want to write Java, not JavaScript, it is essentially a giant workaround. The real solution is better Java Plug-In penetration and just using it. Java 6 Update 10 and later are actually rather good.
GWT predates Java 6 Update 10 and I can understand that even now Google may feel the Plug-In is not a feasible alternative (i.e. that they really can't help drive this into clients despite Chrome, etc). I do sometimes wonder whether Google even wants Java on the client -- as they have more influence and traction in the [D]HTML space. In any event, I believe Google could expend a little of their influence to help Java (and JavaFX) become a real force on the client -- but they clearly have chosen not to attempt that.
Then there's Android. I have to really applaud Google here in one respect -- Java ME is a throwback to ancient Java history and is just begging to be by-passed. Specifically, there's no support for Java 5 language features in ME and no plans whatsoever to add these! On the other hand, Google went a lot further to develop their own set of client libraries rather than using any existing client libraries -- and thus is creating another splinter UI platform space like SWT did before it.
--
Jess Holle
Alexey Zinger
Jun 27, 2009, 2:44:30 PM6/27/09
to java...@googlegroups.com
I have to disagree regarding GWT. I've been using it extensively on new and legacy web app projects. I could kinda see using applets in situations, where I knew there was no need to ever interoperate with DOM (and the state the plug-in is in now, still leaves it behind, IMO), but once you are faced with a need to integrate new RIA-like features into an existing app, it's either hand-coding JS or GWT. Don't get me wrong, GWT is far from perfect: when you hit the edge of its capabilities and have to step out into native JS or come up with clever CSS or HTML hacks, the elegance is gone in an instant and you're up against an even uglier battle trying to make these leaky abstractions that don't get along play nice (GWT still doesn't let you control THEAD elements in tables!). But
overall, I see it more as a higher level alternative to writing complex DHTML, not a straight replacement for applets or Flash.
Alexey
From: Jess Holle <je...@ptc.com>
To: java...@googlegroups.com
Sent: Saturday, June 27, 2009 11:27:56 AM
Subject: [The Java Posse] Google - missing the point?
From: Jess Holle <je...@ptc.com>
To: java...@googlegroups.com
Sent: Saturday, June 27, 2009 11:27:56 AM
Subject: [The Java Posse] Google - missing the point?
Reinier Zwitserloot
Jun 27, 2009, 2:45:53 PM6/27/09
to The Java Posse
The central purpose of GWT, as I understand it, is to make writing
apps 'like gmail' easier. In other words, all these things are either
outright annoying or inconvenient with GWT, or at the very least no
easier than with vanilla javascript:
- any website that has more than one logical page. e.g. all of gmail
is just 'gmail.google.com'. There's not gmail.com/message/12345. Wave
is similar in that respect.
- Working with mostly static content and injecting only a few dynamic
behaviours.
- Working close to the core platform; letting the server render some
HTML, grabbing it via XML, and just stuffing it via .innerHTML into a
div container.
On the other hand, these are very niche applications where GWT shines:
- working with huge code bases for a single website: GWT has
namespaces, static type checking, and the most aggressive code
reduction strategy available today. Because of java's manifest,
nominal, static, strong type system, as well as GWT's atomic
compilation process (no reflection or class loading of any sort) GWT
can easily determine if a given method (or even an entire classworth)
is never actually called on, and if not, just eliminate it wholesale.
That kind of source code base reduction is pointless everywhere,
EXCEPT the web, especially for an app like gmail that is loaded
gazillions of times a day.
- As mentioned, size reduction. Especially for complicate web apps,
writing it in GWT means smaller downloads. This really is niche; if
you're building a new web service and squeezing the last couple of
bytes out of the download is important to you, then you're doing
something wrong. google of course does, and should, worry about such
things, and GWT reflects this. GWT also reduces size by way of
compressing all images into a single one, rolling all JS into a single
file, and even loading _just_ the code that is tailormade for the
target Browser AND language. (With 10 languages supported and 4
browsers, for example, GWT produces 40 files, one for each combo, and
uses a small dynamic loader that gives just the right one to the user
agent).
- unifying server and client code bases. You can put your form
validation code in a common package and call it from both your GWT and
your server code. There are tricks available to try this with
javascript (from writing in an HLL and translating this to BOTH java
and JS, to using Rhino to run the JS code server-side), but in GWT its
trivial, for obvious reasons. It goes much beyond this though; for
example, the code that decides where an email should be rendered in a
gmail discussion tree (is this a reply to this email, or that email?
This is non-trivial) can exist on both ends; that way, when new email
come in, the server just has to hand the client the content, and let
the client sort out where it's supposed to go. When building the
database indices so that an entire thread can be retrieved quickly,
that same code runs server side.
Here's my advice for building web services:
1) Start with JQuery, and keep it simple. 95% of all projects ought to
be html, css, and jquery, with something simple on the backend.
2) Only if you really know what you are doing, and you have some very
non-standard requirements, look elsewhere. GWT is a good place to
look. So is webstart/fx. (and similar technologies, but, hey, this is
a java-centric newsgroup!)
> Google seems to be working /really/ hard to use Java to author client
apps 'like gmail' easier. In other words, all these things are either
outright annoying or inconvenient with GWT, or at the very least no
easier than with vanilla javascript:
- any website that has more than one logical page. e.g. all of gmail
is just 'gmail.google.com'. There's not gmail.com/message/12345. Wave
is similar in that respect.
- Working with mostly static content and injecting only a few dynamic
behaviours.
- Working close to the core platform; letting the server render some
HTML, grabbing it via XML, and just stuffing it via .innerHTML into a
div container.
On the other hand, these are very niche applications where GWT shines:
- working with huge code bases for a single website: GWT has
namespaces, static type checking, and the most aggressive code
reduction strategy available today. Because of java's manifest,
nominal, static, strong type system, as well as GWT's atomic
compilation process (no reflection or class loading of any sort) GWT
can easily determine if a given method (or even an entire classworth)
is never actually called on, and if not, just eliminate it wholesale.
That kind of source code base reduction is pointless everywhere,
EXCEPT the web, especially for an app like gmail that is loaded
gazillions of times a day.
- As mentioned, size reduction. Especially for complicate web apps,
writing it in GWT means smaller downloads. This really is niche; if
you're building a new web service and squeezing the last couple of
bytes out of the download is important to you, then you're doing
something wrong. google of course does, and should, worry about such
things, and GWT reflects this. GWT also reduces size by way of
compressing all images into a single one, rolling all JS into a single
file, and even loading _just_ the code that is tailormade for the
target Browser AND language. (With 10 languages supported and 4
browsers, for example, GWT produces 40 files, one for each combo, and
uses a small dynamic loader that gives just the right one to the user
agent).
- unifying server and client code bases. You can put your form
validation code in a common package and call it from both your GWT and
your server code. There are tricks available to try this with
javascript (from writing in an HLL and translating this to BOTH java
and JS, to using Rhino to run the JS code server-side), but in GWT its
trivial, for obvious reasons. It goes much beyond this though; for
example, the code that decides where an email should be rendered in a
gmail discussion tree (is this a reply to this email, or that email?
This is non-trivial) can exist on both ends; that way, when new email
come in, the server just has to hand the client the content, and let
the client sort out where it's supposed to go. When building the
database indices so that an entire thread can be retrieved quickly,
that same code runs server side.
Here's my advice for building web services:
1) Start with JQuery, and keep it simple. 95% of all projects ought to
be html, css, and jquery, with something simple on the backend.
2) Only if you really know what you are doing, and you have some very
non-standard requirements, look elsewhere. GWT is a good place to
look. So is webstart/fx. (and similar technologies, but, hey, this is
a java-centric newsgroup!)
> Google seems to be working /really/ hard to use Java to author client
> software while avoiding actually using it on the client -- at least with
> GWT.
>
> While GWT is really cool for those who want to write Java, not
> JavaScript, it is essentially a giant workaround. The real solution is
> better Java Plug-In penetration and just using it. Java 6 Update 10 and
> later are actually rather good.
>
> GWT predates Java 6 Update 10 and I can understand that even now Google
> may feel the Plug-In is not a feasible alternative (i.e. that they
> really can't help drive this into clients despite Chrome, etc). I do
> sometimes wonder whether Google even /wants/ Java on the client -- as
> GWT.
>
> While GWT is really cool for those who want to write Java, not
> JavaScript, it is essentially a giant workaround. The real solution is
> better Java Plug-In penetration and just using it. Java 6 Update 10 and
> later are actually rather good.
>
> GWT predates Java 6 Update 10 and I can understand that even now Google
> may feel the Plug-In is not a feasible alternative (i.e. that they
> really can't help drive this into clients despite Chrome, etc). I do
> they have more influence and traction in the [D]HTML space. In any
> event, I believe Google /could /expend a little of their influence to
Joshua Marinacci
Jun 27, 2009, 5:11:53 PM6/27/09
to java...@googlegroups.com
With the new plugin Java and JavaFX applets can easily interoperate with the DOM. You can call javascript from java and vice versa. It's quite nice!
Augusto
Jun 27, 2009, 7:16:48 PM6/27/09
to The Java Posse
On the subject of HTML 5 driven apps like Google Wave (didn't know it
required html 5 until this last podcast). The pirate bay is releasing
their answer to YouTube via the VideoBay.
Interestingly they will only support HTML 5 browsers and up, so I
guess there's more than just Google already itching to support the new
HTML standard instead of other RIA technologies. Interesting.
http://pinstack.blogspot.com/2009/06/video-bay-launching-with-html-5-and-ogg.html
http://tech.slashdot.org/story/09/06/27/2018242/The-Video-Bay-Now-In-Beta
required html 5 until this last podcast). The pirate bay is releasing
their answer to YouTube via the VideoBay.
Interestingly they will only support HTML 5 browsers and up, so I
guess there's more than just Google already itching to support the new
HTML standard instead of other RIA technologies. Interesting.
http://pinstack.blogspot.com/2009/06/video-bay-launching-with-html-5-and-ogg.html
http://tech.slashdot.org/story/09/06/27/2018242/The-Video-Bay-Now-In-Beta
Michael Neale
Jun 27, 2009, 8:57:34 PM6/27/09
to The Java Posse
Reinier's summary seems accurate based on my experience (with both a
LOT of GWT and jQuery) - good advice - the comments on the podcast
seemed factually quite wrong (but no one has experience with GWT, so
not surprising) - I guess (another) interview with someone from the
GWT community/google could be good?
re HTML5: no wave doesn't require it AFAIK - it seems a lot of the
HTML5 stuff is press noise, not actual technical reality - so its
using browser "standards" as they are now (and yes, iPhone safari
supports HTML5).
re Joshua: yeah I like that idea. Years ago I wanted to do that with
applets and "live connect" but it wasn't easy, I do like the promise
of it now - but the problem is its still a promise, its a risk to take
over "vanilla" web things as they are now (as clunky as they may
seem).
On Jun 28, 9:16 am, Augusto <augusto.sellh...@gmail.com> wrote:
> On the subject of HTML 5 driven apps like Google Wave (didn't know it
> required html 5 until this last podcast). The pirate bay is releasing
> their answer to YouTube via the VideoBay.
>
> Interestingly they will only support HTML 5 browsers and up, so I
> guess there's more than just Google already itching to support the new
> HTML standard instead of other RIA technologies. Interesting.
>
> http://pinstack.blogspot.com/2009/06/video-bay-launching-with-html-5-...
>
> http://tech.slashdot.org/story/09/06/27/2018242/The-Video-Bay-Now-In-...
LOT of GWT and jQuery) - good advice - the comments on the podcast
seemed factually quite wrong (but no one has experience with GWT, so
not surprising) - I guess (another) interview with someone from the
GWT community/google could be good?
re HTML5: no wave doesn't require it AFAIK - it seems a lot of the
HTML5 stuff is press noise, not actual technical reality - so its
using browser "standards" as they are now (and yes, iPhone safari
supports HTML5).
re Joshua: yeah I like that idea. Years ago I wanted to do that with
applets and "live connect" but it wasn't easy, I do like the promise
of it now - but the problem is its still a promise, its a risk to take
over "vanilla" web things as they are now (as clunky as they may
seem).
On Jun 28, 9:16 am, Augusto <augusto.sellh...@gmail.com> wrote:
> On the subject of HTML 5 driven apps like Google Wave (didn't know it
> required html 5 until this last podcast). The pirate bay is releasing
> their answer to YouTube via the VideoBay.
>
> Interestingly they will only support HTML 5 browsers and up, so I
> guess there's more than just Google already itching to support the new
> HTML standard instead of other RIA technologies. Interesting.
>
>
> http://tech.slashdot.org/story/09/06/27/2018242/The-Video-Bay-Now-In-...
Joshua Marinacci
Jun 27, 2009, 9:07:06 PM6/27/09
to java...@googlegroups.com
give it a try. The browser plugin has made huge strides in the past
year.
year.
Michael Neale
Jun 28, 2009, 2:23:57 AM6/28/09
to The Java Posse
I love what bits I have seen of JavaFX that have worked well. I am
with Joe - the key is now the experience for end users (including me)
on all the browsers: firstly, does everyone have it? if not, how quick/
idiot proof is it to be up and running. I still noticed too many of
the demos were asking me to "trust" them (and using certs my system
didn't really recognise). So its not FX itself (which is 110% awesome)
but everything else.
Which brings us back to the modularity issue... (as I am guessing
modularising the VM itself will help with the above somewhat.
with Joe - the key is now the experience for end users (including me)
on all the browsers: firstly, does everyone have it? if not, how quick/
idiot proof is it to be up and running. I still noticed too many of
the demos were asking me to "trust" them (and using certs my system
didn't really recognise). So its not FX itself (which is 110% awesome)
but everything else.
Which brings us back to the modularity issue... (as I am guessing
modularising the VM itself will help with the above somewhat.
Joshua Marinacci
Jun 28, 2009, 2:51:13 AM6/28/09
to java...@googlegroups.com
yes, we are all working on the end user experience. We are looking at
the whole stack from memory usage to excess class loading to graphics
performance to getting the new plugin out there. (not to mention the
Java Store). more good things are on the way.
-=j
the whole stack from memory usage to excess class loading to graphics
performance to getting the new plugin out there. (not to mention the
Java Store). more good things are on the way.
-=j
tronda
Jun 28, 2009, 4:42:58 AM6/28/09
to The Java Posse
> While GWT is really cool for those who want to write Java, not
> JavaScript, it is essentially a giant workaround. The real solution is
> better Java Plug-In penetration and just using it. Java 6 Update 10 and
> later are actually rather good.
>
> GWT predates Java 6 Update 10 and I can understand that even now Google
> may feel the Plug-In is not a feasible alternative (i.e. that they
> really can't help drive this into clients despite Chrome, etc). I do
> sometimes wonder whether Google even /wants/ Java on the client -- as
> JavaScript, it is essentially a giant workaround. The real solution is
> better Java Plug-In penetration and just using it. Java 6 Update 10 and
> later are actually rather good.
>
> GWT predates Java 6 Update 10 and I can understand that even now Google
> may feel the Plug-In is not a feasible alternative (i.e. that they
> really can't help drive this into clients despite Chrome, etc). I do
> they have more influence and traction in the [D]HTML space. In any
> event, I believe Google /could /expend a little of their influence to
> help Java (and JavaFX) become a real force on the client -- but they
> clearly have chosen not to attempt that.
I think the main reason is what Carl said. With HTML 5 Google is able
> clearly have chosen not to attempt that.
to drive the standard. With JavaFX/Applet/JavaPlugin this isn't the
case. Flash the same. The web standards has served Google good in the
past and I think this will be able to serve Google good in the future.
I also think it is important to get momentum behind HTML 5 and Google
is probably pushing it to avoid having developers turning to Flash/
JavaFX/Silverlight as a solution for their highly interactive content.
I consider this a good thing.
------- Trond
Jess Holle
Jun 28, 2009, 10:33:03 AM6/28/09
to java...@googlegroups.com
tronda wrote:
> I think the main reason is what Carl said. With HTML 5 Google is able
> to drive the standard. With JavaFX/Applet/JavaPlugin this isn't the
> case. Flash the same. The web standards has served Google good in the
> past and I think this will be able to serve Google good in the future.
> I also think it is important to get momentum behind HTML 5 and Google
> is probably pushing it to avoid having developers turning to Flash/
> JavaFX/Silverlight as a solution for their highly interactive content.
> I consider this a good thing.
>
While I'd consider pushing developers away from Silverlight a good > I think the main reason is what Carl said. With HTML 5 Google is able
> to drive the standard. With JavaFX/Applet/JavaPlugin this isn't the
> case. Flash the same. The web standards has served Google good in the
> past and I think this will be able to serve Google good in the future.
> I also think it is important to get momentum behind HTML 5 and Google
> is probably pushing it to avoid having developers turning to Flash/
> JavaFX/Silverlight as a solution for their highly interactive content.
> I consider this a good thing.
>
thing, I can't consider architecting with any substantive piece of code
in JavaScript a good thing -- and interactive HTML == JavaScript in most
any real case.
If you have a tiny client UI, fine, but as things grow JavaScript
becomes a really nasty technology.
GWT is helpful in getting you around this -- until you hit the wall.
Java and JavaFX are far more attractive in this regard.
--
Jess Holle
Casper Bang
Jun 28, 2009, 11:26:42 AM6/28/09
to The Java Posse
It's all about the lowest common denominator, which is what Google
really gets. They don't care about Java in the same passionate/
religious way as i.e. Dick, to them it's just a tool and a marked to
be harvested. That was one of the most interesting parts of the latest
podcast, Dick putting Carl in the "hot chair". I've criticized the
Java Posse in the past for seeking the path of least resistance and
favouring other things over actual engineering/technology aspects, but
this conversation I thought was superb!
I know there's no chance in he// that will happen, but another
enlightening interview could be with Androids Dan Bornstein. Again,
forgetting about religion and focusing on engineering, I would love to
know how come Mono did not look interesting to them when it provides a
lot of free machinery and performance: http://www.koushikdutta.com/2009/01/dalvik-vs-mono.html
(And no, there's no patent patent issue here, just as Android isn't
currently using Swing, a Mono version would not use WinForms so
Microsoft couldn't do squad if they wanted to.)
All of Google's fancy interactive stuff runs on the iPhone and Android
devices - meanwhile Flash and JavaFX does not (well ok, Flash does
but currently only released for the Hero). And giant hack or not, GWT
makes the users as well as developers happy. The same argument goes
for Android, App Engine etc. And at the end of the that day, isn't
that all that really matters?
/Casper
really gets. They don't care about Java in the same passionate/
religious way as i.e. Dick, to them it's just a tool and a marked to
be harvested. That was one of the most interesting parts of the latest
podcast, Dick putting Carl in the "hot chair". I've criticized the
Java Posse in the past for seeking the path of least resistance and
favouring other things over actual engineering/technology aspects, but
this conversation I thought was superb!
I know there's no chance in he// that will happen, but another
enlightening interview could be with Androids Dan Bornstein. Again,
forgetting about religion and focusing on engineering, I would love to
know how come Mono did not look interesting to them when it provides a
lot of free machinery and performance: http://www.koushikdutta.com/2009/01/dalvik-vs-mono.html
(And no, there's no patent patent issue here, just as Android isn't
currently using Swing, a Mono version would not use WinForms so
Microsoft couldn't do squad if they wanted to.)
All of Google's fancy interactive stuff runs on the iPhone and Android
devices - meanwhile Flash and JavaFX does not (well ok, Flash does
but currently only released for the Hero). And giant hack or not, GWT
makes the users as well as developers happy. The same argument goes
for Android, App Engine etc. And at the end of the that day, isn't
that all that really matters?
/Casper
Alexey Zinger
Jun 28, 2009, 1:22:43 PM6/28/09
to java...@googlegroups.com
Just looked at the latest docs. Still seems like a tough task to render small clipboard-friendly elements.
Alexey
From: Joshua Marinacci <jos...@gmail.com>
To: java...@googlegroups.com
Sent: Saturday, June 27, 2009 5:11:53 PM
Subject: [The Java Posse] Re: Google - missing the point?
From: Joshua Marinacci <jos...@gmail.com>
To: java...@googlegroups.com
Sent: Saturday, June 27, 2009 5:11:53 PM
Subject: [The Java Posse] Re: Google - missing the point?
Michael Neale
Jun 28, 2009, 8:35:26 PM6/28/09
to The Java Posse
Great to hear Josh. Of all the "todo" things, I think the user
experience regarding how is starts up, how it installs if needed, will
make or break this. The rest of it is certainly great, would be a
shame for it to go to waste for the "last mile" !
experience regarding how is starts up, how it installs if needed, will
make or break this. The rest of it is certainly great, would be a
shame for it to go to waste for the "last mile" !
Bill Robertson
Jun 30, 2009, 2:03:54 AM6/30/09
to The Java Posse
I like Mr. Wall w/o the filters, and listening to this episode has
finally got me around to getting this off of my chest. Maybe the rest
of the world will curse him for winding me up, but I'd like to say
thanks.
What I find disturbing is the fracturing of the Java runtime and
language features. Some features and runtime classes aren't available
when its compiled down to Javascript. A disjoint set of things is
unavailable in Android, and yet another different set of things is not
available in the app engine.
The Dalvik (sp?) VM, "Its Java source code that compiles down to a
load of horse manure wrapped in legalese." e.g. I have my nice JavaFX
binaries. They even ran in the outdated 1.5 JVM on my mac. Can I pop
it on my G1 and see how it looks there? No.
Yes, I am oversimplifying it. For example, I couldn't just pop them
onto a Linux box and expect them to work until a few weeks ago,
however, most of it did work, so the option existed. A few months ago
I had to "port" a medium sized swing application to Linux. I unzipped
the jars, changed some paths in the property file, zipped them back up
again and it ran perfectly. These are examples what makes the Java
platform so great, and this is what Google wants you to forget about
and lock you in to their tools and their services.
The app engine is probably the worst, because its really nothing more
than a thinly veiled attempt at vendor lock-in. Correct me if I'm
wrong, the example that I recall is ImageIO. The libraries do not
exist in the GAE environment, but Google does have their own handy
APIs to do what you need. Run away.
Will I ever need something like Google App Engine? Maybe, maybe not.
I think though that if I did, I'd give serious consideration into
doing the extra work that it would require to make it run in an
environment that didn't lock me in (e.g. Amazon's EC2). Especially if
I were one of those small companies starting something new. If you
outsource for your technical talent and depend on Google's proprietary
API's in GAE, then Google will have a huge advantage over you if they
change their terms. You never want a vendor to have that sort of
advantage over you.
finally got me around to getting this off of my chest. Maybe the rest
of the world will curse him for winding me up, but I'd like to say
thanks.
What I find disturbing is the fracturing of the Java runtime and
language features. Some features and runtime classes aren't available
when its compiled down to Javascript. A disjoint set of things is
unavailable in Android, and yet another different set of things is not
available in the app engine.
The Dalvik (sp?) VM, "Its Java source code that compiles down to a
load of horse manure wrapped in legalese." e.g. I have my nice JavaFX
binaries. They even ran in the outdated 1.5 JVM on my mac. Can I pop
it on my G1 and see how it looks there? No.
Yes, I am oversimplifying it. For example, I couldn't just pop them
onto a Linux box and expect them to work until a few weeks ago,
however, most of it did work, so the option existed. A few months ago
I had to "port" a medium sized swing application to Linux. I unzipped
the jars, changed some paths in the property file, zipped them back up
again and it ran perfectly. These are examples what makes the Java
platform so great, and this is what Google wants you to forget about
and lock you in to their tools and their services.
The app engine is probably the worst, because its really nothing more
than a thinly veiled attempt at vendor lock-in. Correct me if I'm
wrong, the example that I recall is ImageIO. The libraries do not
exist in the GAE environment, but Google does have their own handy
APIs to do what you need. Run away.
Will I ever need something like Google App Engine? Maybe, maybe not.
I think though that if I did, I'd give serious consideration into
doing the extra work that it would require to make it run in an
environment that didn't lock me in (e.g. Amazon's EC2). Especially if
I were one of those small companies starting something new. If you
outsource for your technical talent and depend on Google's proprietary
API's in GAE, then Google will have a huge advantage over you if they
change their terms. You never want a vendor to have that sort of
advantage over you.
Reply all
Reply to author
Forward
0 new messages