What is wrong with Applets?

[Martin Gregorie]

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.

 

[Martin Gregorie]

[...] 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]

[...] 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?

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>

 

[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: (e-mail address removed)
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


Regards, Lothar
--
Lothar Kimmeringer E-Mail: (e-mail address removed)
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!

 

[Martin Gregorie]

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.

 

[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

 

[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 C Dalager]

[...]
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.

Cheers,
Bent D

 

[RedGrittyBrick]

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.

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.

 

[John B. Matthews]

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
assume some basic naïveté [naïveté] on the part of the policy makers. Which I
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.

 

[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.

Cheers,
Bent D

 

[John B. Matthews]

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"

Thank you for pointing this out.

You're welcome.

 

[Bent C Dalager]

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

Cheers,
Bent D

 

[Bent C Dalager]

[...]

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.

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.

Cheers,
Bent D

 

[Dancing Fingers]

So can Safari on the iPad run JAVA Applets?

 

[RedGrittyBrick]

So can Safari on the iPad run JAVA Applets?

No.

 

[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?

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.

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]

No.

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?