Of course this should be called GAE Java, then what else?
You could call every java feature you wish to, except that unsupported
features will be met with runtime exception.
If I made a robotic mainframe that we decided would be base on the JVM
but certain Java features would cause inconsistencie
I agree with Ravi and Bryce...we have other fish to fry (threads to
answer) and Java is a programming language reference which doesn't
imply every library under the sun (pun intended).
On Dec 1, 4:19 am, bryce cottam wrote:
> the GAE isn't cross-compiling, javac is doing the compiling (the real
>
the GAE isn't cross-compiling, javac is doing the compiling (the real
java compiler), so it's kind of a moot argument. The point is, the
system runs java, not g-java, not pseudo-java, it's java. It just
doesn't have all the libraries you want. That's all. It's written in
the Java programming la
Suppose someone writes an app in C and wishes to cross compile to
Java. In that scenario, if some C class is unsupported by the cross-
compiler, then does the C app stop being a C app? No.
Bobby
On Dec 1, 4:10 am, Bobby wrote:
> Maybe for terminology's sake it would make sense to detach the GAE
Maybe for terminology's sake it would make sense to detach the GAE
from any language associations and just indicate that there are cross-
compilers from Java/Python to GAE. Then there would be no question on
whether it's "technically Java" - one does write in Java, it's just
that the cross-compile
if we are going to collaborate each other, we need the right names because
communication is critical.
On Mon, Nov 30, 2009 at 4:37 PM, Jess Evans wrote:
> There are innovators who "attempt" to advance the field and be the first.
> They appeal to the desperate and the early adopters with nothing
There are innovators who "attempt" to advance the field and be the first.
They appeal to the desperate and the early adopters with nothing to loose
and much to gain.
There are guardians with deep experience who strive to ensure reliability
and predictability. They appeal to those upon whom many a
I, for one, am sick and tired of Sun's domineering, suffocating
stranglehold on what is and isn't Java. GAE is a breath of fresh air.
JavaME and JavaEE also impose a variety of limitations on Java.
What's the difference between those and GAE? The difference is that
Sun got a committee of big com
The subject of this thread really caught my eye. I have to echo
Bobby: I read about the GAE before trying to implement anything on it,
and was well aware of the limitations. I'd have to suggest that you
read the docs prior to assuming anything about the environment.
The subject matter in this th
If you were able to go 2 months without noticing that there was a
whitelist then it must be more extensive than you make it seem. If you
made a decision without the knowledge that GAE exposes only a subset
of Java then i understand your frustration but it's really all your
fault because it's docume
I'd say look before your leap.
http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine?hl=en
Your asking one company to change a product name due finding yourself
mislead. Even if I agreed with your perspective I'd welcome you to
Capitalism.
On Nov 28, 10:53 am, Ravi Sh
Guys i think we have lots of more important issue to discuss here then "what
should be the name".
Shakespeare said once *What's in a name* :).
I am waiting for my other queries to be answered by Google guys.. i hope
they are enjoying Thanks giving holidays and will reply back soon..
Enjoy.
O
Actually, many people had the same reaction when GAE/J was released.
See for instance,
http://weblogs.java.net/blog/2009/04/16/google-app-engine-java-sucks
Without a doubt if some smaller player created such an incompatible
implementation they would not be allowed to call it 'Java'.
On Nov 27,
On Nov 27, 7:19 pm, Diana Cruise wrote:
>
> Ted... java.lang.Thread, you want to launch new processes from within
> your app server...that's a job for URLFetch.
>
Unlike Thread, I can't use URLFetch to perform a task asynchronously
and return a result to the calling thread.
--
You received t
Jago...in shared environments you can't let apps launch their own
threads, you can't let apps takeover file systems, etc...these are
basic principles for shared resources such as GAE and, for example,
contradicts J2EE specs such as EJB and so on. Such apps belong on
dedicated servers.
Also, loadi
Apologies, I see I didn't read the original e-mail closely.
I was thinking 'shared server environment', not 'shared app server
environment'.
But, come to think of it, I guess whitelist is so large because GAE/J
is a shared app server, not a shared server.
On Nov 27, 4:22 pm, jago wrote:
> What d
> In the end all they
> support is Java syntax and a couple of classes.
I count 1332. Since you're so particular about your terminology, you
may want to look up "a couple."
--
You received this message because you are subscribed to the Google Groups
"Google App Engine for Java" group.
To post
What do you mean with not a problem?
On Nov 27, 10:13 pm, ted stockwell wrote:
> On Nov 27, 12:17 pm, Diana Cruise wrote:
>
> > I'm curious which classes you are referring to that are missing and
> > are NOT considered a stability risk running under a shared app server
> > environment.
>
> Wel
I do not doubt that GAE is also good for big applications. That's not
the reason I started this thread.
The question is if they should call themselves Java. Even if so if
they shouldn't out of pure decency put a big red warning sign at the
top of every page telling people about the whitelist.
On
On Nov 27, 12:17 pm, Diana Cruise wrote:
> I'm curious which classes you are referring to that are missing and
> are NOT considered a stability risk running under a shared app server
> environment.
Well, since you asked, java.lang.Thread is NOT a problem in most
shared app server environments
i belive GAE is good for small application.
i made one with three forms and it was good.
For medium or big applications use your own server and db, and enjoy
freedom.
maybe in the future will grow up, and will be ok for medium and big.
On Fri, Nov 27, 2009 at 5:24 PM, jago wrote:
> We know use
We know use it for 2 month and are finally completely stuck. This
means bye-bye appengine and realizing our losses.
The Google Web Toolkit is also not called the Google Java Web Toolkit.
http://code.google.com/appengine/docs/java/overview.html does not give
a peep about a whitelist! They should di
i agree. should be called different.
call it gJava, googleJava or whatever.
bye,
NM
On Fri, Nov 27, 2009 at 3:17 PM, Diana Cruise wrote:
> I'm curious which classes you are referring to that are missing and
> are NOT considered a stability risk running under a shared app server
> environment. W
Well not Java. Android is also not Java. This is the beginning of
fragmentation if Appengine is allowed to go down this road. Seemingly
Sun struck some deal with Google. I doubt any other company would get
the same liberties.
Could you give an example of classes in the JRE lib that would be a
stab
I'm curious which classes you are referring to that are missing and
are NOT considered a stability risk running under a shared app server
environment. We are developing in Java with this solution so I don't
mind the naming...I have yet to need a class not offered, guess I have
been lucky :)
So, w
25 matches
Mail list logo
