Community
Participate
Working Groups
After installing the plugin eZing Builder (http://sourceforge.net/projects/ezingbuilder), I couldn't open the editor. I always got "ClassNotFoundException". The root cause was that I was running Eclipse with Java 1.4 but the plugin contains classes which are compiled against Java 1.5. I'd like to see two enhancements: - When a plugin contains classes which require Java 1.5, the builder in PDE should disallow to export it without the necessary Execution Environment. - When the classloader can't load a class because it requires a different Java runtime, it should say so (instead of "The editor class could not be instantiated. This usually indicates that the editor's class name was mistyped in plugin.xml."). This second enhancement is probably part of Equinox: java.lang.ClassNotFoundException: com.neusoft.ezingbuilder.designer.editors.HtmlFckDesignerMultiPageEditor at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:407) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:352) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83) at java.lang.ClassLoader.loadClass(Unknown Source)
This type of error would not happen if the author of the plug-in you are using had specified the required execution environment (see http://wiki.eclipse.org/index.php/Execution_Environments and http://lenettoyeur-on-eclipse.blogspot.com/2006/07/setting-bundle-requiredexecutionenviro.html) You should open a bug against the author of the component. Moving to the UI team to see if they can report a better problem. Note that this could tie in with the serviceability solution.
> if the author of the plug-in you are using > had specified the required execution environment Yes, you are correct but the same would happen if I accidentially added a JAR, which was compiled with Java 1.5 for some reason, to a plugin. As long as I run Eclipse with Java 1.5, I wouldn't notice. Therefore my request that PDE should check for these kinds of errors and complain when someone tries to export such a broken plugin.
>Therefore my request that PDE should check for these kinds of errors and >complain when someone tries to export such a broken plugin. Not sure what you mean by "checking for such errors". The plug-in is not broken. If it were, the export would fail. The plug-in just does not specify an execution environment. No need for PDE to interfere here. an execution environment is useful/recommended, but it is optional, and not having it is not an error.
If the behaviour you see at runtime (ie. the classloading error) is mystifying, then I suggest you reopen and move the bug to Equinox for better error reporting.
As it is now, Eclipse requires Java 1.4, so plugins cannot expect to have Java 1.5. On the other hand, it's perfectly possible to create plugins which *require* Java 1.5 without an execution environment. From my point of view, that's like digging a hole and waiting for someone to fall into it. As Java 1.5 becomes more and more widespread, more and more plugins will break. So, as I said in my first comment, PDE should only allow to create plugins without exec env as long as they don't need features which are outside the default exec env (probably Java SDK 1.4). I'll create a second bug report for Equinox so we can keep these issues apart.
I see what you are saying, but PDE can't police the plug-ins and introspect the code in real time to make sure you have an EE defined if you are using a Java5 feature. Plus, your code may have a path that uses Java5 features, but that path may only get executed in very specific scenarios, so this plug-in would run just fine with 1.4 under normal circumstances. This is all very subjective. That is why PDE should remain out of the way, and it is up to the owner of the plug-in to specify the Execution Environment if one is needed.
Of course, there might be corner cases but generally, all class files in a JAR will have been compiled with the same Java version, so checking the bytecode version of just one file in every jar should be enough to generate a warning. Right now, many plugin developers are unaware that the issue even exists. As a user, I must manually check that the plugin will run even though Eclipse would provide the means. Maybe for 3.2.1, you could enforce the EE a bit more, ie. generate a warning when it's not set? This way, the person who should know (the developer) can make an educated guess instead of putting this issue on the shoulders of the users. Wasn't there a FindBugs-like thing for plugins? I thought I remembered something but I'm not sure.
As mentioned above, a missing EE header is not an error. However, it may be desirable by some teams/companies to enforce having it. So this seems like a reasonable request, and we already have a flag for EE validation in the plug-in compiler preferences. I'll reopen and rename the bug report to reflect the new focal point. This is certainly is not a 3.2.x issue though. It will be evaluated for 3.3 and it will depend on how much we want to enforce having an EE in manifests.
The real issue here still needs to be addressed at the platform level which is to give a good error message instead of a class not found exception. The warning at the PDE level is just a nice-to-have.
*** Bug 189580 has been marked as a duplicate of this bug. ***
*** Bug 189579 has been marked as a duplicate of this bug. ***
This is a fairly straightforward warning / quickfix Adam.
Chris, what did you have in mind for the recommended quickfix. The developer still needs to make an educated decision on the EE level they want to choose. Would the quickfix list all the valid EEs a developer can choose?
Simply a configurable problem marker (warning by default) that tells people that they don't have an EE set. The quickfix can simply set the EE header and let you autocomplete it (which you can do already). We could be smarter and even put down an initial EE as part of the quickfix based on your default JRE and its current perfect match EE.
Moving off PDE. Back to inbox.
Hi guys, i'll take pick this one up again if no one minds.
Hi Gary, we love contributors ;) I'm assigning it to you. Once you're done, we will need a "leafy background" picture of you to put on our PDE hall-of-fame webpage (http://www.eclipse.org/pde/pde-ui/committers/committers.php). Let us know if you have any troubles or need help, we're here!
Here is a Mylyn context in your honor Gary ;)
Created attachment 78007 [details] mylyn/context/zip
Created attachment 78108 [details] patch
Setting up a depends relationship on adding the EE selection back the New Plug-in Project wizard.
btw Gary, the patch was beautiful, just need to wait on one more item because right now, what happens is when you create a new plug-in project you get a warning right off the bat since no EE is set. We need to make that not happen and that is done via bug 179213
Should i start looking into bug 179213 to resolve this?
Assigned it to you Gary. We will need a picture of you in a leafy background to go on our PDE hall of fame ;) http://www.eclipse.org/pde/pde-ui/committers/committers.php
moving to M3
thanks Gary, patch was pretty clean. I've created a TODO to refactor some of the code in the resolution to the VMHelper class to minimize redundancy.
Created attachment 79069 [details] mylyn/context/zip
Verified on I20071030-0010
will mark this noteworthy, part of the EE for the new plug-in project wizard
Stumbling over this warning in my Doc plugins. I'm wondering what the PDE team thinks would be a proper setting of Bundle-RequiredExecutionEnvironment if my bundle does not have anything executable (like my doc plugins)? I'm trying to keep exactly the same compiler settings for all my plugins, so I'd like to avoid having a different warning level in the doc plugins than the code plugins.
(In reply to comment #30) > Stumbling over this warning in my Doc plugins. Which version are Eclipse are you using? Are your doc plug-ins java projects by mistake? It's possible to be a Plug-in project without being a Java project.
Using I20080129-1400 It's got a PDE nature indeed although it's not a Java project -- guess the EE warning should be disabled in that case? Here is the .project file: <?xml version="1.0" encoding="UTF-8"?> <projectDescription> <name>org.eclipse.rse.doc.user</name> <comment></comment> <projects> </projects> <buildSpec> <buildCommand> <name>org.eclipse.pde.ManifestBuilder</name> <arguments> </arguments> </buildCommand> <buildCommand> <name>org.eclipse.pde.SchemaBuilder</name> <arguments> </arguments> </buildCommand> </buildSpec> <natures> <nature>org.eclipse.pde.PluginNature</nature> </natures> </projectDescription>
Brian and I can't see anything... can you try rebuilding the project...? I think it's a stale marker as there was a time when we had an issue with validating non-Java projects when we shoudln't have.
Right, the warnings were gone on a clean rebuild. Thanks for your help!
