My vendor is involved but the vendor has no knowledge of the jt400.jar I am using and so I have been investigating from that angle to try and prove or disprove something in that class might be the problem. Since my error is about reflection and it appears that the jt400.jar is using that the error is coming from the jt400.jar and not the vendors code. I'm not real thrilled about needing to distribute a policy file to every PC that needs to use the applet. That would be OK for college owned PCs as we can push the policy file out but this applet could be used from an employee on a home system on a vpn connection and I want to try and use the tool to build applications that could be used by students also and I will not be trying to have them modify a java policy file to make that possible. I will go learn about how to sign an applet and see of that is an option for me.

Thanks for the explination

-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx [mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of Joe Pluta
Sent: Friday, July 25, 2008 9:03 AM
To: Java Programming on and around the iSeries / AS400
Subject: Re: using jt400 in a java applet

Mike Cunningham wrote:
Has anyone ever used the IBM supplied jt400.jar in a java applet application that is sent to the client and executed from the PC? I have a java application that will run from my PC but when I deploy it as an applet it fails with a permissions error. It is acting like the jt400.jar files is trying to run outside the JRE and is being denied permission.

Error Message: access denied (java.lang.reflect.ReflectPermission suppressAccessChecks)
at Source)

Your vendor ought to be helping you with this, but I can point you in
the right direction. Basically, the JT400 code is trying to use
reflection to access something it normally wouldn't be able to access
using the setAccessible method. I haven't looked at that code in some
time, so I don't know why it's doing it, but generally that requires
some pretty good security access.

As of JDK1.2, if you have a security manager installed and don't have a
security policy in place, you will get exactly this message. This
usually isn't an issue, because in most cases people don't have a
security manager installed. However, applets by definition run with a
security manager; in fact, that's pretty much what it was designed for -
to protect client computers from rogue code. This is what is called the
applet "sandbox".

So you need to circumvent the sandbox. AFAIK, you can do this by either
using a signed applet as Paul suggested, or you can put a java.policy
file in your JRE security folder. The latter needs to be done on every
machine using the applet.

I'll try to stay off my sandbox, but generally speaking applet
technology is being replaced by AJAX. Between the powerful UI provided
by the new JavaScript frameworks and the fact that you can get data in
small chunks from the server using AJAX, there are far fewer situations
where downloading actual Java applications is required.

On the other side of the coin, Sun just announced a major upgrade in
applet technology in which applets take advantage of Sun's Java Web
Start technology. I don't know if your vendor is aware of this new
technology; if so, it makes applets a more viable alternative, although
I sense this is really Sun's response to JavaScript, since it's the
first major change to applets in a decade.

Anyway, enough editorializing. I think your best bet is signing your
applets, although if you have complete control over all your client PCs,
a java policy file is a possibility.

This is the Java Programming on and around the iSeries / AS400 (JAVA400-L) mailing list
To post a message email: JAVA400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
or email: JAVA400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.