Bug 158614 - Code Templates don't work
Code Templates don't work
Product: Fedora
Classification: Fedora
Component: eclipse (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: eclipse-bugs
Depends On:
  Show dependency treegraph
Reported: 2005-05-23 21:59 EDT by Ben Konrath
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-06-06 11:04:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
stack trace (10.06 KB, text/plain)
2005-05-23 22:00 EDT, Ben Konrath
no flags Details
log file from when I try to create a new java class (13.05 KB, text/plain)
2005-05-24 12:59 EDT, Andrew Overholt
no flags Details
xml that causes errors (5.01 KB, text/xml)
2005-05-25 00:32 EDT, Ben Konrath
no flags Details

  None (edit)
Description Ben Konrath 2005-05-23 21:59:43 EDT


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-23 22:00:37 EDT
Created attachment 114759 [details]
stack trace
Comment 2 Andrew Overholt 2005-05-24 12:59:21 EDT
Created attachment 114787 [details]
log file from when I try to create a new java class
Comment 3 Ben Konrath 2005-05-25 00:32:27 EDT
Created attachment 114813 [details]
xml that causes errors

I printed out the URL to the xml before the call to
TemplateReaderWriter.read(java.io.InputStream, 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 00:48:21 EDT
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 09:21:55 EDT
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 13:50:51 EDT
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 15:24:29 EDT
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 15:26:14 EDT
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 16:08:28 EDT
This was fixed in classpath by this patch:

2005-05-14  Chris Burdess  <dog@gnu.org>
	* gnu/xml/dom/ls/SAXEventSink.java: 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 11:04:54 EDT
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.