Community
Participate
Working Groups
in EDT, if I create a basic EGL Project, and uses java generator, there is no java runtime included for me. I have to check out the java.runtime project from eclipse cvs and set the java build path to depends on the runtime project. We need to configure this for the end user automatically, like in RBD, we have the equivalent of fda7.jar, which is set on user's project java build path automatically upon creation or generation.
Jing, I can't reproduce this. When Java is generated, a library called "Java runtime" is added to the project's Java build path. That's not an EGL library, it's a Java classpath library. You can also add it manually on the Java build path properties page. Go to the Libraries tab and click Add Library. The one you want is EDT Runtime. What we *do* need is a way for people to get a jar containing the runtime, so people can run generated code outside of the workbench.
Try running this program program tester type BasicProgram {} today date; function main() syslib.writestdout("Hey " + today); end end Fails when I don't explicitly add org.eclipse.edt.runtime.java to my Java Build Path Projects
I posed a similar-ish question related to when the user creates a new EGL project, selects the Basic template, and picks the JavaScript generator: do we just configure the project to use the JavaScript generator OR should we do additional configuration to the project (e.g. create a WebContent folder, etc). I think not. It does seem like there needs to be some type of configuration that happens on a project when a generator is associated with it -- and it seems this should be controlled by whatever actually contributed the generator into the IDE. This way, whenever a generator is associated with a project (whether when it's created or via the Properties dialog later, the project is properly configured).
I made a new project in a new workspace and put Kathy's program into it. No problems. Are there any error messages in your log?
Nothing in the log file. Console content: Exception in thread "main" java.lang.NoClassDefFoundError: com/ibm/icu/util/Calendar at org.eclipse.edt.runtime.java.egl.lang.EDate.defaultValue(EDate.java:65) at example.tester.ezeInitialize(tester.java:28) at example.tester.<init>(tester.java:25) at example.tester.main(tester.java:20) Caused by: java.lang.ClassNotFoundException: com.ibm.icu.util.Calendar at java.net.URLClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClassInternal(Unknown Source) ... 4 more
I do see the same problem when I run the code. I didn't try running until now because the initial bug report says the runtime is missing and it didn't include that error message. You actually do have the runtime. What's missing is the ICU4J library, which the Java runtime depends on. You can work around this by manually adding the ICU4J jar to your project's Java build path. On the Libraries tab, click Add External Jars, and go to the eclipse\plugins\ directory of your Eclipse installation. Pick the jar named com.ibm.icu_4.2.1v20100412.jar. If you have a different version of Eclipse than me, the numbers in the jar's name will be different. That's OK.
I think the point of this defect to say we need to do something in our configuration so that end user doesn't have to do any manual configuration in order to execute the generated java. for now, we use the manual steps I described initially to get by. I agree with Will's post, I think whenever the generator is chosen, we should setup the runtime configuration as well (both java and javascript, whatever that might be)
I agree.
Can we come up with a more descriptive name for "fda7.jar"? Maybe "egljavart.jar"? What does "fda" stand for anyway?
I agree with you Will. We'll be sure to give it a decent name. FDA was the three-letter product code for the Java runtime in VAGen. A handful of other jar files and classes in RBD still have names based on those codes (CSO, HPT, WGS).
Figuring out how/if to include ICU4J will be part of this work. Users might have to download it separately.
*** Bug 355440 has been marked as a duplicate of this bug. ***
Decisions! 1. We'll produce a runtime jar during the build which contains the Java runtime and ICU4J. The name of the jar will be egljavart.jar. 2. The runtime jar will be added to the Java Build Path of EGL projects, instead of the runtime plugin which is what you get at the moment. The runtime plugin doesn't give you ICU4J. 3. The runtime jar can be exported by users so they can compile and run code outside of Eclipse. 4. For extensibility, the name and location of the runtime jar has to be something specified by the generator. This is an enhancement for a future release, captured in Bug 356357 - Need a way to specify the Java runtime jar.
*** Bug 356410 has been marked as a duplicate of this bug. ***
I'm going to revise the decisions from comment 13. 1. The runtime jar will be the runtime plugin jar itself (org.eclipse.edt.runtime.java_0000000.jar). We'll insert the ICU4J classes during the build. The previous idea called for a separate jar to be created, but users needing it outside of Eclipse would be forced to dig it out from inside the plugin. That's too awkward. 2. The runtime jar will be added to the Java Build Path of EGL projects. Developers who have org.eclipse.edt.runtime.java in their local workspace will have to manually add the ICU4J jar to the Java Build Path, because those classes aren't stored in CVS. 3. The enhancement in Bug 356357 still applies.
It looks like ICU4J was successfully inserted into the runtime plugin during the most recent build. The date/time stuff should work now without any additional setup for people with EDT installed.
Closing all JavaGen enhancements that are in the Resolved state.
