Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #23181 > unrolled thread

FireFox Bug 856969 -Too much recursion error with Java LiveConnect Applet

Back to article view | Back to comp.lang.java.programmer

Contents

  FireFox Bug 856969 -Too much recursion error with Java LiveConnect Applet Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2013-04-02 20:44 +0800
    Re: FireFox Bug 856969 -Too much recursion error with Java LiveConnect Applet Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2013-04-16 17:47 +0800
      Re: FireFox Bug 856969 -Too much recursion error with Java LiveConnect Applet Silvio <silvio@internet.com> - 2013-04-16 13:01 +0200
        Re: FireFox Bug 856969 -Too much recursion error with Java LiveConnect Applet Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2013-04-21 14:44 +0800
          Re: FireFox Bug 856969 -Too much recursion error with Java LiveConnect Applet "Qu0ll" <Qu0llSixFour@gmail.com> - 2013-04-21 20:17 +1000
            Re: FireFox Bug 856969 -Too much recursion error with Java LiveConnect Applet Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2013-04-25 10:20 +0800
              Re: FireFox Bug 856969 -Too much recursion error with Java LiveConnect Applet "Qu0ll" <Qu0llSixFour@gmail.com> - 2013-04-25 15:14 +1000

#23181 — FireFox Bug 856969 -Too much recursion error with Java LiveConnect Applet

Hi,

I have worked out what I was doing wrong with the previous Chrome error: -
http://code.google.com/p/chromium/issues/detail?id=129528

So now Chrome is good to go but FF and IE are still causing/exhibiting 
problems under certain circumstances. I have really, really narrowed 
down the SSCCE and causes/effects for what I feel is demonstrably a bug 
with these browsers.

See the following for complete FireFox details: -
https://bugzilla.mozilla.org/show_bug.cgi?id=856969

I don't think there's much on the Java or Javascript side that I can do 
to mitigate the failure more than I have but I'm open to suggestions 
from those of you with experience of LiveConnect.

If you can help solve the problem please do. (If you just respond to 
hear your own voice then please piss off)

Cheers Richard Maher

[toc] | [next] | [standalone]

#23467

On 4/2/2013 8:44 PM, Richard Maher wrote:
> Hi,
>
> I have worked out what I was doing wrong with the previous Chrome error: -
> http://code.google.com/p/chromium/issues/detail?id=129528
>
> So now Chrome is good to go but FF and IE are still causing/exhibiting
> problems under certain circumstances. I have really, really narrowed
> down the SSCCE and causes/effects for what I feel is demonstrably a bug
> with these browsers.
>
> See the following for complete FireFox details: -
> https://bugzilla.mozilla.org/show_bug.cgi?id=856969
>
> I don't think there's much on the Java or Javascript side that I can do
> to mitigate the failure more than I have but I'm open to suggestions
> from those of you with experience of LiveConnect.
>
> If you can help solve the problem please do. (If you just respond to
> hear your own voice then please piss off)
>
> Cheers Richard Maher

  This from  https://bugzilla.mozilla.org/show_bug.cgi?id=856969 :-

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #24)
 > At this point, this issue is not a priority for the project. The java 
plugin
 > is a closed-source blob that has a very poor track record of spinning 
nested
 > event loops when it is not correct or safe to do so, and so we have been
 > more and more aggressively preventing it from doing so. The correct 
solution
 > to this bug is to stop using Java.
 >
 > If somebody wants to provide a backtrace which identifies exactly how the
 > recursion happens, I can provide details about how you might be able 
to fix
 > the problem. Until then, this issue is not going to be tracked.

  and . . .

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #26)
 > The Mozilla project definitely has hostility toward Java, but it's not
 > prejudicial. It is clear that the design of the Java plugin and code is
 > fundamentally insecure, and the repeated exploits against it and slow
 > response times make it clear that the Java plugin is not something that
 > should be part of the web. We have to continue supporting it for legacy
 > sites, but Java will be blocked by default and users will have to 
agree to
 > override the security warning in order to enable Java in the near future.

and . . .

(In reply to Richard Maher from comment #33)
 > (In reply to Benjamin Smedberg  [:bsmedberg] from comment #26)
 > > . . .but Java will be blocked by default and users will have to 
agree to
 > > override the security warning in order to enable Java in the near 
future.
 >
 > Churlish, unworthy, and quite frankly proprietary :-(


Is everyone at Java engineering just used to being bitch-slapped in 
public these days or does Larry look after his assets?

Cheers Richard Maher

[toc] | [prev] | [next] | [standalone]

#23468

On 04/16/2013 11:47 AM, Richard Maher wrote:
> On 4/2/2013 8:44 PM, Richard Maher wrote:
>> Hi,
>>
>> I have worked out what I was doing wrong with the previous Chrome
>> error: -
>> http://code.google.com/p/chromium/issues/detail?id=129528
>>
>> So now Chrome is good to go but FF and IE are still causing/exhibiting
>> problems under certain circumstances. I have really, really narrowed
>> down the SSCCE and causes/effects for what I feel is demonstrably a bug
>> with these browsers.
>>
>> See the following for complete FireFox details: -
>> https://bugzilla.mozilla.org/show_bug.cgi?id=856969
>>
>> I don't think there's much on the Java or Javascript side that I can do
>> to mitigate the failure more than I have but I'm open to suggestions
>> from those of you with experience of LiveConnect.
>>
>> If you can help solve the problem please do. (If you just respond to
>> hear your own voice then please piss off)
>>
>> Cheers Richard Maher
>
>   This from  https://bugzilla.mozilla.org/show_bug.cgi?id=856969 :-
>
> (In reply to Benjamin Smedberg  [:bsmedberg] from comment #24)
>  > At this point, this issue is not a priority for the project. The java
> plugin
>  > is a closed-source blob that has a very poor track record of spinning
> nested
>  > event loops when it is not correct or safe to do so, and so we have been
>  > more and more aggressively preventing it from doing so. The correct
> solution
>  > to this bug is to stop using Java.
>  >
>  > If somebody wants to provide a backtrace which identifies exactly how
> the
>  > recursion happens, I can provide details about how you might be able
> to fix
>  > the problem. Until then, this issue is not going to be tracked.
>
>   and . . .
>
> (In reply to Benjamin Smedberg  [:bsmedberg] from comment #26)
>  > The Mozilla project definitely has hostility toward Java, but it's not
>  > prejudicial. It is clear that the design of the Java plugin and code is
>  > fundamentally insecure, and the repeated exploits against it and slow
>  > response times make it clear that the Java plugin is not something that
>  > should be part of the web. We have to continue supporting it for legacy
>  > sites, but Java will be blocked by default and users will have to
> agree to
>  > override the security warning in order to enable Java in the near
> future.
>
> and . . .
>
> (In reply to Richard Maher from comment #33)
>  > (In reply to Benjamin Smedberg  [:bsmedberg] from comment #26)
>  > > . . .but Java will be blocked by default and users will have to
> agree to
>  > > override the security warning in order to enable Java in the near
> future.
>  >
>  > Churlish, unworthy, and quite frankly proprietary :-(
>
>
> Is everyone at Java engineering just used to being bitch-slapped in
> public these days or does Larry look after his assets?
>
> Cheers Richard Maher


Somewhere around 2K I used to have Applets inside web-applications both 
as visual components and as a generic Ajax communication broker avant la 
lettre that selectively posted JS-events to the server and adjusted the 
HTML from the response.

I replaced the Ajaxy stuff with equivalent JS in 2001 and have stayed 
away from visual components that might once have required Applets until 
SVG and later HTML5 gave me the proper tools.

Applets are an archaic artefact and Larry does not give a damn about 
them. The same goes for the browser developers.

[toc] | [prev] | [next] | [standalone]

#23546

On 4/16/2013 7:01 PM, Silvio wrote:
> On 04/16/2013 11:47 AM, Richard Maher wrote:

>>
>> Is everyone at Java engineering just used to being bitch-slapped in
>> public these days or does Larry look after his assets?
>>
>> Cheers Richard Maher
>

> Applets are an archaic artefact and Larry does not give a damn about
> them. The same goes for the browser developers.
>
>

Bollocks!!!

As can be seen from 
http://www.smh.com.au/it-pro/security-it/oracle-fixes-42-holes-in-java-to-revive-confidence-20130417-2hz6n.html#ixzz2QfmbSO5B 
there is an aggressive (albeit reactive) effort to firm-up Applets. Let 
alone the giant strides that were made with the new applet plugin circa 
6.10.

http://docs.oracle.com/javase/6/docs/technotes/guides/jweb/applet/applet_execution.html

Yet another parrot with the HTML5 mantra :-( SVG? SVfuckingG? Are you 
serious??? Have you not seen what Adobe Flex does or do you just choose 
to be blind? Then what about WebWorkers and WebSockets? Has anyone seen 
two other functionally deficient and naive pieces of shit since kosher BLTs?

Anyway if there are other than fanbois here can I please have a "me too" 
at: -

https://connect.microsoft.com/IE/feedback/details/784918/out-of-stack-space-error-with-java-liveconnect-applet#details

and

https://bugzilla.mozilla.org/show_bug.cgi?id=856969

and if you're really lonely: -

http://code.google.com/p/chromium/issues/detail?can=2&start=0&num=100&

q=&colspec=ID%20Pri%20M%20Iteration%20ReleaseBlock%20Cr%20Status%20

Owner%20Summary%20OS%20Modified&groupby=&sort=&id=129528

Cheers Richard Maher

[toc] | [prev] | [next] | [standalone]

#23548

"Richard Maher"  wrote in message news:kl01s2$6kq$4@speranza.aioe.org...

Apologies for the lack of indentation, reply at the end...

On 4/16/2013 7:01 PM, Silvio wrote:
> On 04/16/2013 11:47 AM, Richard Maher wrote:

>>
>> Is everyone at Java engineering just used to being bitch-slapped in
>> public these days or does Larry look after his assets?
>>
>> Cheers Richard Maher
>

> Applets are an archaic artefact and Larry does not give a damn about
> them. The same goes for the browser developers.
>
>

Bollocks!!!

As can be seen from
http://www.smh.com.au/it-pro/security-it/oracle-fixes-42-holes-in-java-to-revive-confidence-20130417-2hz6n.html#ixzz2QfmbSO5B
there is an aggressive (albeit reactive) effort to firm-up Applets. Let
alone the giant strides that were made with the new applet plugin circa
6.10.

http://docs.oracle.com/javase/6/docs/technotes/guides/jweb/applet/applet_execution.html

Yet another parrot with the HTML5 mantra :-( SVG? SVfuckingG? Are you
serious??? Have you not seen what Adobe Flex does or do you just choose
to be blind? Then what about WebWorkers and WebSockets? Has anyone seen
two other functionally deficient and naive pieces of shit since kosher BLTs?

Anyway if there are other than fanbois here can I please have a "me too"
at: -

https://connect.microsoft.com/IE/feedback/details/784918/out-of-stack-space-error-with-java-liveconnect-applet#details

and

https://bugzilla.mozilla.org/show_bug.cgi?id=856969

and if you're really lonely: -

http://code.google.com/p/chromium/issues/detail?can=2&start=0&num=100&

q=&colspec=ID%20Pri%20M%20Iteration%20ReleaseBlock%20Cr%20Status%20

Owner%20Summary%20OS%20Modified&groupby=&sort=&id=129528

----------------------------------------------------

Richard, I used to be a very strong proponent of applets.  However, the 
browser manufacturers are so hell-bent on making the applet user experience 
so incredibly painful that I no longer think they are a viable technology. 
The applet user virtually has to jump through flaming hoops just to launch 
one of these things nowadays.

Don't get me wrong, applets are and always will be superior in what they can 
achieve over HTML but as no one but Oracle wants them to succeed (and even 
then that's questionable), I just can't see them ever achieving any 
penetration into the world of web applications.

Added to this is the extreme hit that "brand Java" is taking in general with 
the frequent and recurrent security issues.  Perhaps it's been blown out of 
proportion by the anti-Java crowd but there's no doubt that public faith in 
anything Java running in a web browser is at an all-time low.

For Java-based UIs, there's really only one choice: JavaFX.  And it's a 
really good choice!  With most vendors releasing native apps instead of 
HTML-based apps on many platforms now, JavaFX provides an excellent way to 
leverage the power and functionality of the Java platform.  And, if you 
still insist, it *does* in fact run inside a web browser :-)

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
Qu0llSixFour@gmail.com
[Replace the "SixFour" with numbers to email me] 

[toc] | [prev] | [next] | [standalone]

#23635

On 4/21/2013 6:17 PM, Qu0ll wrote:
> "Richard Maher"  wrote in message news:kl01s2$6kq$4@speranza.aioe.org...
>
> Apologies for the lack of indentation, reply at the end...
>
> On 4/16/2013 7:01 PM, Silvio wrote:
>> On 04/16/2013 11:47 AM, Richard Maher wrote:
>
>>>
>>> Is everyone at Java engineering just used to being bitch-slapped in
>>> public these days or does Larry look after his assets?
>>>
>>> Cheers Richard Maher
>>
>
>> Applets are an archaic artefact and Larry does not give a damn about
>> them. The same goes for the browser developers.
>>
>>
>
> Bollocks!!!
>
> As can be seen from
> http://www.smh.com.au/it-pro/security-it/oracle-fixes-42-holes-in-java-to-revive-confidence-20130417-2hz6n.html#ixzz2QfmbSO5B
>
> there is an aggressive (albeit reactive) effort to firm-up Applets. Let
> alone the giant strides that were made with the new applet plugin circa
> 6.10.
>
> http://docs.oracle.com/javase/6/docs/technotes/guides/jweb/applet/applet_execution.html
>
>
> Yet another parrot with the HTML5 mantra :-( SVG? SVfuckingG? Are you
> serious??? Have you not seen what Adobe Flex does or do you just choose
> to be blind? Then what about WebWorkers and WebSockets? Has anyone seen
> two other functionally deficient and naive pieces of shit since kosher
> BLTs?
>
> Anyway if there are other than fanbois here can I please have a "me too"
> at: -
>
> https://connect.microsoft.com/IE/feedback/details/784918/out-of-stack-space-error-with-java-liveconnect-applet#details
>
>
> and
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=856969
>
> and if you're really lonely: -
>
> http://code.google.com/p/chromium/issues/detail?can=2&start=0&num=100&
>
> q=&colspec=ID%20Pri%20M%20Iteration%20ReleaseBlock%20Cr%20Status%20
>
> Owner%20Summary%20OS%20Modified&groupby=&sort=&id=129528
>
> ----------------------------------------------------
>
> Richard, I used to be a very strong proponent of applets.  However, the
> browser manufacturers are so hell-bent on making the applet user
> experience so incredibly painful that I no longer think they are a
> viable technology. The applet user virtually has to jump through flaming
> hoops just to launch one of these things nowadays.
>
> Don't get me wrong, applets are and always will be superior in what they
> can achieve over HTML but as no one but Oracle wants them to succeed
> (and even then that's questionable), I just can't see them ever
> achieving any penetration into the world of web applications.
>
> Added to this is the extreme hit that "brand Java" is taking in general
> with the frequent and recurrent security issues.  Perhaps it's been
> blown out of proportion by the anti-Java crowd but there's no doubt that
> public faith in anything Java running in a web browser is at an all-time
> low.
>
> For Java-based UIs, there's really only one choice: JavaFX.  And it's a
> really good choice!  With most vendors releasing native apps instead of
> HTML-based apps on many platforms now, JavaFX provides an excellent way
> to leverage the power and functionality of the Java platform.  And, if
> you still insist, it *does* in fact run inside a web browser :-)
>
> --
> And loving it,
>
> -Qu0ll (Rare, not extinct)
> _________________________________________________
> Qu0llSixFour@gmail.com
> [Replace the "SixFour" with numbers to email me]


It's hard hearing that from someone whose IT opinion I respect.

I've believed for years that JavaFX was still-born and now see that it 
is gaining some traction but I'm with the "Browser is the GUI" crowd and 
think you're painting yourself into a corner again. Even .NET sites have 
conceded that sending JSON back and forth from the server is the way to 
go and JavaScript is doing the GUI.

I'm not saying Java has a big part to play with the GUI (very little in 
fact) but the feature rich infrastructure tool-set it brings to the 
browser (even sand-boxed) is second to none.

I guess it's just that when Apple, Google, and Microsoft donned their 
brown shirts and started kicking in Java's windows I expected Larry to 
be a little more upset about it.

Cheers Richard Maher

[toc] | [prev] | [next] | [standalone]

#23637

"Richard Maher"  wrote in message news:kla3u9$7g4$1@speranza.aioe.org...

> It's hard hearing that from someone whose IT opinion I respect.
>
> I've believed for years that JavaFX was still-born and now see that it is 
> gaining some traction but I'm with the "Browser is the GUI" crowd and 
> think you're painting yourself into a corner again. Even .NET sites have 
> conceded that sending JSON back and forth from the server is the way to go 
> and JavaScript is doing the GUI.
>
> I'm not saying Java has a big part to play with the GUI (very little in 
> fact) but the feature rich infrastructure tool-set it brings to the 
> browser (even sand-boxed) is second to none.
>
> I guess it's just that when Apple, Google, and Microsoft donned their 
> brown shirts and started kicking in Java's windows I expected Larry to be 
> a little more upset about it.

Everyone is talking about HTML5/JavaScript/CSS etc. as being the future of 
application development.  What is happening in reality is considerably 
different however.

It's well known that Facebook regrets investing so much in an HTML 
application and then diverted their attention to developing native apps. 
LinkedIn have just done exactly the same thing.  When iOS for iPhone was 
first announced, Apple expected most apps would be browser based only to 
find that now the vast majority of apps are in fact native.  Same thing for 
Android.  Even Microsoft is finding that developers aren't really interested 
in HTML for "Metro" apps (and not really interested in Windows 8 specific 
apps at all).

The point is that a world dominated by HTML5 has simply not eventuated and 
possibly never will.  With dramatic declines in sales of PCs, it won't be 
long until the vast majority of computer uses will be mainly using tablets 
and mobiles for their everyday computing.  Desktop PCs will never go away 
but will only be used by a very specific kind of user such as developers, 
graphic designers etc.  Given all this, in 5-10 years time, who will be even 
using a web browser?  Just about every major website has a native app to 
access their site which provides more features and becomes the most common 
way to interact with their site.  Are we moving to an app-centric world 
without a need for web browsers?

Clearly there is definitely a future for native apps and probably always 
will be.  They are more prevalent now than ever and continue to grow in 
popularity.  The problem with applets is that they are part native and part 
browser based.  The latter seriously restricts what they can do and limits 
their availability by imposing all manner of usability impediments as 
previously mentioned.  To me it makes sense to either go all the way with a 
native app or all the way with a web app.

Like you, I am disappointed in the way Oracle has responded to the covert 
attacks on applets by Microsoft, Google, Apple and others but you need to 
remember that Oracle is an "enterprise technology" company.  Why would they 
care about applets at all?  I think we are lucky they actually care about 
Java in general.  Unfortunately you and I cannot "protect" applets or have 
any influence on the browser vendors and the level of support they provide 
for them.  Clearly Oracle are not going to do that either.  This is why I 
reluctantly walked away from applets after many years of investing in them.

But this does not mean I have to walk away from Java or walk away from 
client side or GUI Java completely.  For reasons which up to now escape me, 
Oracle *do* seem to be interested in JavaFX.  Also, JavaFX is a very good 
graphics toolkit.  Oracle have made it quite clear that they see Swing and 
AWT and traditional applets as being completely dead.  They will not spend 
another cent in enhancing those technologies.  They are encouraging everyone 
to move to JavaFX and that is what I am doing.

JavaFX gives us the ability to do many things we simply couldn't do in Swing 
and I very much like what I see.  It is just another Java API and I can use 
the entire Java platform if I want to.  That's the main advantage JavaFX has 
over other competing toolkits.  None of those competing technologies gives 
the developer access to so much rich, stable and advanced functionality.

Anyway, I have never been a big fan of HTML based UIs.  The performance has 
always been a huge problem and still is (yes, don't believe the hype). 
JavaScript is a difficult language to use to develop complex, sophisticated 
applications and has nowhere near the same support in IDEs as Java does. The 
need for browser sniffing is still prevalent with each browser implementing 
HTML and JavaScript in a slightly different way.  This is in spite of the 
rise of libraries such as jQuery.  Added to this is the fact that there are 
simply many, many things that you just can't do in a browser based app and 
why would I invest heavily in a solution which isn't ideal on phones and 
tablets?

Unfortunately there is still no "kick arse" 
technology/toolkit/API/library/product that is going to allow you to develop 
a single code base and deploy to all the various platforms out there in such 
a way that each deployment is optimised for that platform.  However, JavaFX 
has the potential to be this object of desire if it could just get over the 
one major drawback it has now which is that, at the moment at least, it 
doesn't run on iOS or Android.

And this is where I worry and why I have not fully committed to JavaFX just 
yet.  The problem is that Oracle management are not convinced that investing 
in porting JavaFX to mobiles and tablets is a commercially sensible thing to 
do.  How they could be so amazingly ignorant like this is anyone's guess! 
The JavaFX development team at Oracle lead by Richard Bair is absolutely 
passionate about getting JavaFX onto those platforms but they are not being 
funded to do so.  For some inexplicable reason, Oracle thinks it's more 
important or financially sound to invest in porting JavaFX to 
obscure/niche/novelty hardware like Raspberry Pi or Beagle Board which 
hardly anyone actually uses.  They even think that adding support for 3D 
graphics is more important than adding support for phones and tablets.

Some of the decisions being made by Oracle management in this area at the 
moment defy belief but the fact they are making them really worries me. 
Given that PC sales are rapidly declining and that at the moment JavaFX only 
really runs on Windows, MacOS and Linux, what's going to happen to it when 
most people abandon such platforms and use their phones and tablets to do 
most or all of their computing?  Who will be using JavaFX then?

Most pundits agree that any current technology that does not adapt and 
evolve to fully embrace the emerging platforms is effectively already dead. 
It's obvious to everyone except upper management inside Oracle that JavaFX 
is dead unless support for mobiles and tablets appears in the very near 
future.

On the positive side, Oracle has just released all the code they have been 
working on to support JavaFX on these platforms.  Over the last couple of 
years they have been teasing us with demos of JavaFX running on iOS and 
Android but this has not developed into solutions that we can all use.  Now 
that they are releasing the code they have developed we find that the Java 
part of the equation has been running in fully interpreted mode only and has 
been unacceptably slow.  This is because an OS like iOS does not support 
executable memory which is required by JIT compilers such as HotSpot.  There 
are also "legal" and political issues surrounding interpreted code. The only 
way to have Java and JavaFX running on these platforms is to implement a 
Java AOT compiler.

The situation at the moment is that Oracle has released all the code they 
have and are now washing their hands of it.  They do not have the funding to 
take the porting process any further.  They may never have this support from 
management.  Oracle has declared that the "community" must now pick up this 
code and do all the work remaining in getting JavaFX to run on mobiles and 
tablets.  It's entirely up to us now.

This is concerning on at least two fronts.  First, who is going to pick up 
this project?  Secondly, what does this say about Oracle's opinion of JavaFX 
and its future in general?

We need a cashed-up company to come along now and lead the project and 
invest enough money into it to make it happen.  This is not about 
individuals, there is simply too much work for any one person to do on their 
own.  Will this ever happen?

The bottom line is that Java and JavaFX have all the features I need to 
develop the kind of software I am working on and provide a better solution 
than any of the competitors.  However, until I can be convinced that it will 
run on iOS and Android one day I will be very reluctant to devote my 
attention to it in any committed way.

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
Qu0llSixFour@gmail.com
[Replace the "SixFour" with numbers to email me] 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web