Community
Participate
Working Groups
VE may use the JDT compiler to compile (EMF) JavaJet templates on the fly. The compiled templates are than used by VE to generate code. The .class, and .java files are not in any workspace project, and these artifacts are placed in the VE plugin's metadata. All the JDT compiler API today are internal.
I think this will be done when the jsr199 will be publicly available.
*** This bug has been marked as a duplicate of 81471 ***
Gili, How much do you exactly need there ? The JSR-199 will likely require JRE 1.6 classlibs, and is not going to be a happy scenario for you I guess. Are you trying to perform validation on the fly ? If so, is that much different from JSP validation done by WTP in essence ? If not, then I believe you should use a similar approach, which is entirely based on our public API; e.g. you can compile a file in memory using workingCopy and reconcile operation.
It has been a while since I have been in this area of the code; it might be that there is a better way to do this in 3.1. In essence here is the problem I am solving: I have a .javajet file.... it is similar (content/semantic) to a .jsp file. This file will be (EMF JavaJet) translated to a .java file. The .java file will be then compiled to a .class and loaded. The loaded class is a CodeGen template that VE uses to generate code. Upfront, these .javajets are compiled. Bug, when the .javajet is modified (user customization), VE will reTranslate/Compile and load the new CodeGen template on the fly. The .javajet/.java/.class are not in any IProject; they are all stored in the VE's .metadata area. The following is the snippet of code that I using today; it is internal, and I would like to stop using it this way. Is there any other way to solve this problem, or is there any support that you can provide so that I can use formal API. EmitterCompilationUnit[] cu = new EmitterCompilationUnit[] { new EmitterCompilationUnit()}; INameEnvironment env = new FileSystem(classPath, new String[0], fEncodeing); tick(pm); IErrorHandlingPolicy errorPolicy = DefaultErrorHandlingPolicies.exitOnFirstError(); IProblemFactory problemFactory = org.eclipse.jdt.internal.core.builder.ProblemFactory.getProblemFactory(java.util.Locale.getDefault()); EmiterCompilerRequestor requestor = new EmiterCompilerRequestor(); org.eclipse.jdt.internal.compiler.Compiler cmp = new org.eclipse.jdt.internal.compiler.Compiler(env, errorPolicy, JavaCore.getOptions(), requestor, problemFactory); tick(pm); cmp.compile(cu); if (requestor.getErrCount() > 0) throw new TemplatesException("SyntaxError: " + requestor.getProblems()[0].getMessage()); //$NON-NLS-1$ tick(pm); env.cleanup();
Couldn't you contribute a builder for producing the .java file simply ? Then the Java builder will consume it and produce the .class files.
Alternatively, could you wait until we implement JSR199 which will require a 1.6 JRE ? (i.e. likely to be addressed LATER).
... creating a meta .java file and push it onto a user's a project, drive a build, and snatch the .class, and clean up is kind of heavy (not to mention the hack factor ;-). VE is not going to be using JRE1.6 for a while.
Ok, but can you remain on the internal API until we come up with jsr199 implementation ? I am reluctant to add an API which is soon going to be obsoleted by jsr199. If we end up with 2 APIs to maintain it is overkill.
Gili - do you agree to wait until we provide a compiler API based on JSR199 ? In the meantime, you can stay on internal side, it is not changing much anyway at this level.
Sure thing, assume that the internals will not change much and be there until we get to JSR199.
Ok, then it is really a dup of bug 81471.
FYI, here is a note I just posted on jdt-dev-core mailing list, pls respond there. ============================ If you are NOT using compiler internal API IProblemFactory, then you may ignore this note. The current definition of IProblemFactory says that #createProblem(...) is answering org.eclipse.jdt.core.compiler.IProblem. We would like to change this into org.eclipse.jdt.core.compiler.CategorizedProblem CategorizedProblem is an extension of IProblem introduced in 3.2, which offers possibility to categorize problems better and have participant issue their own problems in a non colliding fashion (i.e. no longer need to worry about colliding problem IDs). Since IProblemFactory is not public API, this is not a breaking change; but they are a few users of our batch compiler technology out there, and we would like them to speak up if they want to veto this change. If we do not perform the change, then we internally need to swallow arbitrary IProblem and CategorizedProblem, which is causing unnecessary pain. NOTE: if you are simply using: org.eclipse.jdt.internal.compiler.problem.DefaultProblemFactory then no change is required, since it will get leveraged for free. This is what IProblemFactory would look like after the change: package org.eclipse.jdt.internal.compiler; import java.util.Locale; import org.eclipse.jdt.core.compiler.*; public interface IProblemFactory { CategorizedProblem createProblem( char[] originatingFileName, int problemId, String[] problemArguments, String[] messageArguments, // shorter versions of the problemArguments int severity, int startPosition, int endPosition, int lineNumber); Locale getLocale(); String getLocalizedMessage(int problemId, String[] messageArguments);
