This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 141539 - [65cat] No way to create simple Applet deployment
Summary: [65cat] No way to create simple Applet deployment
Status: NEW
Alias: None
Product: obsolete
Classification: Unclassified
Component: applet (show other bugs)
Version: 6.x
Hardware: All All
: P1 blocker with 1 vote (vote)
Assignee: issues@obsolete
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-07-24 13:37 UTC by wobster
Modified: 2010-03-16 13:47 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description wobster 2008-07-24 13:37:05 UTC
I created an applet in NetBeans 6.5 (recent nightly build) and tried to create the web-deployed distribution. I did not
see any option for generating just a simple applet HTML form and deployment. It only supported the 1.6_r10 JNLP
deployment it seems. Please include an option to generate the simple backward compatible applet HTML form and optionally
run the HtmlConverter program on that to generate the various browser-compatible HTML.
Comment 1 wobster 2008-11-23 15:13:09 UTC
I also noticed that there is no way to even run a standard applet now; NetBeans is only looking for main classes. This
is a regression of functionality. NetBeans used to be much more applet-friendly. I would like to see much better support
for applets in the future, especially with all the effort that has been made in JDK 1.6_10 to make applets more viable.
Comment 2 wobster 2009-12-01 19:39:35 UTC
It appears that the Java Webstart implementation works, but the applet viewer is not available any longer. 

I realize that the Webstart approach is the preferred approach, but there are shortcomings with the current JNLP implementation as well compared the applet tags such as not being able to specify widths of 100% so that the embedded applet will stretch automatically to the browser width and it doesn't appear to allow individual property files for instance to be downloaded without putting them in jar files.

It would be prudent to ensure that the new paradigm can do everything the old paradigm does before removing that functionality I would think.
Comment 3 Jesse Glick 2009-12-02 08:35:24 UTC
[Should still be Version=6.5; submitted bug #177998 requesting that this be readded.]

The shortcomings in the 6u10+ applet support should be filed on bugs.sun.com (feel free to add links here).

As to resurrecting full applet support in NB, I doubt this will happen from the core NB team - just not enough demand to justify the work relative to other things - but this could probably be done as an add-on module by interested parties.
Comment 4 wobster 2010-03-16 01:43:31 UTC
Why not? It is complete shame that previous functionality for something as important as applet support is gone now. It is no wonder people continue to steer away from applets and gravitate towards less capable web technologies when even the company that invented applets has "first-class citizen" support for them?

And the last time I checked the NetBeans team was part of Sun/Oracle. Why aren't you all advocating internally for better support and capabilities when you see deficiencies?

If anything, this should be a regression not an enhancement!
Comment 5 wobster 2010-03-16 01:52:12 UTC
(In reply to comment #4)
> It is no wonder people continue to
> steer away from applets and gravitate towards less capable web technologies
> when even the company that invented applets has "first-class citizen" support
> for them?

I noticed a typo in the previous comment:

It is no wonder people continue to
steer away from applets and gravitate towards less capable web technologies
when even the company that invented applets does not have "first-class citizen" support in the tools for them!
Comment 6 Tomas Zezula 2010-03-16 08:48:22 UTC
1) The applet tag (appletviewer) is deprecated, the applet should be deployed by the deployJava script which checks JDK version and uses either JNLP file (preferred way) or delegates <object> element for legacy JDK. This is done by the WebStart support.
2) The applet cannot be executed from the IDE - can be executed using run single in appletviewer, but I agree this is not enough. The IDE should be able to run (debug) the applet using JNLP as appletviewer do not provide all the needed features (jnlp api). This should be fixed, the jnlp build script contains targets to debug (run) the jnlp app but the problem is in the J2SEActionProvider which do not support to run project with Applet set as a main class. This should be fixed.
Comment 7 wobster 2010-03-16 13:47:34 UTC
The appletviewer is still useful when using the old style applet tags. There are a couple of reasons to still use the original tags:

1.) There are instances where users have to use an old version of Firefox on Linux due to some inflexibility of updating the OS from an old version

2.) The new JNLP-based approach does not support width and heights specified as a percentage of the page dimensions such as width=100%. They have to be hard-coded to a fixed size. Thus the new-style applet will not resize with the page. (At least, I haven't seen a way to do this so far. Perhaps some type of Javascript-based resize listener could be used that creates a window resize event to happen in the applet via a Javascript/Java call, but I don't know if that'd work and it is much more effort from the developer side than the simple percentage based tags. I will submit a bug on this if it doesn't exist already.)

3.) It gave developers an easy way to test the applet from within NetBeans. 

4.) From a cross-browser standpoint, I've had better luck with the applet tags than with the object tags. In fact, the mess that the HtmlGenerator spits out for cross-browser support seemed to confuse the browsers, especially when moving from Windows to Linux.

Thanks for acknowledging the problem and having a fix for the new-style applet tags.