Community
Participate
Working Groups
This needs to be addressed asap; as a first step identify if there is no other way to provide the current functionality Next open a request against jdt and explain exactly your scenario and why you need this functionality to be made available as API. The solution may be that you can refactor the code and have the same function using existing jdt API or there is indeed a need for new API. plugins/org.eclipse.tptp.platform.models/src-fastxpath-common/org/eclipse/tptp/platform/provisional/fastxpath/compiler/EclipseCompiler.java: 25:import org.eclipse.core.runtime.internal.stats.ClassloaderStats; 28:import org.eclipse.jdt.internal.compiler.ClassFile; 29:import org.eclipse.jdt.internal.compiler.CompilationResult; 30:import org.eclipse.jdt.internal.compiler.Compiler; 31:import org.eclipse.jdt.internal.compiler.DefaultErrorHandlingPolicies; 32:import org.eclipse.jdt.internal.compiler.ICompilerRequestor; 33:import org.eclipse.jdt.internal.compiler.IErrorHandlingPolicy; 34:import org.eclipse.jdt.internal.compiler.IProblemFactory; 35:import org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader; 36:import org.eclipse.jdt.internal.compiler.env.ICompilationUnit; 37:import org.eclipse.jdt.internal.compiler.env.INameEnvironment; 38:import org.eclipse.jdt.internal.compiler.env.NameEnvironmentAnswer; 39:import org.eclipse.jdt.internal.compiler.problem.DefaultProblemFactory; 267:} catch (org.eclipse.jdt.internal.compiler.classfmt.ClassFormatException exc)
Target to 4.4. As a primary investigation, there is no other way to provide the functionality without using the internal APIs.
This has to be addressed in 4.4 as a blocking issue; Any API violation can result in being refused to release by the Eclipse foundation Other than the defect being opened, which is a good start, I don't see any other comment showing that this is under investigation and that a plan is in place on how to solve the problem If this is the only approach then there should be a high priority request opened against JDT and a follow up discussion with this team. Moving to Marius since he is the model owner and the initial committer for the fastXPath code
Initial investigation set to 80 hours, the actual implementation could be covered by this also. One way would be to use an approach similar with that used by JET builder, on top of a hidden project named for example .XPathCompiledExpressions. The right way would be to compile in memory, although that will require more time to investigate and implement.
Fix in CVS. Currently there is no compiler implementation in TPTP (I removed the EclipseCompiler class that was implemented using internal JDT code), a user of this function could still create a compiler and use it by setting org.eclipse.tptp.platform.provisional.fastxpath.compiler.ICompilerHelper.COMPILER with the fully qualified class name of the compiler class. I will use bug 138213 to implement a builder that will provide the equivalent function that has been provided by the removed EclipseCompiler class. I also changed the implementation of org.eclipse.tptp.platform.provisional.fastxpath.IFastXPathEngine.getExpressionJavaSource in a way that will provide a valid Java source without using the FastXPath compiler code. That method can be used to generate the corresponding Java source to evaluate an XPath expression.
As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since this enhancement/defect has been resolved and unverified for more than 1 year and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open.
