RE: [Jscheme-user] using Java2D from JScheme applets

[Timothy J. H. <ti...@cs...>]

Hi Boris,

On Jun 28, 2005, at 12:26 AM, Borislav Iordanov wrote:

> Hi,
> =A0
> I=92m trying to use the Java2D API from a Scheme applet. But I=92m =
getting =20
> an permissions error:
> =A0
> (.getTransform graphics )
> =A0 graphics =3D =20
> =
sun.java2d.SunGraphics2D[font=3Djava.awt.Font[family=3DDialog,name=3DDialo=
g,s=20
> tyle=3Dplain,size=3D12],color=3Djav...
> =A0 bird =3D ((233 . 501) 2 . -1)
> =A0 color =3D java.awt.Color[r=3D0,g=3D0,b=3D255]
> =A0
> =A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> java.security.AccessControlException: access denied =20
> (java.lang.RuntimePermission accessClassInPackage.sun.awt)
I think the problem is that Applets have a default security model that =20=

prevents them from finding the class of an object.
The way (.getTransform graphics) is implemented in javadot notation, is =20=

that it first finds the class of the "graphics" object and then
looks for a "getTransform" method.

You can simplify the process and avoid the access error by using the =20
extended javadot notation in which you explicity provide
the class information:
   (.java.awt.Graphics2D.getTransform graphics)

or if you have imported the class earlier in the code
  (import "java.awt.Graphics2D")
you can provide just the classname, not the full package+class name
   (.Graphics2D.getTransform graphics)

The javadot imiplementation of this extended notation,  goes directly =20=

to the
specified class and looks for all methods with the name "getTransform" =20=

and then finds the most
specific method with the right number of parameters that match the =20
arguments. This can all be done
without explicitly asking the system for the types of the objects (i.e. =20=

it uses .instanceOf rather than .getClass)

> =A0
> It seems that the applet support in Jscheme is geared towards JDK 1.1. =
=20
> So I modified SchemeApplet.java to extend JApplet instead of Applet.
We should probably have two of these SchemeApplet and SchemeJApplet ...

>  Same result. I implemented the =91paint(Graphics g)=92 method in =20
> SchemeApplet using the API that is yielding those access control =20
> exceptions, and in this case it works. If, instead, my =20
> SchemeApplet.paint method calls a scheme proc for painting (in the =20
> same way that the =91start=92 and =91init=92 procs are called for =
example), =20
> then I get the access control problem above.
This would make sense if my analysis above is correct....

>  Conclusion: looks like the permissions block happens only when those =20=

> APIs are used through reflection (I don=92t think it has anything to =
do =20
> with class loading issues), by the Scheme interpreter=85
> =A0
> Any idea?
I think it can be solved using  the extended javadot notation   =20
(.CLASSNAME.METHODNAME  OBJ A1 ... An)
where the initial "." before the CLASSNAME is critical!!

> =A0
> Best,
> Borislav
>


Please tell me if this helps! You may have to do this for all of the =20
javadot instance method calls in your applet.

Best,
---Tim---