tools for programming applets

[Joshua Cranmer]

Functions as first-class objects.

Nope, that's original in JavaScript. It's as new to JavaScript as
classes are to Java.

And yet nobody was ever able to do them. Where is the Java equivalent of
jQuery, for example?

How about Swing? Java's graphics APIs are not so shoddy you need a
massive library just to do anything sane with them ;-)

 

[Lawrence D'Oliveiro]

Nope, that's original in JavaScript.

So are you beginning to understand that it’s not JavaScript playing catch-up
to Java?

How about Swing?

How about it?

 

[Lew]

So are you beginning to understand that it’s not JavaScript playing catch-up
to Java?

That's a typical trollish maneuver, Lawrence, shifting to an opposite stance
when someone refutes your original point. I guess your original point you
admit to be wrong, given how quickly you dropped it when challenged, Lawrence.

How about it?

Oh, Lawrence, Lawrence, Lawrence,

How about you drop your intellectually dishonest bullshit?

Lawrence?

I notice you're too frightened to answer me, Lawrence.

 

[Joshua Cranmer]

So are you beginning to understand that it’s not JavaScript playing catch-up
to Java?

/me sighs.

1. It's not JavaScript playing catchup. The language itself has had no
significant change (I'm pretty sure generators are not part of ES5, only
ES:harmony...).

2. The features of the DOM are adding no functionality that Java itself
does not have.

3. "Catch-up" does not imply removing features to achieve a convergence
of languages.

How about it?

That you completely cut off all context of where I explained this.
Sheesh, you're getting as bad as Mr.... I can't remember the original
text he wrote, but I'm sure this will convince him to drop by ;-)

 

[horos22]

Look guys,

I see that I caused a bit of a firestorm - which was not my intent -
and I see that people are attributing motives to me that are
completely baseless. (no - I'm not up to anything 'nefarious', no I'm
not trying to hack the pentagon.)

The site in question is not a large-scale, fully-funded site. It
doesn't - and I don't - have the financial means to fully duplicate
the environment just for the sake of doing testing and development.
Frankly, it's a not-for-profit and the work is also not-for-profit.

Furthermore, *no* I'm not talking about changing a production system
'in place' - in fact I'm making my best possible effort *not* to
change the production system.

By keeping things local - in just changes to the client (the applet),
and not writing back any data to the production system - I'm
guaranteeing that I'm keeping the production system intact.

In fact I'm doing better than that. If I can run tests against *real*
production data, I can make a better guarantee that the applet would
work better than just by regression tests alone.

Sheesh. I swear that developers (myself included) have been in this
industry SO LONG that they take for granted the bulky, resource
intensive, extra-life-support-systems-required effort that programming
has become.

Here's a clue - not everything developed has a requirement of
thousands of transactions per second, page views in the millions, and
teams of hundreds. And not every effort is capitalized in the millions
(or even thousands) of dollars.

So think small in answering this question, will you? It looks like -
from your responses - that I'll have to cobble something up on my
client to do the work. Or have the site administrator put a special
directive for my IP in the server to handle my testing, such that the
data comes from the server, but the applet comes from localhost.

And stop with the nefarious purposes line of thought.. ok? It isn't
conducive to reasoned conversation, and frankly it makes otherwise
intelligent people sound like conspiracy nuts.

Ed

 

[horos22]

I think it is.  There are a couple of tools that let you replace CSS on
an HTML page.  The page design folks use them to mock up new pages or
fix errors before propagating back to the server.

He's just assuming that applets are like HTML.  It's a rookie maneuver,
nothing more.

Mark,

I think you get my drift, but I'd raise you one further. Albeit
insecure, there *should* be a way to replace applets like you would
replace CSS. It would make things a helluva lot simpler in
development. This shouldn't be turned on by default, but it should be
there.

BTW there are tons of things that sense for development purposes, that
make no sense for production deployment. Why this is any different is
beyond me.

Ed

 

[horos22]

Microsoft??


Microsoft?? No, YOU’RE the one kidding me.

95% of the people running your code are running microsoft browsers and
microsoft java implementations. Do you *not* test your applet against
all of these, especially for gui presentation?

Rsync is useless if you aren't running your development client on the
same os as the server, or if you are using licensed code anywhere.

Ed

 

[Lew]

Look guys,

I see that I caused a bit of a firestorm - which was not my intent -
and I see that people are attributing motives to me that are
completely baseless. (no - I'm not up to anything 'nefarious', no I'm
not trying to hack the pentagon [sic].)

The site in question is not a large-scale, fully-funded site. It
doesn't - and I don't - have the financial means to fully duplicate
the environment just for the sake of doing testing and development.
Frankly, it's a not-for-profit and the work is also not-for-profit.

Furthermore, *no* I'm not talking about changing a production system
'in place' - in fact I'm making my best possible effort *not* to
change the production system.

By keeping things local - in just changes to the client (the applet),

Applets are server-side, not clients.

and not writing back any data to the production system - I'm
guaranteeing that I'm keeping the production system intact.

You mean, other than by trying to circumvent its security.

In fact I'm doing better than that. If I can run tests against *real*
production data, I can make a better guarantee that the applet would
work better than just by regression tests alone.

No one has yet suggested regression tests alone. Where did that come from?

Sheesh. I swear that developers (myself included) have been in this
industry SO LONG that they take for granted the bulky, resource
intensive, extra-life-support-systems-required effort that programming
has become.

Irrelevant comment. We were talking about applets and their security
mechanism. There's no "bulky, resource intensive,
extra-life-support-systems-required effort that programming has become".
There's only your irrational resistance to the facts.

Here's a clue - not everything developed has a requirement of
thousands of transactions per second, page views in the millions, and
teams of hundreds. And not every effort is capitalized in the millions
(or even thousands) of dollars.

What does that have to do with anything?\

To quote you, "Sheesh". Get a grip.

So think small in answering this question, will you? It looks like -
from your responses - that I'll have to cobble something up on my
client to do the work. Or have the site administrator put a special
directive for my IP in the server to handle my testing, such that the
data comes from the server, but the applet comes from localhost.

"Think small"? Are you on drugs? This isn't about scale, this is about
applet security, which BY DESIGN prevents the heinous activity for which
you're asking. This is true small or large.

And having a testbed separate from the production server is not "large",
doesn't mean "millions" or "gaziilions" or any other of that hyperbolic
bullshit you're pooping out.

Sober up, take a deep breath, and approach your problem rationally, son.

And stop with the nefarious purposes line of thought.. ok? It isn't
conducive to reasoned conversation, and frankly it makes otherwise
intelligent people sound like conspiracy nuts.

You kept fighting the truth and asking for a nefarious, security-circumventing
technique even after your question was asked. Maybe if you'd been more
forthcoming initially, and less insulting right now, we'd have less basis to
suspect your motives. The conclusion was entirely rational based on the
evidence you provided. Your attempt to duck responsibility for that doesn't
make anyone else look less intelligent, horos22 (not your real name).

So stop with the blaming us for your behavior, hm-K?

 

[Lew]

Mark,

I think you get my drift, but I'd raise you one further. Albeit
insecure, there *should* be a way to replace applets like you would
replace CSS. It would make things a helluva lot simpler in
development. This shouldn't be turned on by default, but it should be
there.

BTW there are tons of things that sense for development purposes, that
make no sense for production deployment. Why this is any different is
beyond me.

No, there shouldn't. How would an applet call back to the correct host if you
have it mounted from localhost? Applets are only allowed to get resources
from their own server.

Your fundamental error in thought is that applets are not at all like CSS.
CSS is a brower-interpreted, client-side phenomenon. Applets are a JVM-run,
server-side phenomenon that just happen to run out of a browser. Big difference.

Now stop whining about your pathetic thoughts of how things "should" be and
deal with reality as it actually is, or find a profession that doesn't require
rational reasoning. Or write your own technology to compete with applets.
Just stop whining over and over and over and over and over and over about how
you think in your infinite wisdom and genius that things should be different
than they actually are. You'll never get the job done that way.

It's pathetic.

 

[markspace]

I think you get my drift, but I'd raise you one further. Albeit
insecure, there *should* be a way to replace applets like you would
replace CSS.

Well, no, I disagree. I'm sorry your on a corner case of development
where you're trying to do this on a shoe-string, but I don't think it's
practical for Oracle or anyone else to solve all the problems of all the
shoe string developers out there. It's just too complicated. It might
work in one persons web site but break in all the other shoe string
sites out there. It's just not a solvable problem.

And I'd still like to hear what development environments you use that
allow you to slide things into production servers and production systems
with out making an modifications of your own code. I might appreciate
being able to use one of those tools some day.

 

[Lawrence D'Oliveiro]

In message <3c7d8f50-df8e-4198-

95% of the people running your code are running microsoft browsers and
microsoft java implementations. Do you *not* test your applet against
all of these, especially for gui presentation?

I don’t bother with applets, so your question is moot.

Rsync is useless if you aren't running your development client on the
same os as the server ...

But why deliberately use a platform that makes development more difficult?
Wouldn’t you rather save yourself some work?

And what happened to the much-trumpeted Java claim of “write once, run
everywhere�

... or if you are using licensed code anywhere.

All the code I use is “licensedâ€. Only most of it happens to be Free
Software, which means the licence allows free copying.

 

[Lawrence D'Oliveiro]

That you completely cut off all context of where I explained this.

*Sigh* I get this crap all the time from the clueless newbies. Let me
explain to you something about USENET: my postings are to record what I
said, not what you said. If I quote any part of you said, it is to give some
context for what I said, nothing more.

Rest assured if I reply to you I did read what you said, whether I quoted it
or not. If I was ignoring what you said, I wouldn’t even bother replying to
you.

 

[Arved Sandstrom]

*Sigh* I get this crap all the time from the clueless newbies. Let me
explain to you something about USENET: my postings are to record what I
said, not what you said. If I quote any part of you said, it is to give some
context for what I said, nothing more.

[ SNIP ]

That's the point of quoting, yes, to provide context for what you're
saying. Joshua is saying that you didn't quote enough to provide
context. You surely did not.

In case you didn't know this about English (this is not a Usenet thing),
the point of quoting as we use it here is typically to call attention to
another person's position so you can agree or disagree with it, and
follow up on what they said. Brevity is good, but you're supposed to
keep enough quoted material to actually express the intent.

Here's another way of looking at it: assume that readers only have the
one post to examine. The sense of what you quote should independently
accurately reflect what the original author is saying. "How about
Swing?" fails miserably on that count.

AHS

 

[Silvio]

All,

I was looking to do some quick java development of applets. Here's my
situation:

1. I have a static server (ie: that I cannot touch) which serves my
client data (and applets).
2. a bare-bones client programming setup (vim and java compiler)

What I was hoping to do, therefore, is hijack the applets that are
coming from the server, and replace them with my own, compiled ones,
and hook the browser in such a way that when the applet is asked for,
my applet fires instead (hopefully in debugging mode) using the data from the server as input.

Surely this is a common enough situation that there are standard
firefox plugins to do this..

Or is it? In any case any, help on this would be most appreciated.

Thanks much,

Ed

Sounds like a strange request but whatever.

Why don't you run a local proxy (apache comes to mind but even
Tomcat/Jetty would do) for the site with some special rules to serve the
applet from where you have it and to replace the sites DNS with its
actual IP. Then map the DNS to localhost in /etc/hosts or
/Windows/System32/drivers/etc/hosts. Has worked fine with almost any
site for me in the past.

Silvio

 

[Lew]

*Sigh* I get this crap all the time from the clueless newbies. Let me

Wow. You really have lost it this time, Lawrence. Please show more courtesy.

explain to you something about USENET: my postings are to record what I
said, not what you said. If I quote any part of you said, it is to give some
context for what I said, nothing more.

Rest assured if I reply to you I did read what you said, whether I quoted it
or not. If I was ignoring what you said, I wouldn’t even bother replying to
you.

Arrogant much, Lawrence?

 

[Alessio Stalla]

No, there shouldn't.  How would an applet call back to the correct hostif you
have it mounted from localhost?  Applets are only allowed to get resources
from their own server.

Your fundamental error in thought is that applets are not at all like CSS..
CSS is a brower-interpreted, client-side phenomenon.  Applets are a JVM-run,
server-side phenomenon that just happen to run out of a browser.  Big difference.

Now stop whining about your pathetic thoughts of how things "should" be and
deal with reality as it actually is, or find a profession that doesn't require
rational reasoning.  Or write your own technology to compete with applets.
Just stop whining over and over and over and over and over and over abouthow
you think in your infinite wisdom and genius that things should be different
than they actually are.  You'll never get the job done that way.

It's pathetic.

Guys, sorry, but you're completely nuts. Once more I understand why
Java has got the reputation of being bloated. We should remember that
Java is not necessarily targeted only at big corporations and multi-
million projects! The OP asked how to do a certain thing. Telling him
how a Fortune 500 company should do it is not going to help him.
Besides, I don't think even a Fortune 500 company should clone the
whole production server just to test one *applet*!

To answer directly to the OP question: there are a few ways you can
test your own modified applet against your production server.
1) you can run the applet as a standalone application: either coding
(e.g. a JFrame to contain it) or using something like Oracle's
AppletViewer. This is feasible only if the applet does not interact
with the surrounding page.
2) signed applets can bypass security restrictions. So you can run
your (signed) applet on a page loaded from localhost and still connect
to the remote server. Or, if you *really* need the applet to run on
the production page itself, you can probably use something like
Greasemonkey to patch (your client-local version of) the page to
include the applet. Needless to say, the latter option could be a
violation of the site's terms of use, and it's unnecessarily
cumbersome, so avoid it unless it's the only option left.

To everyone else: applets *are* client-side. Really, I can't imagine
why you think otherwise. Yes, they are downloaded from a server; so
what? Most software nowadays is downloaded from somewhere the first
time. But they run on the client, and only talk to the server via
remoting, RPC, SOAP or whatever else. Or do you really believe that
e.g. Flash is server-side?

Sorry for being a little aggressive, but I can't really understand why
there are ~50 posts sponsoring the big costly solution and ~0
suggesting the practical one.

Cheers,
Alessio

 

[Lew]

Guys, sorry, but you're completely nuts. Once more I understand why
Java has got the reputation of being bloated. We should remember that
Java is not necessarily targeted only at big corporations and multi-
million projects! The OP asked how to do a certain thing. Telling him
how a Fortune 500 company should do it is not going to help him.
Besides, I don't think even a Fortune 500 company should clone the
whole production server just to test one *applet*!

Huh? "Fortune 500 company"? Where's your head, dude? It takes twenty
minutes and about 50c worth of disk space to clone the server. I do it all
the time at home in my practice work. That's one individual person, not even
a company, let alone a Fortune 500 company. Get real.

To answer directly to the OP question: there are a few ways you can
test your own modified applet against your production server.
1) you can run the applet as a standalone application: either coding
(e.g. a JFrame to contain it) or using something like Oracle's
AppletViewer. This is feasible only if the applet does not interact
with the surrounding page.

Suggested upthread, but only partially useful as not all applet behaviors can
be tested this way.

2) signed applets can bypass security restrictions. So you can run

On the localhost, yes. It doesn't change the restrictions on which server they
can communicate with.

The tutorial explains this:

"An applet can communicate with server applications that run on the same host
as the applet."
<http://download.oracle.com/javase/tutorial/deployment/applet/server.html>

"Signed applets operate outside the security sandbox and have extensive
capabilities to access the client."

your (signed) applet on a page loaded from localhost and still connect
to the remote server. Or, if you *really* need the applet to run on
the production page itself, you can probably use something like
Greasemonkey to patch (your client-local version of) the page to
include the applet. Needless to say, the latter option could be a
violation of the site's terms of use, and it's unnecessarily
cumbersome, so avoid it unless it's the only option left.

The applet still has to communicate with the server from which is was loaded,
and no other.

To everyone else: applets *are* client-side. Really, I can't imagine
why you think otherwise. Yes, they are downloaded from a server; so

They are a special component that talks to a special application server, not a
client of the web server, as explained upthread.

what? Most software nowadays is downloaded from somewhere the first
time. But they run on the client, and only talk to the server via
remoting, RPC, SOAP or whatever else. Or do you really believe that
e.g. Flash is server-side?

Sorry for being a little aggressive, but I can't really understand why
there are ~50 posts sponsoring the big costly solution and ~0
suggesting the practical one.

Because the solution is neither big, nor costly, and is, in fact, much LESS
expensive than testing on the production box. Risk has a cost, duh. Talk
about how inexpensive development and testing on the production server are
when you've brought it to its knees and the client is out of business for a
day while you try to undo the damage done by your insane irresponsibility.

Why do you guys latch on to this "big, expensive" rhetoric as if there were
any merit to it whatsoever? It's been pointed out before that that is false
reasoning. What is this, repeat the Big Lie (without evidence or supporting
logic) long enough and this intelligent group of software engineers are
somehow suddenly going to believe it?

 

[Stanimir Stamenkov]

Mon, 23 May 2011 14:17:43 +1200, /Lawrence D'Oliveiro/:

And yet nobody was ever able to do them. Where is the Java equivalent of
jQuery, for example?

Which languages have a jQuery equivalent?

jQuery is rather fat library for the things it does. It does a lot
of things wrong, does not teach developers of learning the standard
DOM, in turn teaches developers not doing things right, and finally
adds quite a bit amount of crap going over the network which
developers and users end up not really using.

If you go to comp.lang.javascript you'll get quite negative opinion
on the usefulness of the jQuery library from the experts.

 

[Alessio Stalla]

Huh?  "Fortune 500 company"?  Where's your head, dude?  It takes twenty
minutes and about 50c worth of disk space to clone the server.  I do itall
the time at home in my practice work.  That's one individual person, not even
a company, let alone a Fortune 500 company.  Get real.

Well, of course I was exaggerating, but still, how long it takes
depends on the server, doesn't it? What if in the OP's case the server
is backed by a 1TB database? Even copying just the bits he needs for
the test requires identifying those bits, and writing SQL scripts to
selectively copy them. In general, it requires detailed knowledge
about the server, and - I repeat - that's overkill just to test one
applet.

Suggested upthread, but only partially useful as not all applet behaviorscan
be tested this way.

True. The OP will decide if the behaviors he can test this way are
those that interest him or not.

On the localhost, yes. It doesn't change the restrictions on which serverthey
can communicate with.

The tutorial explains this:

"An applet can communicate with server applications that run on the same host
as the applet."
<http://download.oracle.com/javase/tutorial/deployment/applet/server.html>

"Signed applets operate outside the security sandbox and have extensive
capabilities to access the client."
<http://download.oracle.com/javase/tutorial/deployment/applet/security...>

Not true. You can explicitly grant AllPermissions to your applet,
thereby effectively disabling security altogether. Granted, it's a
stupid thing to do most of the time, but not in the OP's case. See,
e.g., <http://stackoverflow.com/questions/608387/can-signed-applets-
connect-with-a-different-host-from-which-they-originate>.

The applet still has to communicate with the server from which is was loaded,
and no other.


They are a special component that talks to a special application server, not a
client of the web server, as explained upthread.

A special component *that runs on the client* and that *can* talk to a
special application server, but also to a HTTP server, or to no server
at all. How is this different from Flash? Or even JavaScript, except
the latter does not require a plugin?

Because the solution is neither big, nor costly, and is, in fact, much LESS
expensive than testing on the production box.

How can you possibly know!? The OP said nothing about the production
box! It might as well be a cluster of ten high-end machines, as far as
we know!

 Risk has a cost, duh.  Talk
about how inexpensive development and testing on the production server are
when you've brought it to its knees and the client is out of business fora
day while you try to undo the damage done by your insane irresponsibility..

You're grossly exaggerating. I don't get why you insist on doing it.

Why do you guys latch on to this "big, expensive" rhetoric as if there were
any merit to it whatsoever?  It's been pointed out before that that is false
reasoning.  What is this, repeat the Big Lie (without evidence or supporting
logic) long enough and this intelligent group of software engineers are
somehow suddenly going to believe it?

From my POV, these lines apply more to you and markspace than to the
OP and me.

Peace,
Alessio

 

[Lawrence D'Oliveiro]

In message

What if in the OP's case the server is backed by a 1TB database?

1TB drives can be had for pocket change these days.

What was the problem, again?