openjnlp-devel

[Openjnlp-devel] Tweak to AppletRunner.java

[Christopher H. <he...@ez...>]

I had to tweak AppletRunner.java to get it to compile correctly under JDK 1.4 
 Basically, there are 3 methods in the AppletContext interface that are new 
with that JDK - I just stubbed them to return null (if they aren't void), and 
commented them as incompletely implemented.  They're checked into CVS just to 
avoid divergence.

					Chris

Re: [Openjnlp-devel] Tweak to AppletRunner.java

[Scott K. <sko...@ap...>]

That's fine -- those additional methods are only used by the Java Plugin 
on 1.4 -- AppletRunner would only need those to satisfy the interface 
and nothing else.

Scott K.

On Tuesday, May 14, 2002, at 09:16  PM, Christopher Heiny wrote:

> I had to tweak AppletRunner.java to get it to compile correctly under 
> JDK 1.4
>  Basically, there are 3 methods in the AppletContext interface that are 
> new
> with that JDK - I just stubbed them to return null (if they aren't 
> void), and
> commented them as incompletely implemented.  They're checked into CVS 
> just to
> avoid divergence.
_____________________
Scott Kovatch
Java Runtime Classes
Apple Computer
Cleveland Hts, OH
sko...@ap...

"We're going to need some glue and a ten minute head start." - Baby Blues

Re: [Openjnlp-devel] Tweak to AppletRunner.java

[Kevin H. <ke...@na...>]

On Tuesday, May 14, 2002, at 08:22 , Scott Kovatch wrote:

> That's fine -- those additional methods are only used by the Java 
> Plugin on 1.4 -- AppletRunner would only need those to satisfy the 
> interface and nothing else.

I went ahead and implemented the methods to actually do stuff, since it 
was pretty straightforward using collections.

Do you know how these methods are used or what Sun's intention is? Seems 
odd Sun would add these to the AppletContext interface just for the Java 
Plugin. Now they're exposed to the applet itself through 
Applet.getAppletContext, so I can see applet writers using them.

Re: [Openjnlp-devel] Tweak to AppletRunner.java

[Scott K. <sko...@ap...>]

On Thursday, May 16, 2002, at 10:13  PM, Kevin Herrboldt wrote:

> On Tuesday, May 14, 2002, at 08:22 , Scott Kovatch wrote:
>
>> That's fine -- those additional methods are only used by the Java Plugin on 1.4 -- AppletRunner would only need those to satisfy the interface and nothing else.
>
> I went ahead and implemented the methods to actually do stuff, since it was pretty straightforward using collections.
>
> Do you know how these methods are used or what Sun's intention is? Seems odd Sun would add these to the AppletContext interface just for the Java Plugin. Now they're exposed to the applet itself through Applet.getAppletContext, so I can see applet writers using them.

They're related to JavaBeans -- I believe there's a feature of the plugin that allows you to wrap a Java Bean as an ActiveX control, so there's a pile of code that treats JavaBeans like applets.  As a security measure you don't want components reading from or writing to each others streams, so this is how they keep them separate.

That's a 10-minute reading-of-the-code analysis, so I may be wrong.  But, you're implementation sounds like it matches what's in the plugin.  I doubt it will ever get used, though.

Scott

_____________________
Scott Kovatch
Java Runtime Classes
Apple Computer
Cleveland Hts, OH
sko...@ap...

Re: [Openjnlp-devel] Tweak to AppletRunner.java

[Christopher H. <he...@ez...>]

On Friday 17 May 2002 08:37 am, Scott Kovatch wrote:

> They're related to JavaBeans -- I believe there's a feature of the plugin
> that allows you to wrap a Java Bean as an ActiveX control, so there's a
> pile of code that treats JavaBeans like applets.  As a security measure you
> don't want components reading from or writing to each others streams, so
> this is how they keep them separate.
>
> That's a 10-minute reading-of-the-code analysis, so I may be wrong.  But,
> you're implementation sounds like it matches what's in the plugin.  I doubt
> it will ever get used, though.

That is my understanding of their primary purpose, based on a similar quick 
scan of things.

There is a nagging idea in the back of my head that this is also intended for 
use in visual bean IDEs.  That may just be the product of all the Nyquil I've 
been taking lately (I >hate< having the flu in May :-) ).

					Chris

Re: [Openjnlp-devel] Tweak to AppletRunner.java

[Jeff A. <je...@wo...>]

At 11:37 AM -0400 5/17/02, Scott Kovatch wrote:
>On Thursday, May 16, 2002, at 10:13  PM, Kevin Herrboldt wrote:
>
>>On Tuesday, May 14, 2002, at 08:22 , Scott Kovatch wrote:
>>
>>>That's fine -- those additional methods are only used by the Java 
>>>Plugin on 1.4 -- AppletRunner would only need those to satisfy the 
>>>interface and nothing else.
>>
>>I went ahead and implemented the methods to actually do stuff, 
>>since it was pretty straightforward using collections.
>>
>>Do you know how these methods are used or what Sun's intention is? 
>>Seems odd Sun would add these to the AppletContext interface just 
>>for the Java Plugin. Now they're exposed to the applet itself 
>>through Applet.getAppletContext, so I can see applet writers using 
>>them.
>
>They're related to JavaBeans -- I believe there's a feature of the 
>plugin that allows you to wrap a Java Bean as an ActiveX control, so 
>there's a pile of code that treats JavaBeans like applets.  As a 
>security measure you don't want components reading from or writing 
>to each others streams, so this is how they keep them separate.
>
>That's a 10-minute reading-of-the-code analysis, so I may be wrong. 
>But, you're implementation sounds like it matches what's in the 
>plugin.  I doubt it will ever get used, though.
>
>Scott
>
>_____________________
>Scott Kovatch
>Java Runtime Classes
>Apple Computer
>Cleveland Hts, OH
>sko...@ap...
>

Actually, there is some documentation on what they can be used for by applets
that want to basically persist anything longer than a single session, 
and some sample code at:

http://java.sun.com/j2se/1.4/docs/guide/plugin/developer_guide/persistence.html

more useful is section 4.2 (page 24) of:

http://internal.wolfram.com/~jeffa/java/api/1.4_plugin.pdf


Jeff

Re: [Openjnlp-devel] Tweak to AppletRunner.java

[Christopher H. <he...@ez...>]

Thanks for completing that implementation.

I picked up your latest check in, and the VerifyError is still there.  Web 
searching seems to indicate that it might be a conflict between things 
compiled with Blackdown or Jikes and the Sun JVM.  At any rate, the JVM is 
not happy with something relating to line 276, but unfortunately the error 
message is way to nebulous.  How do I determine which compiler Ant is using 
in the builds?

Another way the message can result is through misuse of scoping loopholes in 
the language, or compiler bugs related to scoping.

I'm going to try constructing a test case with a similar set of relationships 
between the classes, to see if that will barf in the same spot.

					Chris 

[Openjnlp-devel] FileCachedEntry and Java 1.4

[Kevin H. <ke...@na...>]

On Friday, May 17, 2002, at 11:08 , Christopher Heiny wrote:
[...]
> I picked up your latest check in, and the VerifyError is still there.  
> Web

I haven't gotten the new FileCachedEntry checked in, sorry. I ran into a 
snag but will get it done today. I'll try compiling under Java 1.4 on 
one of my linux boxen and see what I get.

> searching seems to indicate that it might be a conflict between things
> compiled with Blackdown or Jikes and the Sun JVM.  At any rate, the JVM 
> is
> not happy with something relating to line 276, but unfortunately the 
> error
> message is way to nebulous.  How do I determine which compiler Ant is 
> using
> in the builds?

I dunno, use "ant -debug", that usually causes copious amounts of 
output. The ant rule for OpenJNLP compiling uses the default compiler in 
the <javac> task as far as I know (no special setting for selecting 
compiler).