Just include the aspectjrt.jar as a required archive. For example, here is the HTML code for an HTML editor applet that contains some debugging aspects: <APPLET CODE='com.company.swing.applets.EditorApplet' WIDTH='700' HEIGHT='525'> <PARAM NAME="CODE" VALUE="com.company.swing.applets.EditorApplet" > <PARAM NAME="ARCHIVE" VALUE ="../company-applets.jar,../aspectjrt.jar,../xmlrpc-applet.jar" > <PARAM NAME="type" VALUE="application/x-java-applet;version=1.

JSP: It is possible to use AspectJ to affect code in JSPs by precompiling them into Java sources and compiling these with ajc. This can be used, e.g., to customize displays by turning on and off custom JSP taglibs. The mapping from a given jsp source to java package and class name is not standardized, which means doing this imposes dependencies on specific container versions. EJB: AspectJ supports a wide variety of aspects for EJBs.

The AspectJ compiler or weaver is required at some point, but many people can use AspectJ without changing their build or deployment process significantly. For aspects that are not required to compile, you can use the AspectJ binary weaver, run at build-time or class-load-time. You can write aspects using the original code style (which must be compiled with the AspectJ compiler) or using the annotation style new in AspectJ 5 (which may be compiled with Javac or the AspectJ compiler).

One way to accomplish this is to have the applets communicate via TCP/IP sockets to the servlet. The servlet would then use a custom protocol to receive and push information between applets. However, this solution does have firewall problems if the system is to be used over and Internet verses an Intranet.

But at this time, unfortunately not. The two compilers are just not at all compatible. In an ideal world, there would be a wonderful Open Source extensible compiler framework for Java that both GJ and AspectJ would be built on top of, and they would seamlessly interoperate along with all other extensions to Java that you might be interested in, but that's not the case (yet?).

No. The AspectJ tools download is completely self-contained and does not require that you work in Eclipse. For information on IDE support, see Q: How well does AspectJ integrate with existing Java development tools?.

Yes. Those are client-side technologies, so the host doesn't have to do anything to support or enable them. Any browser (such as Internet Explorer or Netscape) that supports them is enough, so any host will do. It doesn't matter whether Java or Flash are listed among the plan's features, they are supported by default.

You may use AspectJ in your product or project with little risk. Several factors play a role in reducing the risk of adopting this new technology: AspectJ is an addition to Java, and can be introduced into a project in a way that limits risk. See Q: How should I start using AspectJ? for some suggestions on how to do this. The AspectJ compiler accepts standard Java as input and produces standard Java bytecode as output. In 1.

Microsoft supplies the J# Browser Controls that provide the capability to migrate existing applets to run within the context of the .NET Framework - usually with no changes to the Java applet source code!

Java v1.0.2 is limited in its font choices. To be safe with cross-platform names stick with one of the following (exactly as named): TimesRoman, Courier, Dialog, DialogInput, Helvetica. Font size can be just about any positive integer, but certain browsers don't support values greater than 36. The font style may be either: 'plain', 'bold', 'italic', or 'bolditalic'.

Droplets have full browser-independent capabilities, and remain as persistent desktop applications even when the browser is closed. Unlike applets, Droplets deliver zero application code to the client, making start-up much faster. This gives developers the ability to write much larger, enterprise-strength applications without worrying about the start-up cost.

For now, we prefer that you simply link to this site. For one thing, that lets people have a discussion around a visualization using the bookmarking and forums that we provide.

Use the latest, greatest, fastest JVM you can get your hands on for your platform. The compiler's performance is dependent on the performance of the JVM it is running on, so the faster a JVM you can find to run it on, the shorter your compile times will be. At a minimum you need to use a Java 2 or later JVM to run the compiler (J2SE 1.3 for AspectJ 1.1). We realize that this constraint can be a problem for users who don't currently have a Java 2 JVM available.

In AspectJ 1.0, the PARSER for ajc is written by hand. This choice was made with full awareness of the generator tools out there. (Jim had for example used the excellent javacc tool for building the parser for JPython (now Jython)). One of the reasons that AspectJ uses a hand-written parser is that using javacc taught Jim about the LL-k design for parsers (pioneered by antlr). As opposed to the state-machine parsers produced by yacc, these parsers are very readable and writable by humans.

Author: Alex Chaffee (http://www.jguru.com/guru/viewbio.jsp?EID=3) Question originally posed by swati m (http://www.jguru.com/guru/viewbio.jsp?EID=64343 Applets run inside browsers, and servlets run inside servers. So broadly speaking, use applets when you need dynamism on the client side, and use servlets when you need dynamism on the server side. Servlets can produce any HTML (or indeed, any file type), and therefore are much more versatile than applets.

Java Applets inside Safari can be configured to run any installed Java version by using the Java Preferences application.

Yes, JavaMail will work in applets in browsers that support the required JDK version. The Java Plug-in may be required to provide such support.

Most of the applets I use come from Fabio Ciucci's site Anfy Java. Some other good resources for java applets are Gamelan, Java Boutique and Web Developers Journal.

Yes. Even though the Java Plug-in has been enhanced to support APPLET tags, it is fully backward compatible with existing web pages that use OBJECT tags to launch applets. Moreover, the JRE/Java Plug-in continues to ship with the HTML Converter for those developers who want to invoke their applets using OBJECT rather than APPLET tags.

Standard? Hmmm... just link to The Applet Depot's front page (http://www.ericharshbarger.com/java/), and maybe mention me by name (Eric Harshbarger). Go for it. I am always willing to hear new ideas. I cannot guarantee the suggestion will be implemented, but I will consider it.

Yes in signed applets, but no in unsigned applets (most cases). Since we do not allow unsigned applets access to any communications port under the JDK1.1 security model, you can not use the Java communications API with unsigned applets. We do plan to be compliant to JDK1.2 security model in later releases, which might allow trusted applet access to ports. The javax.comm.properties file is not intended to be edited by users.

Any locally attached, intranet or Internet user equipped with either Netscape Navigator or Microsoft Internet Explorer, and Java Plug in 1.3 can use ThinView applets.

AspectJ 1.1 through 1.5.1 source code and documentation is available under the Common Public License 1.0. The AspectJ 1.0 tools are open-source software available under the Mozilla Public License 1.1. That documentation is available under a separate license that precludes for-profit or commercial redistribution. Most users only want to use AspectJ to build programs they distribute. There are no restrictions here.

AspectJ is based on over ten years of research at Xerox Palo Alto Research Center as funded by Xerox, a U.S. Government grant (NISTATP), and a DARPA contract. It has evolved through open-source releases to a strong user community and now operates as an open source project at http://eclipse.org/aspectj The AspectJ team works closely with the community to ensure AspectJ continues to evolve as an effective aspect-oriented programming language and tool set. The latest release is 1.