Re: J2ME question: launch JAD files from the desktop

[Darryl L. Pierce]

I want to be able to launch JAD files from my desktop
machine by clicking on their links. Is that possible?

You can install Sun's Wireless Toolkit and associate the emulator.exe with
..JAD files. Then you can configure it as a helper application and pass the
URL for the JAD file to it as an argument.

 

[Tim Tyler]

: Tim Tyler wrote:

:> I want to be able to launch JAD files from my desktop
:> machine by clicking on their links. Is that possible?

: You can install Sun's Wireless Toolkit and associate the emulator.exe with
: .JAD files.

It's already set up so JAD files are associated with emulatorw.exe.

: Then you can configure it as a helper application and pass the
: URL for the JAD file to it as an argument.

This is the sticking point. Presumably I have to configure something
like this in any browsers I'm using.

"Helper application" seems to be terminology used by Netscape.

I would be more interested in information relating to IE.

As far as I can make out, this involves editing the registry :-(

Something along the lines of
http://www.hiscs.org/howtotip/pdfstuff/inexppc.htm
....perhaps...

Sun do this for "jnlp" files. "jad" files seem to have been left out
in the cold, though - and running them appears to be a clunky process.

 

[Tim Tyler]

: Tim Tyler wrote:

:> : Then you can configure it as a helper application and pass the
:> : URL for the JAD file to it as an argument.
:>
:> This is the sticking point. Presumably I have to configure something
:> like this in any browsers I'm using.
:>
:> "Helper application" seems to be terminology used by Netscape. [...]

:> I would be more interested in information relating to IE.
:>
:> As far as I can make out, this involves editing the registry :-(

: Nope. Go into Explorer and point it to any folder. Then click Tools->Folder
: Options and select the "File Types" tab. There you would modify the entry
: for JAD files to be the reference implementation (sorry, I said before the
: emulator from Sun's WTK; this doesn't support OTA provisioning as I had
: hoped it would) and have the RI download the JAD file and install the JAR.

I copied the format of the JNLP files (which work).

It launches the emulator - but the emulator promptly crashes - with:

Error: Could not find jar file at SpruceGO.jar
com.sun.kvem.midletsuite.InvalidJadException: Reason = 20
Could not locate MIDlet-Jar-URL: SpruceGO.jar [...]

I figure it is looking for the Jar file on the path.

You seem to be saying that using the emulator from the wireless toolkit
doesn't work. I've tried it and indeed it doesn't seem to work.

You suggest using the "reference implementation".

I presume you refer to the download at:

http://java.sun.com/products/midp/

I'll have a go at trying that.

:> Sun do this for "jnlp" files. "jad" files seem to have been left out
:> in the cold, though - and running them appears to be a clunky process.

: JAD files were designed to describe a MIDlet suite to the AMS on a handset.
: Rather than being left out in the cold, they're perfectly suited for doing
: what they were designed to do: describe a MIDlet suite and inform a handset
: about the size, vendor, version and location of the suite. Supporting JADs
: on the desktop is the responsibility of the desktop application developer.
: The WTK's emulator works in its domain (emulating the runtime environment
: of a handset) and the reference implementation within its domain(emulator a
: full-fledged handset with OTA capabilities). If there's something in
: between, I wouldn't consider it a failure on Sun's part.

I want the emulator to help develop midlets. A part of that
effort involves running other people's midlets from their web
sites - to see what is possible, and what has already been done.

The emulator apparently makes that a needlessly complex process.

 

[Tim Tyler]

: : Tim Tyler wrote:

: :> : Then you can configure it as a helper application and pass the
: :> : URL for the JAD file to it as an argument.
: :>
: :> This is the sticking point. Presumably I have to configure something
: :> like this in any browsers I'm using.
: :>
: :> "Helper application" seems to be terminology used by Netscape. [...]

: :> I would be more interested in information relating to IE.
: :>
: :> As far as I can make out, this involves editing the registry :-(

: : Nope. Go into Explorer and point it to any folder. Then click Tools->Folder
: : Options and select the "File Types" tab. There you would modify the entry
: : for JAD files to be the reference implementation (sorry, I said before the
: : emulator from Sun's WTK; this doesn't support OTA provisioning as I had
: : hoped it would) and have the RI download the JAD file and install the JAR.

: I copied the format of the JNLP files (which work).

: It launches the emulator - but the emulator promptly crashes - with:

: Error: Could not find jar file at SpruceGO.jar
: com.sun.kvem.midletsuite.InvalidJadException: Reason = 20
: Could not locate MIDlet-Jar-URL: SpruceGO.jar [...]

: I figure it is looking for the Jar file on the path.

: You seem to be saying that using the emulator from the wireless toolkit
: doesn't work. I've tried it and indeed it doesn't seem to work.

: You suggest using the "reference implementation".

: I presume you refer to the download at:

: http://java.sun.com/products/midp/

: I'll have a go at trying that.

This apparently contains a midp emulator: bin/midp.exe

Trying it from the command line suggests "midp -transient -force <JAD-URL>"
should work.

This produces the desired effect from the command line - but using:

C:\Incoming\Java\Sun\midp2source\midp2.0fcs\bin\midp.exe -transient -force %1

....as the command associated with JAD files fails.

I also explored putting quotes in a variety of places.

The emulator either launched and exited - within a fraction of a second -
or printed the help text in a dos box before rapidly exiting - depending
on exactly where I had the quotes.

Then I created a batch file, "launch.bat".

One line in it:

C:\Incoming\Java\Sun\midp2source\midp2.0fcs\bin\midp -transient -force %1

Now I can type:

"launch <JAD-URL>"

From the browser it fails - some error message about an invalid URL
flashes by in the process.

I put in some echo statements to see the URL. It is attempting
to execute the JAD file from an URL in IE's cache.

I set the size of the cache to zero - and cleared the history.

It /still/ tried the execute the JAD file from an URL in IE's cache.

This all makes me wonder if what I'm trying to do is actually possible.

 

[Darryl L. Pierce]

I want the emulator to help develop midlets. A part of that
effort involves running other people's midlets from their web
sites - to see what is possible, and what has already been done.

The emulator apparently makes that a needlessly complex process.

Only if you ignore the fact that the emulator wasn't designed to do that,
and it wasn't a part of the feature set to have it install from the web.
The emulator was designed to run the JAR/JAD file's generated by the
Wireless Toolkit, and that it does remarkably well.

 

[Darryl L. Pierce]

Tim Tyler wrote:

This all makes me wonder if what I'm trying to do is actually possible.

The MIDlet-Jar-URL should have the fully qualified URL for the JAR file in
it; i.e., http://www.foo.com/download/mysuite.jar. What's going on is that
the JAD file is being passed to the RI emulator on your system as
"file:///blah/blah/blah/mysuite.jad" and you're (I'm assuming here) using a
relative URL for the JAR file; i.e., "MIDlet-Jar-URL: mysuite.jar". Since
the emulator knows nothing of the website, it can only assume that
mysuite.jar is located at the relative URL as the JAD file
(file:///blah/blah/blah/") and tries to load it from there.

The short of it is, change the MIDlet-Jar-URL to have the fully qualified
URL for the JAR and it should work.

 

[Roedy Green]

the JAD file

I think there are two JADs. One in the Java disassembler. What is
your JAD?

 

[Darryl L. Pierce]

I think there are two JADs. One in the Java disassembler. What is
your JAD?

The Java Application Descriptor, a sort of properties file to describe a
MIDlet suite to the Java Application Manager on a handset.

 

[Tim Tyler]

: The MIDlet-Jar-URL should have the fully qualified URL for the JAR file in
: it; i.e., http://www.foo.com/download/mysuite.jar. [...]

Should it? That means you need a different version of the
JAD file when you are running locally and when you are
deploying over the internet.

Developers seem to have voted with their feet on this issue.

They are almost all using relative URLs - presumably so they don't have
to bother with maintaining or generating different versions for different
contexts - and if their content ever moves - or is downloaded to
a local drive - it continues to work.

They are probably following the principle that hard-wired in absolute
addresses are usually bad.

: The short of it is, change the MIDlet-Jar-URL to have the fully qualified
: URL for the JAR and it should work.

Unfortunately that doesn't help - doing that for every midlet I fancy
running would be more effort than my current solution - of opening a DOS
box and typing "run_midp " and then pasting in the URL of the JAD file.

 

[Darryl L. Pierce]

: The MIDlet-Jar-URL should have the fully qualified URL for the JAR file
: in it; i.e., http://www.foo.com/download/mysuite.jar. [...]

Should it?

Ought to be. There are carriers in the US (SprintPCS, for example) whose
JAM will *not* download if you use a relative URL for the JAR file.
Instead, they complain that the URL is invalid; they're looking for the
fully qualified URL. So, if you want to be available to all users, you need
to put the fully qualified URL into the JAD. No performance costs and it's
quite easy to do.

That means you need a different version of the
JAD file when you are running locally and when you are
deploying over the internet.

Why? I know of no situation where running a MIDlet suite locally requires a
different JAD file than when deploying OTA.

Developers seem to have voted with their feet on this issue.

They are almost all using relative URLs - presumably so they don't have
to bother with maintaining or generating different versions for different
contexts - and if their content ever moves - or is downloaded to
a local drive - it continues to work.

I have no idea what you're on about. I was giving you some help in making
your JAR/JAD available to the RI emulator, and you're now on about some
hypothetical developers and some unsupported claim about relative URLs.

They are probably following the principle that hard-wired in absolute
addresses are usually bad.

Who "they" and from where is the above assertion drawn? BTW, companies who
don't support their end users or who require their end users to do what
they don't want (such as move away from thier current carrier in order to
use the ISV's product) and companies *without* end users and customers.

: The short of it is, change the MIDlet-Jar-URL to have the fully
: qualified URL for the JAR and it should work.

Unfortunately that doesn't help - doing that for every midlet I fancy
running would be more effort than my current solution - of opening a DOS
box and typing "run_midp " and then pasting in the URL of the JAD file.

I didn't say do it for every MIDlet you fancy. I was trying to help you get
your current MIDlet target to work on the RI emulator. Take the suggestion
or don't, I couldn't care less either way.

 

[Tim Tyler]

: Tim Tyler wrote:

:> : The MIDlet-Jar-URL should have the fully qualified URL for the JAR file
:> : in it; i.e., http://www.foo.com/download/mysuite.jar. [...]
:>
:> Should it?

: Ought to be.

Well it isn't.

:> That means you need a different version of the
:> JAD file when you are running locally and when you are
:> deploying over the internet.

: Why? I know of no situation where running a MIDlet suite locally requires a
: different JAD file than when deploying OTA.

*If* you can have a remote MIDlet-Jar-URL, and /still/ run offline -
then I stand corrected.

However, when *I* try this I get:

``Error: Download of http://foo.bar/test.jar failed.
Error: Please check again the URL location and proxy settings
Exception Warning: java.util.zip.ZipException: error in opening zip file
in thread "main" java.lang.NullPointerException''

That may act as a bit of a deterrernt for people contemplating using
absoulte URLs.

:> Developers seem to have voted with their feet on this issue.
:>
:> They are almost all using relative URLs - presumably so they don't have
:> to bother with maintaining or generating different versions for different
:> contexts - and if their content ever moves - or is downloaded to
:> a local drive - it continues to work.

: I have no idea what you're on about. I was giving you some help in making
: your JAR/JAD available to the RI emulator, and you're now on about some
: hypothetical developers and some unsupported claim about relative URLs.

These developers are *not* "hypothetical".

http://spruce.jp/freemidlets/GO/SpruceGO.jad

....for example. Or:

http://javamobiles.com/midlets/jfdoue/asteroids.jad

In fact *all* the JAD files I look at are as I describe -
and I have yet to see one "in the wild" that fits your description.

Also I believe we are at cross purposes. When I asked to have
links to JAD files open the emulator on my desktop, perhaps
I should have stated more clearly that these JAD files
are likely to be other folk's programs on the internet.

I can run my own programs in the emulator OK - it's
launching Midlets across the internet from a web
browser I was trying to find out about.

:> They are probably following the principle that hard-wired in absolute
:> addresses are usually bad.

: Who "they" and from where is the above assertion drawn?

The programmers who use relative URLs for their "MIDlet-Jar-URL"s.

I don't know for certain why they are doing it. Maybe it is due to
the reasons I mentioned. Or maybe it's because that's what all Sun's
examples do.

:> : The short of it is, change the MIDlet-Jar-URL to have the fully
:> : qualified URL for the JAR and it should work.
:>
:> Unfortunately that doesn't help - doing that for every midlet I fancy
:> running would be more effort than my current solution - of opening a DOS
:> box and typing "run_midp " and then pasting in the URL of the JAD file.

: I didn't say do it for every MIDlet you fancy. I was trying to help you get
: your current MIDlet target to work on the RI emulator. [...]

I was never talking about my own midlet. If I wasn't clear, I'm sorry.

*Hopefully* I have now spelled out sufficiently clearly that what I was
asking after was the ability to make links to JAD files in a browser
launch the MIDP emulator on my desktop. These JAD files are likely
to have come from the internet - and have probably been written by
other people.

In other words, I'm looking for the MIDP equivalent of Java Web Start.

Browsers in phones can do it OK - but my desktop machine can't -
I have to fall back to the command line to run midlets.

 

[Darryl L. Pierce]

:> : The MIDlet-Jar-URL should have the fully qualified URL for the JAR
:> : file in it; i.e., http://www.foo.com/download/mysuite.jar. [...]
:>
:> Should it?

: Ought to be.

Well it isn't.
Whatever.

:> That means you need a different version of the
:> JAD file when you are running locally and when you are
:> deploying over the internet.

: Why? I know of no situation where running a MIDlet suite locally
: requires a different JAD file than when deploying OTA.

*If* you can have a remote MIDlet-Jar-URL, and /still/ run offline -
then I stand corrected.

However, when *I* try this I get:

``Error: Download of http://foo.bar/test.jar failed.
Error: Please check again the URL location and proxy settings
Exception Warning: java.util.zip.ZipException: error in opening zip file
in thread "main" java.lang.NullPointerException''

That may act as a bit of a deterrernt for people contemplating using
absoulte URLs.

But, the whole point of my posts has been to answer the question "how can I
have users run my MIDlet from a browser on their computer?" I answer that.
All this rest is irrelevant; if you're offline, you're not running it from
a website, right? You're providing ad hoc arguments that go against the
original question.

:> Developers seem to have voted with their feet on this issue.
:>
:> They are almost all using relative URLs - presumably so they don't have
:> to bother with maintaining or generating different versions for
:> different contexts - and if their content ever moves - or is downloaded
:> to a local drive - it continues to work.

: I have no idea what you're on about. I was giving you some help in
: making your JAR/JAD available to the RI emulator, and you're now on
: about some hypothetical developers and some unsupported claim about
: relative URLs.

These developers are *not* "hypothetical".

http://spruce.jp/freemidlets/GO/SpruceGO.jad

...for example. Or:

http://javamobiles.com/midlets/jfdoue/asteroids.jad

In fact *all* the JAD files I look at are as I describe -
and I have yet to see one "in the wild" that fits your description.

Dude, what are you looking for, answers or arguments? You point to two JAD
files with I assume relative URLs. So? Almost all of the midlets at MIDlet
Central are fully qualified URLs, TMK. So what of it?

Also I believe we are at cross purposes. When I asked to have
links to JAD files open the emulator on my desktop, perhaps
I should have stated more clearly that these JAD files
are likely to be other folk's programs on the internet.

I can run my own programs in the emulator OK - it's
launching Midlets across the internet from a web
browser I was trying to find out about.

Then why do you ask how people will run them offline?

:> They are probably following the principle that hard-wired in absolute
:> addresses are usually bad.

: Who "they" and from where is the above assertion drawn?

The programmers who use relative URLs for their "MIDlet-Jar-URL"s.

And you've performed a survey to find out that the majority feel this way,
or you're assuming conclusions to support your assertions?

I don't know for certain why they are doing it. Maybe it is due to
the reasons I mentioned. Or maybe it's because that's what all Sun's
examples do.

Or that they've not had experiences with SprintPCS users, or that users who
have been unable to download their MIDlets (you only pointed to games)
aren't willing to jump through hoops to get their MIDlets loaded onto their
phones? Customers don't exactly want to go through that much effort to get
to your product. If it's not easy, it's not worth the trouble.

:> : The short of it is, change the MIDlet-Jar-URL to have the fully
:> : qualified URL for the JAR and it should work.
:>
:> Unfortunately that doesn't help - doing that for every midlet I fancy
:> running would be more effort than my current solution - of opening a
:> DOS box and typing "run_midp " and then pasting in the URL of the JAD
:> file.

: I didn't say do it for every MIDlet you fancy. I was trying to help you
: get your current MIDlet target to work on the RI emulator. [...]

I was never talking about my own midlet. If I wasn't clear, I'm sorry.

*Hopefully* I have now spelled out sufficiently clearly that what I was
asking after was the ability to make links to JAD files in a browser
launch the MIDP emulator on my desktop. These JAD files are likely
to have come from the internet - and have probably been written by
other people.

In other words, I'm looking for the MIDP equivalent of Java Web Start.

You can install ME4SE and run MIDlets in an applet embedded in a webpage.

Browsers in phones can do it OK - but my desktop machine can't -
I have to fall back to the command line to run midlets.

MIDP was never intended to run in desktops; the whole architecture was
designed around OTA provisioning to mobiles.

 

[Tim Tyler]

: Tim Tyler wrote:
:> :> : The MIDlet-Jar-URL should have the fully qualified URL for the JAR
:> :> : file in it; i.e., http://www.foo.com/download/mysuite.jar. [...]
:> :>
:> :> Should it?
:>
:> : Ought to be.
:>
:> Well it isn't.

: Whatever.

:> :> That means you need a different version of the
:> :> JAD file when you are running locally and when you are
:> :> deploying over the internet.
:>
:> : Why? I know of no situation where running a MIDlet suite locally
:> : requires a different JAD file than when deploying OTA.
:>
:> *If* you can have a remote MIDlet-Jar-URL, and /still/ run offline -
:> then I stand corrected.
:>
:> However, when *I* try this I get:
:>
:> ``Error: Download of http://foo.bar/test.jar failed.
:> Error: Please check again the URL location and proxy settings
:> Exception Warning: java.util.zip.ZipException: error in opening zip file
:> in thread "main" java.lang.NullPointerException''
:>
:> That may act as a bit of a deterrernt for people contemplating using
:> absoulte URLs.

: But, the whole point of my posts has been to answer the question "how can I
: have users run my MIDlet from a browser on their computer?" I answer that.
: All this rest is irrelevant; if you're offline, you're not running it from
: a website, right? [...]

*if*.

: You're providing ad hoc arguments that go against the
: original question.

The original question never suggested I was offline.

:> :> Developers seem to have voted with their feet on this issue.
:> :>
:> :> They are almost all using relative URLs - presumably so they don't have
:> :> to bother with maintaining or generating different versions for
:> :> different contexts - and if their content ever moves - or is downloaded
:> :> to a local drive - it continues to work.
:>
:> : I have no idea what you're on about. I was giving you some help in
:> : making your JAR/JAD available to the RI emulator, and you're now on
:> : about some hypothetical developers and some unsupported claim about
:> : relative URLs.
:>
:> These developers are *not* "hypothetical".
:>
:> http://spruce.jp/freemidlets/GO/SpruceGO.jad
:>
:> ...for example. Or:
:>
:> http://javamobiles.com/midlets/jfdoue/asteroids.jad
:>
:> In fact *all* the JAD files I look at are as I describe -
:> and I have yet to see one "in the wild" that fits your description.

: Dude, what are you looking for, answers or arguments? You point to two JAD
: files with I assume relative URLs. So?

So the "hypothetical developers" are no longer "hypothetical" -
and my "unsupported claim about relative URLs" is supported.

: Almost all of the midlets at MIDlet Central are fully qualified URLs,
: TMK. So what of it?

Maybe - but:

``The Midletcentral Site is still undergoing extended maintenance. We
apologise for any inconvenience caused. Please check back in the next
few weeks.''

If /some/ developers do this it is of low relevance - since most of
the ones I have tried don't. A solution that only works with a tiny
fraction of midlets is unlikely to be very satisfying.

:> Also I believe we are at cross purposes. When I asked to have
:> links to JAD files open the emulator on my desktop, perhaps
:> I should have stated more clearly that these JAD files
:> are likely to be other folk's programs on the internet.
:>
:> I can run my own programs in the emulator OK - it's
:> launching Midlets across the internet from a web
:> browser I was trying to find out about.

: Then why do you ask how people will run them offline?

Where did I mention being offline?

I may have talked about people running JAD files locally.

That was because you raised the issue of using absoulte URLs.

These apparently won't work when the JAD/JAR files are used from desktops
offline - thus, perhaps partially explaining why very few people seem to
use them.

In other words, any mention of being offline was to offer an
explanation of why developers might avoid using absolute URLs.

:> :> They are probably following the principle that hard-wired in absolute
:> :> addresses are usually bad.
:>
:> : Who "they" and from where is the above assertion drawn?
:>
:> The programmers who use relative URLs for their "MIDlet-Jar-URL"s.

: And you've performed a survey to find out that the majority feel this way,

No. I did not claim to know how they felt.

: or you're assuming conclusions to support your assertions?

To quote from the message you are replying to:

``I don't know for certain why they are doing it. Maybe it is due to
the reasons I mentioned. Or maybe it's because that's what all Sun's
examples do.''

:> In other words, I'm looking for the MIDP equivalent of Java Web Start.

: You can install ME4SE and run MIDlets in an applet embedded in a webpage.

Yes - though that's not running midlets from JAD files on web pages by
clicking on their links.

:> Browsers in phones can do it OK - but my desktop machine can't -
:> I have to fall back to the command line to run midlets.

: MIDP was never intended to run in desktops; the whole architecture was
: designed around OTA provisioning to mobiles.

Indeed there are technical reasons stopping it from working in
today's browsers.

That probably explains why Sun didn't implement it - it isn't currently
possible.

No doubt future browsers will allow midlets to be executed from links
on web pages.

 

[Darryl L. Pierce]

:> That may act as a bit of a deterrernt for people contemplating using
:> absoulte URLs.

: But, the whole point of my posts has been to answer the question "how
: can I have users run my MIDlet from a browser on their computer?" I
: answer that. All this rest is irrelevant; if you're offline, you're not
: running it from a website, right? [...]

*if*.

Mate, at this point I'm pretty much done with the discussion. You asked a
question and I answered it. Your ad hoc conditions pretty much make the
original question irrelevant (you can't run an online function when you're
offline) and at this point you seem to be more inclined towards pointless
bickering.

As I said in a previous message, I have answered your original question.
Take the advice or leave it, I don't really care.

: You're providing ad hoc arguments that go against the
: original question.

The original question never suggested I was offline.

Which is what I just said. Your original question required the user be
online. Now you're bringing up a condition where the user's not online,
breaking the original question's requirement. As I said, you're now seeming
to posture needlessly.

:> In fact *all* the JAD files I look at are as I describe -
:> and I have yet to see one "in the wild" that fits your description.

: Dude, what are you looking for, answers or arguments? You point to two
: JAD files with I assume relative URLs. So?

So the "hypothetical developers" are no longer "hypothetical" -
and my "unsupported claim about relative URLs" is supported.

No, and no. You point to two JAD files with relative URLs and seem to think
this supports an assertion that the majority have rejected fully qualified
URLs in JAD files. Again, I ask, are you looking for answers or arguments?

Are you familiar with the logical fallacies of the appeal to common
practice, appeals to popularity, hasty generalizations, bandwagon, or
biased samples (jeez, I could point to a bunch of fallacies here)? You
might want to read up on those before presenting an argument such as this
in future. That a selected group of MIDlet suites use one form of
MIDlet-Jar-URL does not make it 1) best, 2) appropriate, nor 3) does it
mean that "[t]he developers seem to have voted with their feet".

: Almost all of the midlets at MIDlet Central are fully qualified URLs,
: TMK. So what of it?

Maybe - but:

``The Midletcentral Site is still undergoing extended maintenance. We
apologise for any inconvenience caused. Please check back in the next
few weeks.''

What does this have to do with anything beyond an attempt at argument on
your part and a red herring to the point?

If /some/ developers do this it is of low relevance - since most of
the ones I have tried don't.

Biased sample and hasty generalization on your part. Have you really
checked every site with MIDlets? Or are you jumping to conclusions based on
a few that you personally have checked?

A solution that only works with a tiny
fraction of midlets is unlikely to be very satisfying.

What are you on about here? I said that some carriers won't load MIDlets
that don't have a fully qualified URL in the JAD. I don't know what you're
arguing for/against at this point, and frankly don't give a fiddler's fart
either way.

:> Also I believe we are at cross purposes. When I asked to have
:> links to JAD files open the emulator on my desktop, perhaps
:> I should have stated more clearly that these JAD files
:> are likely to be other folk's programs on the internet.
:>
:> I can run my own programs in the emulator OK - it's
:> launching Midlets across the internet from a web
:> browser I was trying to find out about.

: Then why do you ask how people will run them offline?

Where did I mention being offline?

"If you can have a remote MIDlet-Jar-URL, and still run offline -
then I stand corrected."

I may have talked about people running JAD files locally.

You talked about running the MIDlets while offline.

That was because you raised the issue of using absoulte URLs.

To download the JAR from the web by clicking a web page link and using the
RI emulator as the helper application.

These apparently won't work when the JAD/JAR files are used from desktops
offline

Again, with the offline part...

- thus, perhaps partially explaining why very few people seem to
use them.

In other words, any mention of being offline was to offer an
explanation of why developers might avoid using absolute URLs.

And the whole of using absolute URLs was for accessing the JAR/JAD while
*online* and from a browser. My whole answer was constrained by those
original requirements/assumptions and all of your arguments against seem to
have no bearing on that.

:> :> They are probably following the principle that hard-wired in
:> :> absolute addresses are usually bad.
:>
:> : Who "they" and from where is the above assertion drawn?
:>
:> The programmers who use relative URLs for their "MIDlet-Jar-URL"s.

: And you've performed a survey to find out that the majority feel this
: way,

No. I did not claim to know how they felt.

You asserted that the majority feel as you do. A hasty generalization at
best, a biased sample basically.

: or you're assuming conclusions to support your assertions?

To quote from the message you are replying to:

``I don't know for certain why they are doing it. Maybe it is due to
the reasons I mentioned. Or maybe it's because that's what all Sun's
examples do.''

Saying you don't know the whys is irrelevant.

:> In other words, I'm looking for the MIDP equivalent of Java Web Start.

: You can install ME4SE and run MIDlets in an applet embedded in a
: webpage.

Yes - though that's not running midlets from JAD files on web pages by
clicking on their links.

And you received an answer for one way that can be done. Do with that
information what you wish.

:> Browsers in phones can do it OK - but my desktop machine can't -
:> I have to fall back to the command line to run midlets.

: MIDP was never intended to run in desktops; the whole architecture was
: designed around OTA provisioning to mobiles.

Indeed there are technical reasons stopping it from working in
today's browsers.

Such as?

That probably explains why Sun didn't implement it - it isn't currently
possible.

No doubt future browsers will allow midlets to be executed from links
on web pages.

Whatever.