What is wrong with Applets?
jesbox
active code to run in the web browser.
The Java Applet technology seems largely forgotten. Are there
technical reasons for not using Java Applets?
If someone made something like AJAX but using Applets for the client-
side execution, how would that compare to the omnipresent JavaScript
solutions??
Are there issues with browser compatibility, security or inferior
functionality? Are Applets actually better but neglected??
Thanks for your insights on this topic.
Joshua Cranmer
> There is major momentum for JavaScript and in some ways Flash to make
> active code to run in the web browser.
>
> The Java Applet technology seems largely forgotten. Are there
> technical reasons for not using Java Applets?
Java has suffered from a noticeably long load time, so people do notice
when applets are loading.
AJAX also has somewhat looser security controls (you can load any HTTP
page you want with XHR (if you do a few things, none of which involves
signing your code), Java limits you to connections to your source server).
Predominantly, I think the major reason for the drop in use of Java
applets is that they stand out more in terms of UI. AJAX displays
basically using the same techniques as the webpage, so the UI is a lot
more seamless; Java applets will typically be using default Swing or AWT
settings, so they really stick out if they have anything hinting at UI.
> If someone made something like AJAX but using Applets for the client-
> side execution, how would that compare to the omnipresent JavaScript
> solutions??
I'm not quite sure what you're asking here. Applets have pretty much
been more featureful than AJAX since AJAX was first contrived. Perhaps
people may find it just too hard to prototype stuff quickly in Java
compared to JS, but I've found that not to be the case whenever I've tried.
> Are there issues with browser compatibility, security or inferior
> functionality? Are Applets actually better but neglected??
Ultimately, I think applets are much more powerful than "Web 2.0" tools.
However, they do have very noticeable issues in terms of startup
performance and UI seamlessness.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
Arne Vajhøj
I think it is a combination of many things:
- a version mess with very old MS Java version and a rather
wide range of SUN Java versions out there
- Java is not as good for the flashy stuff as Flash and SL, we
need to use JavaFX to compete in that area and not that many
have started using JavaFX
- most Java people work with Java EE and those people prefer
all the logic server side
- Java applets are not in fashion today
Arne
Roedy Green
wrote, quoted or indirectly quoted someone who said :
I would like to see JavaScript disappear. My objections are:
1. It is inefficient to use pass around source code.
2. the language itself is Mickey Mouse.
3. It never works the same way on two different browsers.
It has succeeded because it can do things that Java itself cannot.
There is no inherent reason that should be so. Perhaps it is just the
Sun likes things to be multiplatform and the JavaScript people do not.
Apple is partly the villain there. They have been deliberately
screwing up Java and promoting JavaScript for their iPhone iPad toys.
--
Roedy Green Canadian Mind Products
http://mindprod.com
Pfizer’s world wide patents on Viagra will expire over the period 2010 to 2013. This will launch an avalanche of cheap generics. Wrigley has even patented a chewing gum containing generic Viagra.
Arved Sandstrom
> On 09-04-2010 18:16, jesbox wrote:
>> There is major momentum for JavaScript and in some ways Flash to make
>> active code to run in the web browser.
>>
>> The Java Applet technology seems largely forgotten. Are there
>> technical reasons for not using Java Applets?
>>
>> If someone made something like AJAX but using Applets for the client-
>> side execution, how would that compare to the omnipresent JavaScript
>> solutions??
>>
>> Are there issues with browser compatibility, security or inferior
>> functionality? Are Applets actually better but neglected??
>
> I think it is a combination of many things:
> - a version mess with very old MS Java version and a rather
> wide range of SUN Java versions out there
> - Java is not as good for the flashy stuff as Flash and SL, we
> need to use JavaFX to compete in that area and not that many
> have started using JavaFX
I personally may never start - the samples on javafx.com hang both
Safari and Firefox on Mac OS X 10.6, and go into error dialog loops in
Firefox on Ubuntu 9.10. None of these browsers have any problems running
applets, and the JRE versions are completely updated. If that's the
state of the art I'll stick with all the other approaches that actually
work, thank you very much.
> - most Java people work with Java EE and those people prefer
> all the logic server side
I don't know if that's it - I'm OK with logic on the client, whether
that's a PDA or a smartphone or a browser on a desktop. I just happen to
believe that so long as our most serious problems lie with producing
reliable, easy-to-maintain, correct code, why are we dicking around with
visual effects?
I also happen to believe that users of our UIs want clear, intuitive
interfaces, not dressed-up circus shows. If you think you need Flash or
JavaFX or any of that other stuff to sell your interface then you're
already on the wrong road. IMHO.
> - Java applets are not in fashion today
>
> Arne
AHS
Arved Sandstrom
> On Fri, 9 Apr 2010 15:16:44 -0700 (PDT), jesbox <jes...@gmail.com>
> wrote, quoted or indirectly quoted someone who said :
>
>> There is major momentum for JavaScript and in some ways Flash to make
>> active code to run in the web browser.
>>
>> The Java Applet technology seems largely forgotten. Are there
>> technical reasons for not using Java Applets?
>>
>> If someone made something like AJAX but using Applets for the client-
>> side execution, how would that compare to the omnipresent JavaScript
>> solutions??
>>
>> Are there issues with browser compatibility, security or inferior
>> functionality? Are Applets actually better but neglected??
>
> I would like to see JavaScript disappear. My objections are:
> 1. It is inefficient to use pass around source code.
What's more inefficient is to keep on calling the server to render new
pages or page sections to do something that the browser can do by
processing JavaScript.
> 2. the language itself is Mickey Mouse.
How so? For its intended purpose it works reasonably well.
> 3. It never works the same way on two different browsers.
On modern or fairly modern browsers you sort of have to try to make it
work different on different browsers. I can think of a couple of largish
J2EE web apps I work with right now that have JavaScript libraries like
Prototype and script.aculo.us included in pages, plus all the script
introduced by using JSF, plus plenty of Javascript page logic included
by the application. We're talking dozens through hundreds to some cases
thousands of lines of Javascript per page. All pages work without any
changes in IE6 through IE8, work with a handful of minor tweaks in
Firefox and Safari, and not so many more minor tweaks for Chrome and Opera.
Mind you, the stuff we use JavaScript for falls within what I consider
to be its reasonable boundaries, so maybe that's why we don't run into
problems.
> It has succeeded because it can do things that Java itself cannot.
Pretty good reason, don't you think?
> There is no inherent reason that should be so. Perhaps it is just the
> Sun likes things to be multiplatform and the JavaScript people do not.
>
> Apple is partly the villain there. They have been deliberately
> screwing up Java and promoting JavaScript for their iPhone iPad toys.
Screwing up Java? This is what I'm running on Mac OS X 10.6.2 right now
(I haven't done my 10.6.3 upgrade yet):
java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-10M3025)
Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01-101, mixed mode)
I run NetBeans 6.8, Eclipse 3.5, and any number of Java EE 5/6 servers
on that laptop, and I can't say I have noticed that Java is screwed up.
AHS
Arne Vajhøj
[lots of stuff that I agree with]
> Roedy Green wrote:
>> Apple is partly the villain there. They have been deliberately
>> screwing up Java and promoting JavaScript for their iPhone iPad toys.
>
> Screwing up Java? This is what I'm running on Mac OS X 10.6.2 right now
> (I haven't done my 10.6.3 upgrade yet):
>
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-10M3025)
> Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01-101, mixed mode)
>
> I run NetBeans 6.8, Eclipse 3.5, and any number of Java EE 5/6 servers
> on that laptop, and I can't say I have noticed that Java is screwed up.
Roedy did write iPhone and iPad.
Somehow I think you are running those IDE's and app servers on
a Mac computer and not on iPhone/iPad.
Arne
Arne Vajhøj
> I would like to see JavaScript disappear. My objections are:
> 1. It is inefficient to use pass around source code.
JavaScript can be compressed quite well. It does not need to
be a problem.
> 2. the language itself is Mickey Mouse.
It was designed for another purpose than Java.
I can not see a problem with the language for web client
side code.
> 3. It never works the same way on two different browsers.
Lot of it does.
Code can be written portable or non-portable.
It is very difficult to create a language that prevents
people from writing non-portable code.
> Perhaps it is just the
> Sun likes things to be multiplatform and the JavaScript people do not.
Nonsense.
JavaScript is standardized under ECMA & ISO.
Implementations does implement the standard.
> Apple is partly the villain there. They have been deliberately
> screwing up Java and promoting JavaScript for their iPhone iPad toys.
Apple is pushing Objective-C instead of Java.
Most likely noone at Apple considered Java and JavaScript
to be alternatives.
Arne
Qu0ll
news:bc72a472-8ff3-42f4...@r27g2000yqn.googlegroups.com...
In a word - nothing.
In fact, applets are my preferred deployment environment. When launched
using JNLP an applet can do anything a Web Start application can do with the
added benefit that it is embedded within the browser. Applet load time,
which is frequently cited as its Achilles Heel, has been significantly
reduced with the advent of Java 6 Update 10 (the so-called "consumer"
release which was done in preparation for JavaFX). And when using the
combination of ProGuard to reduce the applet JAR size and pack200 to
compress the resulting JARs, surprisingly small footprints can be achieved
which also aid faster startup times.
The reason applets have not been utilised more is because of initial slow
load times and some very poor early examples of what could be achieved with
an applet. If you take your time to invest as much diligence into your
applet code that you would your application code you can produce remarkably
good applets which can provide a remarkably good web experience.
Coding for applets is somewhat more difficult than coding for applications
but is well worth the effort IMHO.
--
And loving it,
-Qu0ll (Rare, not extinct)
_________________________________________________
Qu0llS...@gmail.com
[Replace the "SixFour" with numbers to email me]
Arved Sandstrom
screwing up Java for anything else, which was my point, I'm somewhat
dubious that they are expending effort on screwing it up for anything.
If Apple is in fact pushing JavaScript for iPad/iPhone (and they could
well be, I don't develop for either device) all that means is that they
are pushing JavaScript. Not deliberately crippling Java, nor even not
supporting it. And if this is true then perhaps it means that Apple
thinks JavaScript is well-suited even if Roedy does not.
AHS
Daniel Pitts
> Joshua Cranmer<Pidg...@verizon.invalid> writes:
>> Java applets will typically be using default Swing or AWT
>> settings, so they really stick out if they have anything hinting at UI.
>
>
> »Through either the JavaScript DOM APIs or the
> Java Common DOM APIs, the Java applet can modify
> the web page dynamically«
>
> https://jdk6.dev.java.net/plugin2/liveconnect/
>
True, but I have personally experienced issues (freezing, strange
behavior, etc...) with multi-threaded applets that rely on that
functionality (even when doing appropriate synchronizing and using the
DOM dispatcher thread).
Not to mention the JSObject interface is very buggy. There are
work-arounds, but none as good as I'd like.
I wrote about such a work-around here:
<http://virtualinfinity.net/wordpress/tools/2008/10/11/javascript-and-java-applets/>
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
Richard Maher
"Daniel Pitts" <newsgroup....@virtualinfinity.net> wrote in message
news:oW2wn.177217$2r7.1...@newsfe05.iad...
> On 4/9/2010 6:46 PM, Stefan Ram wrote:
> > Joshua Cranmer<Pidg...@verizon.invalid> writes:
> >> Java applets will typically be using default Swing or AWT
> >> settings, so they really stick out if they have anything hinting at UI.
> >
> > By default, but they also could be hidden and modify the DOM:
> >
> > »Through either the JavaScript DOM APIs or the
> > Java Common DOM APIs, the Java applet can modify
> > the web page dynamically«
> >
> > https://jdk6.dev.java.net/plugin2/liveconnect/
> >
> True, but I have personally experienced issues (freezing, strange
> behavior, etc...) with multi-threaded applets that rely on that
> functionality (even when doing appropriate synchronizing and using the
> DOM dispatcher thread).
Can you please explain further on how you are "using the DOM dispatcher
thread"? Are you still talking about the Liveconnect JSObject interface or
the Common DOM APIs?
How are you telling your JSObject.call() to execute on the "DOM dispatcher
thread" and, with reference to the following link, what choice do we have?
http://java.sun.com/javase/6/docs/technotes/guides/jweb/applet/applet_execution.html
Cheers Richard Maher
Arne Vajhøj
> Arne Vajh�j wrote:
>> On 09-04-2010 20:25, Arved Sandstrom wrote:
>> [lots of stuff that I agree with]
>>> Roedy Green wrote:
>>>> Apple is partly the villain there. They have been deliberately
>>>> screwing up Java and promoting JavaScript for their iPhone iPad toys.
>>>
>>> Screwing up Java? This is what I'm running on Mac OS X 10.6.2 right now
>>> (I haven't done my 10.6.3 upgrade yet):
>>>
>>> java version "1.6.0_17"
>>> Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-10M3025)
>>> Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01-101, mixed mode)
>>>
>>> I run NetBeans 6.8, Eclipse 3.5, and any number of Java EE 5/6 servers
>>> on that laptop, and I can't say I have noticed that Java is screwed up.
>>
>> Roedy did write iPhone and iPad.
>>
>> Somehow I think you are running those IDE's and app servers on
>> a Mac computer and not on iPhone/iPad.
> screwing up Java for anything else, which was my point, I'm somewhat
> dubious that they are expending effort on screwing it up for anything.
>
> If Apple is in fact pushing JavaScript for iPad/iPhone (and they could
> well be, I don't develop for either device) all that means is that they
> are pushing JavaScript. Not deliberately crippling Java, nor even not
> supporting it. And if this is true then perhaps it means that Apple
> thinks JavaScript is well-suited even if Roedy does not.
Apple are pushing very hard a no-VM policy on iPhone and iPad. So
no Java, no Flash, no CLR etc..
Arne
RedGrittyBrick
> On 10-04-2010 10:25, Arved Sandstrom wrote:
From Apples developer licence agreement for iPhone:
3.3.1 — Applications may only use Documented APIs in the manner
prescribed by Apple and must not use or call any private APIs.
Applications must be originally written in Objective-C, C, C++, or
JavaScript as executed by the iPhone OS WebKit engine, and only code
written in C, C++, and Objective-C may compile and directly link against
the Documented APIs (e.g., Applications that link to Documented APIs
through an intermediary translation or compatibility layer or tool are
prohibited).
That is very clear. I can see the benefits to Apple and, arguably, to
iPhone users. It is one reason why I'll probably be buying an Android
phone not an iPhone.
--
RGB
jesbox
> From Apples developer licence agreement for iPhone: [ ... ]
> Applications must be originally written in Objective-C, C, C++, or
> JavaScript as executed by the iPhone OS WebKit engine, and only code
> written in C, C++, and Objective-C may compile and directly link against
I get a clear impression that Java Applet (and JavaFX) is at least on
par with JavaScript etc. Of course there are differences, but I am
glad to hear that Applets are not obsolete or inferior as I was
fearing. So in many cases it would make sense to build both server-
side and client-side using Java. Probably it deserves to happen more
often. At least enterprise solutions would tolerate client start-up
times, if that remains an issue.
A notable exception is the iPhone/iPad platform where the JVM and Java
language is obviously forbidden.
Thanks for your answers!
(I can't resist to ask. Surely it would be possible to write a JVM in
JavaScript for iPhone? )
Joshua Cranmer
> (I can't resist to ask. Surely it would be possible to write a JVM in
> JavaScript for iPhone? )
Somehow I doubt the iPhone app reviewers would approve it. But given
that their approval process appears to mostly rely on a dart board....
Andrew Thompson
> ...So in many cases it would make sense to build both server-
> side and client-side using Java. ..
The 'client-side Java' of that equation does not
need to be an embedded applet. It could be a plain
old desktop application, or a frame/applet launched
using JWS.
--
Andrew T.
pscode.org
Martin Gregorie
>
> (I can't resist to ask. Surely it would be possible to write a JVM in
> JavaScript for iPhone? )
>
Its forbidden. The latest Jobsian Edict bans indirect execution, i.e.
using any type of intermediate code interpreter. I suspect this is
largely due to Steve throwing his teddy at Flash, but nonetheless its
part of the recently updated list of published hurdles that third party
apps must jump to get into the AppStore.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
Daniel Pitts
> On Sun, 11 Apr 2010 15:47:47 -0700, jesbox wrote:
>
>>
>> (I can't resist to ask. Surely it would be possible to write a JVM in
>> JavaScript for iPhone? )
>>
> Its forbidden. The latest Jobsian Edict bans indirect execution, i.e.
> using any type of intermediate code interpreter. I suspect this is
> largely due to Steve throwing his teddy at Flash, but nonetheless its
> part of the recently updated list of published hurdles that third party
> apps must jump to get into the AppStore.
compatible JavaScript.
Although, the performance would likely be so abysmal that they wouldn't
need to do anything about it.
Hmm, actually. It would be interesting to see a HotSpot implementation
that converts from JVM ByteCode into JavaScript :-) Then, hopefully the
JavaScript implementation could HotSpot the result even further! Rube
Goldberg, we need you!
Daniel Pitts
> Hi Daniel,
>
> "Daniel Pitts"<newsgroup....@virtualinfinity.net> wrote in message
> news:oW2wn.177217$2r7.1...@newsfe05.iad...
>> On 4/9/2010 6:46 PM, Stefan Ram wrote:
>>> Joshua Cranmer<Pidg...@verizon.invalid> writes:
>>>> Java applets will typically be using default Swing or AWT
>>>> settings, so they really stick out if they have anything hinting at UI.
>>>
>>> By default, but they also could be hidden and modify the DOM:
>>>
>>> �Through either the JavaScript DOM APIs or the
>>> Java Common DOM APIs, the Java applet can modify
>>> the web page dynamically�
>>>
>>> https://jdk6.dev.java.net/plugin2/liveconnect/
>>>
>> True, but I have personally experienced issues (freezing, strange
>> behavior, etc...) with multi-threaded applets that rely on that
>> functionality (even when doing appropriate synchronizing and using the
>> DOM dispatcher thread).
>
> Can you please explain further on how you are "using the DOM dispatcher
> thread"? Are you still talking about the Liveconnect JSObject interface or
> the Common DOM APIs?
<http://java.sun.com/javase/6/docs/technotes/guides/plugin/developer_guide/java_js.html>
>
> How are you telling your JSObject.call() to execute on the "DOM dispatcher
> thread" and, with reference to the following link, what choice do we have?
> http://java.sun.com/javase/6/docs/technotes/guides/jweb/applet/applet_execution.html
I'm not telling the method to execute anywhere. I'm executing it myself
through the DOMAction/DOMService API mentioned above.
Martin Gregorie
> Martin Gregorie <mar...@address-in-sig.invalid> writes:
>>Its forbidden. The latest Jobsian Edict bans indirect execution, i.e.
>>using any type of intermediate code interpreter.
>
> Formally, any program that takes any input is an interpreter of a
> certain language. For example, when a program just has two buttons
> [next] and [quit], the user input language is
>
Yes, I agree about interpreters in general, e.g. Perl or awk, which
interpret source code directly. However, if you're being picky you can
say that they too are 'intermediate code interpreters' since in the
interests of speed they actually compile the source to some intermediate
form which is then interpreted before being discarded at the end of the
run.
However, Apple have an explicit prohibition on 'intermediate code
interpreters', by which they appear mean anything that interprets a file
containing compiled output that's not native machine code for the iPhone
or iPad hardware. A Java application that's been compiled to the iPhone's
native machine code via, say, the GNU Java compiler would be OK but a
self-contained .jar file containing the same application compiled to
bytecode is not. At least, that's how I understand it.
Peter Duniho
> [...] A Java application that's been compiled to the iPhone's
> native machine code via, say, the GNU Java compiler would be OK
No, it wouldn't. The new rules don't just prohibited interpreted
languages. They prohibit any programs not originally written in
Objective-C, C, C++, or for the specific Javascript supported on the iPhone.
A Java program is not one that is originally written in one of the
"blessed" languages, and so is forbidden, even if you use some tool to
compile it to native iPhone code.
Pete
Martin Gregorie
> Martin Gregorie wrote:
>> [...] A Java application that's been compiled to the iPhone's native
>> machine code via, say, the GNU Java compiler would be OK
>
> No, it wouldn't. The new rules don't just prohibited interpreted
> languages. They prohibit any programs not originally written in
> Objective-C, C, C++, or for the specific Javascript supported on the
> iPhone.
>
I missed seeing that.
How does the phone know anyway? Does the Objective C compiler leave magic
watermarks in the executable?
John B. Matthews
Martin Gregorie <mar...@address-in-sig.invalid> wrote:
I don't think it's the phone that checks; it's the vendor.
Article & discussion:
<http://www.itworld.com/legal/104320/adobe-vs-apple-going-get-uglier?source=smlynch>
<http://apple.slashdot.org/story/10/04/13/145247/Will-Adobe-Sue-Apple-Over-Flash?art_pos=1>
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
Peter Duniho
The phone has no way to "know" per se. But Apple will reject an
application if after examining it, they believe it was created in a way
contrary to their rules. I would expect that any pre-compilation tools
would emit code following certain general patterns that would be
recognizable to a human inspecting the code (or even to
specifically-written inspection tools, once someone's figured out what
the characteristics of such a program would be).
Of course, their approval process is already pretty arbitrary, so
frankly I'm not sure the new rules really change that much. It's not
like a person really had a reliable way to know for sure that their app
would be approved anyway.
Pete
Lothar Kimmeringer
> I would like to see JavaScript disappear. My objections are:
> 1. It is inefficient to use pass around source code.
> 2. the language itself is Mickey Mouse.
> 3. It never works the same way on two different browsers.
You're knowledge of Javascript is obvioulsy from the time where
applets were common, i.e. of about 1998. Speaking of that time,
your points are 100% true. Nowerdays, Javascript is standardized,
is processed using JIT and happliy works (within the public standard)
on every browser.
> Apple is partly the villain there. They have been deliberately
> screwing up Java and promoting JavaScript for their iPhone iPad toys.
This is a knowledge of pre-SDK times. Currently I receive mails
from Apple every week or so announcing a new version of XCode
for the development of iPhone and iPad applications. the language
of choice there is Objective-C. And if you want to sell applications
via the App-Store you can't do this for browser-based ones.
Regards, Lothar
--
Lothar Kimmeringer E-Mail: spam...@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)
Always remember: The answer is forty-two, there can only be wrong
questions!
Lothar Kimmeringer
> The Java Applet technology seems largely forgotten. Are there
> technical reasons for not using Java Applets?
Yes, AJAX is "built in" where Java Applets need a JVM. With GWT (a
Java to Javascript compiler) I can create web based applications
that run on every browser including Apple iPhone and all Android
based systems. I can't do that with Java and even Flash is not
available e.g. on iPhones/iPads
> If someone made something like AJAX but using Applets for the client-
> side execution, how would that compare to the omnipresent JavaScript
> solutions??
The first thing you need is a JSON-parser to be able to use the
nowerdays common data-transfer format (no XML anymore). Then you
are limited to the rectangle the applet is taking and to be able
to access the other parts of the page, you need the - Javascript
based - Bridge to the DOM-tree.
> Are there issues with browser compatibility, security or inferior
> functionality?
With the standardization of Javascript as ECMA and ISO standard,
compatibility has improved. Security is not really an issue for
something that completely runs on client side and both techniques
(Java and Javascript) have had bugs in the implementation that
allowed code to break the sandbox.
> Are Applets actually better but neglected??
There is no simple "is better" here. Applets have many advantages:
- Can access the local file system if signed, AJAX can't
- Runs in an own thread, i.e. you can perform operations in the
background. Javascript runs in one thread only, which is the
reason, why all calls to the server have to be asynchron.
- You can use the full functionality of the JVM (within the
restrictions of the sandbox), allowing you to run anything
you like on the client side using all the libraries that are
already available. That's the reason e.g. the tax and revenue
offices in Germany are using an Applet on their site people
have to use for their vat- and other declarations.
But also disadvantages (that are in my eyes also valid for Flash):
- You're a "blob" in a page. Resizing the page often has no effect
on the applet and in ancient times (and I haven't tried it later)
a printout of the page produced only a grey box where the contents
of the applets should have been.
- You have no real access to the DOM-tree the applet resides in. So
the classic use-case where you use AJAX is quite hard to be imple-
mented with a Java Applet
Martin Gregorie
> Martin Gregorie wrote:
>> How does the phone know anyway? Does the Objective C compiler leave
>> magic watermarks in the executable?
>
> The phone has no way to "know" per se. But Apple will reject an
> application if after examining it, they believe it was created in a way
> contrary to their rules. I would expect that any pre-compilation tools
> would emit code following certain general patterns that would be
> recognizable to a human inspecting the code (or even to
> specifically-written inspection tools, once someone's figured out what
> the characteristics of such a program would be).
>
That's what I was wondering. I suppose 'strings' might show compiler-
specific differences: if a person can tell that an unapproved compiler
was used then I suppose that the loader could make the same checks, but
why?
Are Apple trying to make more money by selling locking in 3rd party
developers to using only the Apple toolset?
> Of course, their approval process is already pretty arbitrary, so
> frankly I'm not sure the new rules really change that much. It's not
> like a person really had a reliable way to know for sure that their app
> would be approved anyway.
>
Judging by The Register's ongoing comments about the AppStore approval
process its at least as arbitrary and subject to whim as Google's AdWords
bidding process.
Peter Duniho
> That's what I was wondering. I suppose 'strings' might show compiler-
> specific differences: if a person can tell that an unapproved compiler
> was used then I suppose that the loader could make the same checks, but
> why?
>
> Are Apple trying to make more money by selling locking in 3rd party
> developers to using only the Apple toolset?
Apple's true motivations are known only to them. Of course, there's no
shortage of speculation.
The official party line is that their policies "ensure a positive
customer experience". But Apple has a long history, since Steve Jobs
came back, of building their business models around lock-in. And that
depends on them keeping an iron grip on how developers use their
platforms, especially on the consumer-electronics side.
It's my opinion that Apple's belief is that by restricting developers in
this way, they will prevent people from developing cross-platform
programs, and that Apple — having the market–share advantage at the
moment — will remain the platform of choice. That is, developers
without the resources to write the same program multiple times will have
to choose a platform, and they will choose Apple.
It's also my opinion that this strategy will blow up in their face. In
reality, other manufacturers are catching up and will be eating away at
their market share. I gather Android has already made significant
inroads on that front. And being evil to their developers is only going
to make developers more likely to focus on non-iPhone platforms, not less.
I certainly hope this does blow up in Apple's face. But only time will
tell. There seems to be a fairly deep reservoir of people willing to
complain to no end about Apple while they continue to hand over their
hard-earned cash to them. As long as consumers and developers continue
to be willing to bend over for Apple, Apple will continue to be more
than happy to stick it to them.
Pete
RedGrittyBrick
>
> Apple's true motivations are known only to them. Of course, there's no
> shortage of speculation.
>
> The official party line is that their policies "ensure a positive
> customer experience". But Apple has a long history, since Steve Jobs
> came back, of building their business models around lock-in. And that
> depends on them keeping an iron grip on how developers use their
> platforms, especially on the consumer-electronics side.
>
> It's my opinion that Apple's belief is that by restricting developers in
> this way, they will prevent people from developing cross-platform
> programs, and that Apple — having the market–share advantage at the
> moment — will remain the platform of choice. That is, developers without
> the resources to write the same program multiple times will have to
> choose a platform, and they will choose Apple.
>
> It's also my opinion that this strategy will blow up in their face. In
> reality, other manufacturers are catching up and will be eating away at
> their market share. I gather Android has already made significant
> inroads on that front. And being evil to their developers is only going
> to make developers more likely to focus on non-iPhone platforms, not less.
>
I'm reminded of Joel Spolsky's essay† saying that successful companies
commoditise the complements of their products. I guess Phone-app
developers should like Android for this reason. By this logic, Apple
ought to be welcoming Java, Flash and other app development tools.
Perhaps the iTunes app-store by itself is doing a pretty good job of
making apps for iPhones a commodity.
†http://www.joelonsoftware.com/articles/StrategyLetterV.html
--
RGB
Bent C Dalager
>
> Are Apple trying to make more money by selling locking in 3rd party
> developers to using only the Apple toolset?
As far as I can tell pretty much all of Apple's more questionable
moves over the past years can be adequately explained by their near
pathological desire to control the user experience on their platforms.
I think this is all the reason they need, because they consider that
the one thing that keeps people in love with Apple hardware is the
Apple user experience and if they lose this then they lose their very
lucrative market.
This basically means that anything that they have the authority to
approve or reject (e.g. iPhone apps) will necessarily be subject to
arbitrary (-seeming) subjective review by someone or other, someone
who hopefully at least has a decent idea what the Apple user
experience /is/. To most of the rest of us, that is almost a complete
unknown because it appears to be based on criteria such as "what Jobs
feels is right" which isn't the sort of technical specification a
programmer likes to relate to.
The latest result of this line of thinking appears to be "platform
abstraction layers harm the user experience", which is a sentiment one
can understand when you're talking about resource constrainted
platforms such as iPhones, iPads and the like. They are a bit of a
blast from the past in that you may actually see a noticable extra
delay for going through such abstraction layers and Jobs doesn't want
to give his users that frustration. He wants a crisp, clean, fast,
beautiful platform to show his customers even when that platform is
based on a chip that runs like molasses (comparatively speaking).
It probably doesn't help that to the extent such abstraction layers
try to emulate the Apple look and feel, they will inevitably get
something or other just slightly wrong. And "just slightly wrong"
screams out and insults every single iPhone user out there so Jobs
doesn't want that. He wants everyone to use the Apple provided UI
libraries so that everything is /exactly/ pixel perfect like it was
meant to be, and like his customers expect it to be.
So you get a ban on anything that doesn't compile straight to the
metal. This may seem ludicrous to a programmer, but over in touchy
feely Apple land it probably makes all sorts of sense.
Cheers,
Bent D
--
Bent Dalager - b...@pvv.org - http://www.pvv.org/~bcd
powered by emacs
Peter Duniho
> I'm reminded of Joel Spolsky's essay† saying that successful companies
> commoditise the complements of their products. I guess Phone-app
> developers should like Android for this reason. By this logic, Apple
> ought to be welcoming Java, Flash and other app development tools.
> Perhaps the iTunes app-store by itself is doing a pretty good job of
> making apps for iPhones a commodity.
While Spolsky's assertion makes some sense to me, I'm not sure it's
completely proven. Also, I'm not sure of the ultimate conclusion even
if we take the assertion as given.
If the goal is to commoditize apps on the iPhone, that means it has to
be difficult or impossible for one developer to do something
significantly better than or different from any other developer. This
could well mean prohibiting the use of a variety of tools, so that each
developer is starting from the same place. In such an environment, you
never get any truly special apps, but you do get a large number of
similar apps.
On the other hand, given that part of Apple's approval process seems to
be to take into account whether there's a substantially similar app
already available, and to disapprove and app if there is. So, whether
commoditization is a good thing or not, and whether open or closed tools
are the best path to that, it doesn't seem like that's actually the goal
Apple is trying to achieve.
Pete
Peter Duniho
> [...]
> So you get a ban on anything that doesn't compile straight to the
> metal. This may seem ludicrous to a programmer, but over in touchy
> feely Apple land it probably makes all sorts of sense.
Unfortunately, that rationalization doesn't fit with the observed data.
One of Apple's approved programming environments is the WebKit
Javascript, in which you can code up pretty much any UI that you could
in any other browser, look-and-feel be damned.
It also doesn't explain why cross-compilation tool, that simply emits
Cocoa-based code to be natively compiled for the iPhone platform is also
prohibited. That code will be no less efficient than code written by
hand using the same techniques.
You've clearly drunk the "preserve user experience" Kool-Aid that
Apple's been serving, but their claims don't really make much sense
given what can be observed both about their actual rules and behavior,
as well as given what apps are there.
Pete
Bent C Dalager
> Bent C Dalager wrote:
>> [...]
>> So you get a ban on anything that doesn't compile straight to the
>> metal. This may seem ludicrous to a programmer, but over in touchy
>> feely Apple land it probably makes all sorts of sense.
>
> Unfortunately, that rationalization doesn't fit with the observed data.
> One of Apple's approved programming environments is the WebKit
> Javascript, in which you can code up pretty much any UI that you could
> in any other browser, look-and-feel be damned.
I doubt such an app would pass the examination process though.
> It also doesn't explain why cross-compilation tool, that simply emits
> Cocoa-based code to be natively compiled for the iPhone platform is also
> prohibited. That code will be no less efficient than code written by
> hand using the same techniques.
The idea would be that the extra layer will tend to add inefficiencies
that are not desired for the True Apple Experience (tm).
> You've clearly drunk the "preserve user experience" Kool-Aid that
> Apple's been serving, but their claims don't really make much sense
> given what can be observed both about their actual rules and behavior,
> as well as given what apps are there.
What I've been seeing matches their behaviour reasonably well, if you
assume some basic naïveté on the part of the policy makers. Which I
wouldn't find entirely unreasonable.
RedGrittyBrick
> RedGrittyBrick wrote:
>> I'm reminded of Joel Spolsky's essay† saying that successful companies
>> commoditise the complements of their products.
>
> completely proven. Also, I'm not sure of the ultimate conclusion even if
> we take the assertion as given.
>
> If the goal is to commoditize apps on the iPhone, that means it has to
> be difficult or impossible for one developer to do something
> significantly better than or different from any other developer.
Well, I think you highlight the flaw in the analogy with true
commodities (wheat, gold, oil, pork?). Perhaps I oversimplified what
Spolsky was driving at.
Clearly it is in Apples interest to have a large number of inexpensive
applications for their iPhone hardware.
> On the other hand, given that part of Apple's approval process seems to
> be to take into account whether there's a substantially similar app
> already available, and to disapprove and app if there is.
To digress a little, Apple's approvals process is alleged to be somewhat
opaque and seemingly arbitrary. I was recently looking for an iPhone app
that would encrypt small notes organised by title, e.g. for passwords
and longer, but still small, chunks of text. I found a few apps in the
App store that did this and were rather similar to one another. None of
them had certain features I wanted (e.g. synchronising or just copying
the encrypted data to a PC over USB) If I wanted to write such an app
presumably it would be in danger of being rejected unless I heavily
emphasised the differentiating features? What if it were accepted but
the next version of one of the other apps then also included the new
features?
I suspect it isn't in Apple's interests to have lots of identical apps
in their app-store but neither is it in their interest to stifle
competition. By trying to adjudicate on similarity, Apple are certainly
setting themselves up for a lot of work - and to look foolish occasionally.
> So, whether
> commoditization is a good thing or not, and whether open or closed tools
> are the best path to that, it doesn't seem like that's actually the goal
> Apple is trying to achieve.
As you said before, we can only speculate about Apple's thinking.
However it is probably not in Apple's interest for 100,000 iPhone apps
to immediately appear in the Android marketplace and the Ovi store - as
they might if all were written in J2ME say.
So yes, the commoditisation idea may not stand up completely to detailed
scrutiny - but I found it afforded an interesting perspective of the
Java iPhone issue.
--
RGB
John B. Matthews
Bent C Dalager <b...@pvv.ntnu.no> wrote:
> Content-Type: text/plain; charset=iso-8859-1
> ...
> naïveté
Should Content-Type say this, instead?
Content-Type: text/plain; charset=UTF-8
<http://groups.google.com/group/comp.lang.java.programmer/msg/17e10d2be6d709c7>
<http://groups.google.com/group/comp.lang.java.programmer/msg/17e10d2be6d709c7?hl=en&dmode=source>
<http://www.fileformat.info/info/unicode/char/00e4/index.htm>
<http://www.fileformat.info/info/unicode/char/00e9/index.htm>
Lew
> What I've been seeing matches their behaviour reasonably well, if you
> wouldn't find entirely unreasonable.
You know what you get when you assume.
Finding something reasonable doesn't make it so. For example, I deem it
highly unlikely that the marketing and technical folks at Apple are naive, but
that doesn't mean they aren't. Of course, I'm not assuming they aren't, I'm
concluding that they aren't.
--
Lew
Bent C Dalager
>
> Should Content-Type say this, instead?
>
> Content-Type: text/plain; charset=UTF-8
That would certainly have been ideal. A cursory examination indicates
I may have an obsolete version of slrn but I will investigate it more
thoroughly when I get the chance.
Thank you for pointing this out.
John B. Matthews
Bent C Dalager <b...@pvv.ntnu.no> wrote:
> On 2010-04-14, John B. Matthews <nos...@nospam.invalid> wrote:
> >
> > Should Content-Type say this, instead?
> >
> > Content-Type: text/plain; charset=UTF-8
>
> That would certainly have been ideal. A cursory examination indicates
> I may have an obsolete version of slrn but I will investigate it more
> thoroughly when I get the chance.
It may just need to be set in "charset outgoing"
<http://slrn.sourceforge.net/downloads/slrn.rc>
> Thank you for pointing this out.
You're welcome.
Peter Duniho
> [...]
>> Javascript, in which you can code up pretty much any UI that you could
>> in any other browser, look-and-feel be damned.
>
> I doubt such an app would pass the examination process though.
They don't have a choice. JavaScript apps can be run straight from the web.
>> It also doesn't explain why cross-compilation tool, that simply emits
>> Cocoa-based code to be natively compiled for the iPhone platform is also
>> prohibited. That code will be no less efficient than code written by
>> hand using the same techniques.
>
> The idea would be that the extra layer will tend to add inefficiencies
> that are not desired for the True Apple Experience (tm).
There's nothing about those tools that require an extra layer. Just as
there is, for example, a cross-compiler to convert VB.NET code to C#,
which can then be compiled as a C# program, one could write a
cross-compiler to convert Flash, or Java, or whatever to Objective-C/Cocoa.
Furthermore, it is quite common for developers to write their own
layers. Both for the abstraction value it provides, as well as for
providing a surface for cross-platform compatibility. Such a layer
would be especially common in an OOP environment like C++ or
Objective-C, and yet there is no prohibition from Apple on that kind of
application.
The "no layers allowed" reasoning doesn't hold water.
Pete
Bent C Dalager
> In article <slrnhsck6...@decibel.pvv.ntnu.no>,
> Bent C Dalager <b...@pvv.ntnu.no> wrote:
>
>> On 2010-04-14, John B. Matthews <nos...@nospam.invalid> wrote:
>> >
>> > Should Content-Type say this, instead?
>> >
>> > Content-Type: text/plain; charset=UTF-8
>>
>> That would certainly have been ideal. A cursory examination indicates
>> I may have an obsolete version of slrn but I will investigate it more
>> thoroughly when I get the chance.
>
> It may just need to be set in "charset outgoing"
Yes, I tried some variations of that but it won't accept it:
charset: invalid command
slrn fatal error:
.slrnrc: Error encountered processing line 44
charset outgoing "utf-8"
My working theory is that it may be related to this:
$ slrn --version
Slrn 0.9.8.1pl1 [2005-02-17]
* Note: This version is a developer preview.
S-Lang Library Version: 2.1.3
* Note: This program was compiled against version 2.0.6.
Compiled at: Mar 28 2007 14:54:46
Operating System: Debian
Bent C Dalager
> Bent C Dalager wrote:
>> [...]
>>> One of Apple's approved programming environments is the WebKit
>>> Javascript, in which you can code up pretty much any UI that you could
>>> in any other browser, look-and-feel be damned.
>>
>> I doubt such an app would pass the examination process though.
>
> They don't have a choice. JavaScript apps can be run straight from the web.
Ah, and this will work on an iPhone? I had the impression you'd need
some sort of approval to run your javascripts there but if they allow
random scripts from across the web then this is different of course.
I am not sure how they reconcile this, if at all.
>> The idea would be that the extra layer will tend to add inefficiencies
>> that are not desired for the True Apple Experience (tm).
>
> There's nothing about those tools that require an extra layer.
Well, no, it is not reality - it is just their idea. Which is why I
used the troublesome French word that got me into my UTF-8 problem
elsewhere :-)
> Just as
> there is, for example, a cross-compiler to convert VB.NET code to C#,
> which can then be compiled as a C# program, one could write a
> cross-compiler to convert Flash, or Java, or whatever to Objective-C/Cocoa.
I expect in this case they view the cross-compiler as the extra layer,
even if the code /it/ produces goes straight to the metal on the
iPhone.
> Furthermore, it is quite common for developers to write their own
> layers. Both for the abstraction value it provides, as well as for
> providing a surface for cross-platform compatibility. Such a layer
> would be especially common in an OOP environment like C++ or
> Objective-C, and yet there is no prohibition from Apple on that kind of
> application.
The line they are trying to draw is very artificial and one of the
problems is that the distinction between "one of my libraries" and "my
abstration layer" is very fuzzy at best. However, if you create an
actual abstraction layer for the purpose of cross-platform
compatibility then you are very likely in violation of 3.3.1 of the
iPhone developer license:
"Applications may only use Documented APIs in the manner prescribed by
Apple and must not use or call any private APIs. Applications must be
originally written in Objective-C, C, C++, or JavaScript as executed
by the iPhone OS WebKit engine, and only code written in C, C++, and
Objective-C may compile and directly link against the Documented APIs
(e.g., Applications that link to Documented APIs through an
intermediary translation or compatibility layer or tool are
prohibited)."
If you create your very own API to act as intermediary between your
code and Apple's libraries then, so far as I can see, you are in
violation.
Peter Duniho
> [...] However, if you create an
> actual abstraction layer for the purpose of cross-platform
> compatibility then you are very likely in violation of 3.3.1 of the
> iPhone developer license:
No, you would not be in violation at all.
> "Applications may only use Documented APIs in the manner prescribed by
> Apple and must not use or call any private APIs. Applications must be
> originally written in Objective-C, C, C++, or JavaScript as executed
> by the iPhone OS WebKit engine, and only code written in C, C++, and
> Objective-C may compile and directly link against the Documented APIs
> (e.g., Applications that link to Documented APIs through an
> intermediary translation or compatibility layer or tool are
> prohibited)."
>
> If you create your very own API to act as intermediary between your
> code and Apple's libraries then, so far as I can see, you are in
> violation.
You are misinterpreting the clause. The "private API" that they are
referring to is any API _within_ the iPhone OS and which is not public.
It would be ridiculous to prohibit people from calling their own
"private API" in their own code's libraries. With such a prohibition,
you would have to write your entire program as a single huge function.
Pete
Dancing Fingers
RedGrittyBrick
> So can Safari on the iPad run JAVA Applets?
No.
--
RGB
http://www.insideria.com/2010/01/is-the-ipad-really-the-future.html
Blueparty
> There is major momentum for JavaScript and in some ways Flash to make
> active code to run in the web browser.
>
> The Java Applet technology seems largely forgotten. Are there
> technical reasons for not using Java Applets?
>
> side execution, how would that compare to the omnipresent JavaScript
> solutions??
>
>
> Thanks for your insights on this topic.
There is nothing wrong with applets, really. All the initial problems
are taken care off.
I think it is more a "political" problem. When you develop a web, applet
developer or developers are, in certain way, separated from the rest of
the team. They are using different techniques, they can't share the
same templates (if there are any). Applet is an standalone application,
a subproject within the project.
B
Dancing Fingers
wrote:
That really sucks. My plan was to have an App teaser with an Applet
then sell the App somewhere else. JAVA runs great on the iMac, why
change?