• Articles by category
• Projects
• Recent Changes

• Submit your applet
• Review applets
• Upload File

• All articles

Selected categories:

• Physics
• Electronics
• Bioinformatics
• Biology
• Barcodes
• Astronomy, geography
• Communication
• Mathematics
• Statistics
• Programming
• Games

• Forum and issue tracker
• Help on editing
• Contact

   New articles (RSS)

See also Applet requirements

[Edit]Respect the licensing, also when it is Free

• Double check your project for all files you may not have rights to release. If such are present, write alternative replacements first.
• Always include the license file in your code. Some licenses require this; even when they do not do, it is highly desirable as eliminates possible misunderstandings.
• If you are not the first author and especially not the first owner, mark files you have changed, also stating the date of change. Never remove any legal texts left by the previous owners, also when they appear in GUI.
• Put short licensing information on the top of every class defined in a separate file.

[Edit]Perform cleanup

• Remove .cvs, .svn, automated editor backups and similar files.
• Set your encoding in to UTF-8 in the editor settings (otherwise national characters may show up as garbage).

[Edit]Source code only

You must submit sources, and not a compiled .class files. To make sure we run the same code as we review it needs to be compiled on a server side. Please do not include inside the archive .class files, .jar files (like libraries) and anything the like. Source code is required regardless of the license you choose and this code will be public. If you need to keep your code or any part of it confidential, do not contribute.

Your applet must be compliant with standard Java 1.5 (any older Java version is automatically compliant). It must not require any particular version of Java runtime and must not require any specific runtime library packages outside org.*, java.* and javax.* domains. Non standard sun.* and similar packages are normally blocked during server side compilation.

To get your applet approved quickly, it makes sense to show some respect to reviewers. Here are some most important rules on how to prepare the code:

• Always place classes into packages (do not use default package). The package name must start from lowercase.
• Use one file per class (except inner classes).
• Name classes properly (start from capital letter, no underscores). There is a good Wikihow article on that.
• At least class header must contain the explaining comment. The more comments the better.
• Do not use star imports like import java.awt.*. Explicit imports allows reviewer to see immediately which system classes are used. Most of the recent IDEs can organize imports for you.
• Format your code to have a good style. Most of the recent IDEs contain a built in code beautifier.
• Sort class members in the following order: inner classes, fields, constructors, all other methods.
• Specify your license, whatever it is, at the beginning of at least one file (as comment). There are lots of good applets on the web that we cannot use because we do not know licensing conditions neither we can contact the author.

Also, we recommend to build user interfaces manually, without using fancy GUI designers. There are two important reasons for that:

• The code, produced by GUI designer software, is often near unreadable for human being. This unreadable code still must be checked by reviewers.
• Different designers usually cannot read each others code and you cannot assume that everybody will use exactly your tool to work with your applet in the future. It is especially nasty when they start adding they own proprietary classes like layout managers: such class must be rewritten before it is usable outside your builder.

Valuable contributions (especially old code) can be accepted also if it does not match these rules. We are limited in resources but for a good reason we do the cleanup themselves. However if you write a new code, please try to follow them. Valuable contributions on that you have no longer time to work may be processed and fixed by our team if you put them into the Rescue page.

[Edit]Contributing derived versions of existing projects

See also Terms of use

Please always clearly specify when your work is derived from some other work the is already inside Ultrastudio.org . There are two important reasons for that:

• With Ultrastudio.org built-in code difference tool, reviewers can only check changes and not the whole project again. This makes reviewing fast and trivial, also encourages multiple small changes.
• If you specify the previous version, we believe that you are only liable for consequences, caused by the changes you have made. Well, you should likely be liable only for your changes anyway but that way is much easier to prove.

When producing derived work, please do not format existing code without the real need. This will produce many tiny non significant differences that are difficult to track.

We recommend to contribute the derived work under the same license as the original work. If you choose a different license, it is your responsibility to make sure that the licenses are compatible. Upload system should reject clearly incompatible changes (like GPL to BSD) but it works without warranty of any kind. If your decision about license compatibility is based on some reliable source, please put this reference into upload comment.

[Edit]ZIP internal structure

All code uploaded through submission form must be packaged into one .zip archive. Inside this archive, the class files must be placed into folders accordingly to they packages. This is a typical structure of the java project that most of the recent developing tools would enforce.

If the archive structure is broken (like having src folder at the top of all packages), the Ultrastudio.org build system will try to fix it for you. Depending on how much chaos have you introduced this may or may not work so it may be better care about the correct structure before upload.

[Edit]Resources

Build system also accepts plain text resources and images. Do not rely on exact passing of your images on binary level as the image processor will load and save them again during the check procedure. Text files must be UTF-8 compliant. Please place them next to the .java class files that references them, not into separate folder. Please do not add your custom manifest as it will be discarded anyway. Please do not add any binary files other than images - this will force automatic rejection at the early stages of submission. Access resources from your code in the following way: InputStream resource = getClass().getResourceAsStream("/images/mybuble.png"). Do not try to load them directly from the web.

[Edit]Building scripts

Currently we do not support Ant, Maven, Make or any other custom build scripts nor we plan to support them in the future. Allowing this would complicate the security requirements of the Ultrastudio.org build system. Masters of these tools can use them to produce a custom source archive, ready to upload into Ultrastudio.org .

[Edit]Signed applets

As an extra security feature, recompilation on a server side drops your .jar signatures, if any. All applets in this portal run with the lowest possible permissions of the unsigned code.