Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 158614 - Code Templates don't work
Summary: Code Templates don't work
Alias: None
Product: Fedora
Classification: Fedora
Component: eclipse
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: eclipse-bugs
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-05-24 01:59 UTC by Ben Konrath
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-06-06 15:04:54 UTC

Attachments (Terms of Use)
stack trace (deleted)
2005-05-24 02:00 UTC, Ben Konrath
no flags Details
log file from when I try to create a new java class (deleted)
2005-05-24 16:59 UTC, Andrew Overholt
no flags Details
xml that causes errors (deleted)
2005-05-25 04:32 UTC, Ben Konrath
no flags Details

Description Ben Konrath 2005-05-24 01:59:43 UTC


Steps To Reproduce:

* go to "Window -> Preferences -> Java -> Code Style -> Code Templates"
* notice the Code Templates window does not display
* the attached stack trace will be in your log file

This is not a miscompilation because I had the same error when I moved
classmap.db out of the way.

Comment 1 Ben Konrath 2005-05-24 02:00:37 UTC
Created attachment 114759 [details]
stack trace

Comment 2 Andrew Overholt 2005-05-24 16:59:21 UTC
Created attachment 114787 [details]
log file from when I try to create a new java class

Comment 3 Ben Konrath 2005-05-25 04:32:27 UTC
Created attachment 114813 [details]
xml that causes errors

I printed out the URL to the xml before the call to, java.util.ResourceBundle): 

URL bundleentry://98/templates/default-templates.xml

Using the osgi console I was able to determine that bundle 98 is cdt.ui so the
xml that is causes the problem is
org.eclipse.cdt.ui_3.0.0/templates/default-templates.xml. I attached it for

Comment 4 Ben Konrath 2005-05-25 04:48:21 UTC
Moving org.eclipse.cdt.ui_3.0.0/templates/default-templates.xml out of the way
is a temporary solution:

pushd /usr/share/eclipse/plugins/org.eclipse.cdt.ui_3.0.0/templates/
mv default-templates.xml{,.bak}

Comment 5 Andrew Overholt 2005-05-25 13:21:55 UTC
This does indeed fix the problem for me.  If we can't figure out what's causing
the failure with GNU XML, we can always disable the CDT code templates.

Comment 6 Andrew Overholt 2005-05-25 17:50:51 UTC
I'm confused as to why the CDT template xml fails when the JDT one does not:

<template name="for" description="for loop"
id="org.eclipse.cdt.ui.text.templates.c.for" enabled="true">for (${var} = 0;
${var} &lt; ${max}; ++${var}) {

unzip /usr/share/eclipse/plugins/org.eclipse.jdt.ui_3.1.0.jar \ 
<template name="for" description="%Templates.for_array"
id="org.eclipse.jdt.ui.templates.for_array" context="java" enabled="true">for
(int ${index} = 0; ${index} &lt; ${array}.length; ${index}++) {

What's different that causes the failure when the CDT one is enabled?

Comment 7 Tom Tromey 2005-05-25 19:24:29 UTC
I have a simple test program to parse this xml using dom.
I got it here:

This works with the jdk but fails with gij.

One workaround is to replace the failing entity references with hex equivalents

&quot;  =>  &#x22;
&gt;  =>  &#x3e;
&lt;  =>  &#x3c;

However, there is code in aelfred2 that looks like this is intended to work
as-is.  I'm going to poke at it a bit more.  If I can't make it work I will
forward to Chris Burdess for consideration.

Comment 8 Tom Tromey 2005-05-25 19:26:14 UTC
Both of the files in comment #6 work fine with my test program.
The one in the attachment does not however.

Comment 9 Tom Tromey 2005-05-25 20:08:28 UTC
This was fixed in classpath by this patch:

2005-05-14  Chris Burdess  <>
	* gnu/xml/dom/ls/ Ignore XML entities in start/
	end entity callbacks.

I am checking this in to gcc 4.0 and trunk.
This patch makes my test program work on the data with which it failed earlier.

Comment 10 Andrew Overholt 2005-06-06 15:04:54 UTC
This has been fixed in gcc*4.0.0-9.

Note You need to log in before you can comment on or make changes to this bug.