🚀 go-pugleaf

Ruben-B. Reincke wrote:
> Hello everybody,
> 
> I'm trying to tell JBuilder 2005 Dev. Ed. (11.0.236.116) to truly compile
> against JDK 5.0 (1.5.0_06) resources,
> in particular use the updated "javax.xml.parsers.*" classes (from "rt.jar"
> provided therein: JDK 5.0 provides enhanced
> interfaces for XML processing, e. g. the DocumentBuilderFactory lets you
> create parsers that combine parsing and
> schema validation).  But it looks like the compiler is sort of stuck to the
> JDK 1.4 resources installed along
> with JBuilder.
> 
> Apparently, it is neither sufficient to set the project JDK accordingly, nor
> does it help to adjust the "compiler"
> settings in the project properties. (Playing around with the project class
> path settings didn't help either.)
> 
> Any helpful hints would be appreciated - thanks in advance!
> 
> Best regards,
> Ruben-B. Reincke
> 
> 

Did you:

1.  Set the Project JDK to be JDK 1.5?
2.  Try using the Project "javac" instead of "Borland Make"?

If you did, and you are still having problems, it would be useful to 
have a specific example of what goes wrong...

-- 

Regards,

Lori Olson [TeamB]

------------

Save yourself, and everyone else, some time and search the
newsgroups and the FAQ-O-Matic before posting your next
question.

Google Advanced Newsgroup Search
     http://www.google.ca/advanced_group_search
Other Newsgroup Searches:
     http://www.borland.com/newsgroups/ngsearch.html
Joi Ellis's FAQ-O-Matic:
     http://www.visi.com/~gyles19/fom-serve/cache/1.html

First of all thank you, Lori,  for responding!

I finally figured out the reason for this problem myself: It turned out not
to be any sophisticated compiler configuration issue, but rather a question
of the structure of the compiler class path: Whilst compiling,  JBuilder2005
obviously searches additional libraries assigned to a particular project
*before* it searches the project JDK resources, such as "rt.jar" of JDK1.5.
In this particular case, outdated "javax.xml.parsers.*" resources were taken
from some FOP library (xml_apis_for_fop_0_20_5.jar) instead of using the
latest versions provided along with JDK 1.5.
This was most irritating because
(1) I know of no way to inspect the complete compiler class path which
JBuilder is actually using
(2) While the compiler reported some method invocation
"DocumentBuilderFactory.setSchema(.)" could not be resolved, browsing the
definition of DocumentBuilderFactory (using the IDE function provided in the
context menu) led to the class source code in "src.zip" (as distributed
along with JDK 1.5) where the method in question was properly defined.
(3) Building the same project using ANT (i. e. outside JBuilder) was no
problem at any time.

To me the bottom line is that, once again, we see the trade-off of
abstractions supplied by an IDE intended to ease development (such as
JBuilder's ability to graphically define compilation using a layer of
"libraries" instead of hard-coding a class path). While they help you to
retain the overview in some cases, they obscure things in others. In this
case, I would have benefited if I had had access to the actual compilation
class path (my solution was to create myself a helper to browse the runtime
class path for a regular name pattern and report all matches in the proper
order).

Best regards,

Ruben-B. Reincke

Ruben-B. Reincke wrote:
> First of all thank you, Lori,  for responding!
> 
> I finally figured out the reason for this problem myself: It turned out not

That's good.  And sorry for taking so long to respond.  I was just 
making a sweep to find messages that have not been answered, and found 
your post.  I thought I had answered it a couple of weeks ago.

> 
> To me the bottom line is that, once again, we see the trade-off of
> abstractions supplied by an IDE intended to ease development (such as
> JBuilder's ability to graphically define compilation using a layer of
> "libraries" instead of hard-coding a class path). While they help you to
> retain the overview in some cases, they obscure things in others. In this
> case, I would have benefited if I had had access to the actual compilation
> class path (my solution was to create myself a helper to browse the runtime
> class path for a regular name pattern and report all matches in the proper
> order).
> 

Well, you do have access to the actual compilation classpath.  If you go 
to your Project Properties and Select "Path", one of the available tabs 
is "Preview".  The preview tab lists the entire classpath that will be 
used to compile the project.

I think you have stumbled across a subtle bug here.  The code insight is 
being TOO smart, and finding a definition in the JDK jars, when there 
was an overriding definition in the classpath ahead of the JDK.

If you can come up with a small example of the issue, it would be worth 
reporting as a bug in QualityCentral.

-- 

Regards,

Lori Olson [TeamB]

------------

Save yourself, and everyone else, some time and search the
newsgroups and the FAQ-O-Matic before posting your next
question.

Google Advanced Newsgroup Search
     http://www.google.ca/advanced_group_search
Other Newsgroup Searches:
     http://www.borland.com/newsgroups/ngsearch.html
Joi Ellis's FAQ-O-Matic:
     http://www.visi.com/~gyles19/fom-serve/cache/1.html