Limitations of the program film

For security reasons, the program is very limited, and there are a lot of things we can not do. You will generally ask what it looks like and what it can do: Expand the functionality of the Web page in your browser. Since being an online surfer, we never really wanted to know whether a Web page came from a friendly or unfriendly site, and we wanted code that could be safely acted on. So we might notice a lot of restrictions:
(1) A piece of the program can not contact the local disk. This means that you cannot write and read on a local disk, and we do not want a piece of the program to read and transmit important information through a Web page. Writing is forbidden, of course, because that will cause the virus to invade. These restrictions are lifted when the digital signature is in effect.
(2) The program cannot have a menu. (Note: This is stipulated in swing) this may reduce the hassle of security and the simplification of the program. We may be notified about the benefits of the program's coordination as part of a Web page, and we usually don't pay attention to the scope of the program. There are no frames and title bars that pop up from the menu, and the frames and title bars that appear are Web browsers. Perhaps the future design can be changed to allow us to combine the browser menu with the menu of the program-the program can affect its environment will cause too much threat to the entire system security and make the program too complex.
(3) The dialog box is not trusted. In Java, dialog boxes have some difficult places to solve. First of all, they do not correctly reject the program, which is frustrating. If we pop a dialog box from the program, we'll see a message box "untrusted Patch" on the dialog. This is because, in theory, it is possible to deceive users into thinking that they are trading on the web with an old customer's local application and having them enter their credit card number. After seeing the kind of GUI developed by AWT, we may be saddened to believe that anyone will be fooled by that approach. But the program is always attached to a Web page, and can be seen in the browser, and the dialog box does not have this attachment, so theoretically possible. Therefore, we rarely meet with a program that uses a dialog box.
In newer browsers, many restrictions are relaxed for trusted patches (trusted programs are authenticated by a trusted source).
When it comes to the development of a piece of software, there are other issues to consider:
Patches are downloaded from a separate server that is suitable for different classes. Our browsers can cache patches, but there is no guarantee. One of the improvements in Java version 1.1 is the Jar (Java ARchive) file, which allows you to package all of the program piece components (including other class files, images, sounds) together in a compressed file that can be downloaded by a single server. The digital signature (the ability to validate class creators) effectively joins each individual jar file.
For security reasons, we do some work more difficult, such as accessing the database and sending e-mail. In addition, security restriction rules make it very difficult to access multiple hosts because everything must be routed through the Web server, creating a performance bottleneck, and a single link error can cause the entire process to stop.
The program slices in the browser do not have the same control type that the local application runs. For example, since users can switch pages, they don't have a formal dialog box in the program. When a user changes to a Web page or exits the browser, it is a disaster for our program-there is no way to save the state, so if we are in process and operation, the information will be lost. In addition, when we leave a Web page, different browsers will do different things to our program, so the result is inherently uncertain.