Re: [general] creation of jdktools
Ilya, I'd like this idea. But I think having two tools.jar libraries (jdk/jre/lib/tools.jar and jdk/lib/tools.jar) may be quite confusing. It's convenient for JDK to have jdk/lib/tools.jar and many programs explicitly include it into CLASSPATH. I suggest renaming second tools.jar (going to JRE) to jretools.jar or something ike this, so we'll have jdk/jre/lib/jretools.jar jdk/lib/tools.jar which should be less confusing. Thanks. Ivan On 10/30/06, Ilya Neverov [EMAIL PROTECTED] wrote: Hello, I want to gather opinions about structure of the jdktools component. I'm going to create scripts for moving tools' sources from classlib/ to top-level directory jdktools/ and to prepare patches for build system for building tools from new place. I think the following structure will be appropriate for future evolution of the jdktools: jdktools/trunk/ build.xml make/ doc/ modules/ jre/ # keytool, tool launcher go here build.xml # classes go to jdk/jre/lib/tools.jar make/ src/ jdk/ # javac, jarsigner go here build.xml # classes go to jdk/lib/tools.jar make/ src/ jdwp/# separate module for large component build.xml make/ src/ Assumptions which look reasonable for jdktool's build subsystem: 1) it works in presence of built classlib (as HDK binaries or as a result of classlib phase of overall build); 2) the 'jre' module is always built before building 'jdk' to provide generic tool launcher and the jre/lib/tools.jar. Probably it will be easy to obtain these items from HDK. I'm rather newbie in the Harmony build system so your thoughts will be very helpful. Thank you -Ilya
Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)
On 10/12/06, Gregory Shimansky [EMAIL PROTECTED] wrote: BTW sun's hotspot should compile a method if it is called several times, so user defined class loader could do something like calling this method many times to trigger its compilation. AFAIK, it is possible to run Sun's Hotspot VM with option -Xcomp to force compilation of all methods. This should help in investigating RI behavior. Ivan - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Any JDWP/Eclipse experts out there?
Chris, You can find more info about error in the 'Error log' view (Windows-Show view-Error log). If you click on the corresponding error, you can see exception stack trace. This may give you some hints where this error occured or display JDWP error code and you can find description of this error in JDWP spec [1]. Thanks. Ivan [1] http://java.sun.com/j2se/1.5.0/docs/guide/jpda/jdwp/jdwp-protocol.html#JDWP_Error On 10/9/06, Chris Gray [EMAIL PROTECTED] wrote: Sorry for the noise, but I know there are some VM designers etc listening here. I'm trying to get JDWP working between the Wonka VM and Eclipse. I've reached the point where I can set a breakpoint and run the app until I hit it; Eclipse shows the correct stack frames and shows the correct mine in the edit window, but then throws up an error message 'An internal error occurred during Debug'. Now I'm wondering what to do next ... can anyone give me tips on how to get more debugging info out of Eclipse, documentation about how Eclipse uses JDWP, supplementary documentation on JDWP in general, etc.? Thanks for your time, Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where to put the tools.... (was Re: [vote] HARMONY-1410 : JDWP agent for DRLVM)
Yes, JDWP agent uses most of JVMTI functions, and testing JDWP level indirectly checks JVMTI implementation. JDWP unit tests included into JDWP contribution do not provide exhaustive testing, but they often catch problems with basic JVMTI support related to debug functionality. However, there is a number of JVMTI functions not used in JDWP agent. They are targeted for profiling support and will not be tested with JDWP tests. But they can be tested with any Java profiler, for example new JVMTI profiler in Eclipse TPTP project [1]. Their automation testing framework can be used for testing JVMTI profiling support in Harmony JRE. Ivan. [1] http://www.eclipse.org/tptp/ On 10/4/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Ivan Popov wrote: --- I'd like to see JDWP unit tests included into regular tests runs, they often reveal problems with JVMTI and JNI support when JVM implementation is changed. I'm not sure that unit tests are provided with other tools and included into tests run, and this can be a separate topic for discussion. Yah, I've been noting that in JVMTI commit messages - we need a suite of JVMTI tests, and I guess we can use the agent for it? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] DRLVM, jre/bin/default and launcher
J2SE documentation explicitely mention standard and non-standard but well-known option for 'java' tool in [1] and [2]. I think it makes sense to follow this description rather than help message, they are not equal. [1] http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/java.html [2] http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/java.html Ivan. On 10/4/06, Vladimir Ivanov [EMAIL PROTECTED] wrote: As we know the current IBM VM does not support all 'standard' java options. IBM VM peoples, could you give some expectation when this support will be available (1 month, 3 or 6 ...)? thanks, Vladimir The standard options from my point of view are (without deprecated): tmpjava Usage: java [-options] class [args...] (to execute a class) or java [-options] -jar jarfile [args...] (to execute a jar file) where options include: -client to select the client VM -server to select the server VM -hotspot is a synonym for the client VM [deprecated] The default VM is client. -cp class search path of directories and zip/jar files -classpath class search path of directories and zip/jar files A ; separated list of directories, JAR archives, and ZIP archives to search for class files. -Dname=value set a system property -verbose[:class|gc|jni] enable verbose output -version print product version and exit -version:value require the specified version to run -showversion print product version and continue -jre-restrict-search | -jre-no-restrict-search include/exclude user private JREs in the version search -? -help print this help message -Xprint help on non-standard options -ea[:packagename...|:classname] -enableassertions[:packagename...|:classname] enable assertions -da[:packagename...|:classname] -disableassertions[:packagename...|:classname] disable assertions -esa | -enablesystemassertions enable system assertions -dsa | -disablesystemassertions disable system assertions On 9/4/06, Oliver Deakin [EMAIL PROTECTED] wrote: Salikh Zakirov wrote: Andrey Chernyshev wrote: 1. Fix the DRLVM layout - rename vmcore to harmonyvm and move ..dll/.so into the default subdirectory such that one doesn't have to type -vm and -vmdir options; While would you want to rename DRLVM to Harmony VM? It feels to me like claiming DRLVM to be the only Harmony VM. On the contrary, I thought Harmony project is about *encouraging* diversity. I think having library named libdrlvm.so would be much better. The Harmony launcher looks for harmonyvm.dll as its default vm library. It's just a generic name so that the launcher can find the correct library without -vm. The IBM VME also contains a harmonyvm.dll, which is why it works without specifying command line options Regards, Oliver 2. Exclude building of the original launcher from the DRLVM build - it currently conflicts with the classlib launcher (both are called java). 3. Aside from the hythread, it may also have a sense to make the classlib and DRLVM using the same zlib dll/so (preferably the system one). - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] creation of jdktools
+1 from me too. I'd like idea of having separate directory for all tools going to JDK and including them into federal build. Ivan. On 10/4/06, Tim Ellison [EMAIL PROTECTED] wrote: +1 for creating a jdktools directory. The dependency on the classlib launcher should be relatively light if we go with a simple tools launcher that rewrites the tool invocation into a generic launcher invocation. You may recall the idea was discussed a while ago. So, for example, jdk/bin/javac -source 1.5 -J-Xmx200M FooBar is rewritten to jdk/jre/bin/java -cp jdk/lib/tools.jar;jdk/lib/ecj.jar -Xmx200M org.apache.harmony.tools.javac.Main -source 1.5 FooBar and so on. Regards, Tim Geir Magnusson Jr. wrote: Geir Magnusson Jr. wrote: Now that we have javac, javah, javap (if Tim votes ;) and keytool, I'd like to organize these and add them to the next snapshot. My bad - the javap isn't being voted on yet. I was thinking of the jdwp vote... sorry So I propose adding a new top-level directory called jdktools (and rename tools to project_tools) and create a build target that - with a dependency on classlib for the launcher - creates the 'stuff' needed to fill into the JDK. Any comments? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where to put the tools.... (was Re: [vote] HARMONY-1410 : JDWP agent for DRLVM)
Initially I considered putting JDWP agent to classlib as part of JPDA module, so its build is adjusted to the classlib build structure. But I agree that putting it to tools directory (or to jdktools as discussed in separate thread) should be better solution. JDWP agent is not an implementation of Java classes like classlib modules, it provides debug service for JRE and thus logically it is closer to tools, though it is not a true tool like javac, javap, rmic, etc., it's rather service. I suggest creating JPDA module in tools (or jdktools) directory and putting there the whole JDWP contribution that includes implementation of JDWP agent, TCP/IP socket transport, and JDWP unit tests. Creating JPDA module in tools for JDWP agent gives the following advantages: --- this follows logical structure of JPDA architecture that includes JDI, JDWP, JVMTI/DI/PI levels --- initially it will include JDWP implementation as a minimal support for debug service in Harmony JRE --- one day we can add here JDI implementation (main JPDA component currently provided by Eclipse JDT debugger) that is necessary in JDK for enabling other Java debuggers --- we can also add here implementation of profiling agent similar to what is included in other JDKs --- we can add here any other JPDA based tools and services which provide extended functionality --- tests for all JPDA components can share JPDA testing framework currently provided with JDWP tests that facilitates running two JVM instances (debugger/debuggee or profiler/profilee) I think you can put JDWP contribution to tools/jpda as is, it is proven to be built separately. AFAIK, currently there are no rules and runtime structure for building tools, each tool is built separately. I can then provide a patch for build.xml just to facilitate separate build according to the new location of JPDA module. But I think we need a discussion of how to include building tools into common build and what should be supported by their build scripts. Anyway, I volunteered for providing any support for quick integration of JDWP agent into Harmony sources and resolving all problems. Finally, I'd like to add several notes according to putting JDWP agent to tools: --- Unlike to other tools whose binaries usually go to JDK binaries directory, JDWP agent binary usually goes to JRE binaries directory. This enables debugging application running on JRE even if you have no JDK available, especially if you are debugging application remotely. --- I'd like to see JDWP unit tests included into regular tests runs, they often reveal problems with JVMTI and JNI support when JVM implementation is changed. I'm not sure that unit tests are provided with other tools and included into tests run, and this can be a separate topic for discussion. Thanks. Ivan On 9/28/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Keeping the discussion out of the vote thread. Both this and javah aren't going into classlib anyway. I was going to suggest we put them into /tools, bring the javac and keytool over, and I volunteer to do it. Then add that to the federated build, and get into the jdk. geir On Sep 28, 2006, at 8:07 AM, Ivan Popov wrote: Yes, build script for JDWP agent should be aligned with the current classlib build structure. It should be easy, because it is generally oriented to the classlib structure and requires just a few changes. I can provide patch for this. I tried to build JDWP agent as a separate classlib component and it was built successfully with some known problems mentioned in README. Thanks. Ivan - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] HARMONY-1410 : JDWP agent for DRLVM
Yes, build script for JDWP agent should be aligned with the current classlib build structure. It should be easy, because it is generally oriented to the classlib structure and requires just a few changes. I can provide patch for this. I tried to build JDWP agent as a separate classlib component and it was built successfully with some known problems mentioned in README. Thanks. Ivan On 9/28/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: +1, but it seems to me that its build is not aligned with the classlib build structure. Please, correct me if I am wrong. Have somebody tried to build it already? On 9/28/06, Alexey Varlamov [EMAIL PROTECTED] wrote: +1 2006/9/28, Paulex Yang [EMAIL PROTECTED]: +1 Geir Magnusson Jr. wrote: BCC and ACQs are in. What say ye? Would it be nice to debug using eclipse debugger in DRLVM? [ ] + 1 accept this contribution into the project [ ] -1 don't accept (please give reason) Vote runs usual 3 days unless protest or early completion. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DRLVM contribution - try this out!
On 5/6/06, Gregory Shimansky [EMAIL PROTECTED] wrote: I want to make a small addition to Vladimir's suggestion. Eclipse doesn't work after its configuration directory is erased completelty. You should keep config.ini file in it or eclipse won't start any more. You might also consider using option '-clean' in the Eclipse command line: -clean (OSGi) equivalent to setting osgi.clean to true osgi.clean if set to true, any cached data used by the OSGi framework and eclipse runtime will be wiped clean. This will clean the caches used to store bundle dependency resolution and eclipse extension registry data. Using this option will force eclipse to reinitialize these caches. Regards. Ivan Popov Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r394890 - in /incubator/harmony/enhanced/classlib/trunk/modules: applet/make/common/ archive/make/common/ auth/make/common/ awt/make/common/ beans/make/common/ crypto/make/common/ jndi
By default Eclipse uses its own Eclipse [built-in] formatter for Java code, which inserts tabs for indentations\. However, it's possible to configure it to use spaces, or just choose Java convetions [built-in] formatter, which uses spaces by default. Just go Window-Preferences-Java-Code Style-Formatter page, select desired formatter, press Show button and set appropriate indentation policy and tab size. I think there is no need for a special formatter. AFAIK, for XML sources Eclipse uses Ant editor by default, which also uses tabs for indentation. It is possible to configure it to use spaces, just go to Window-Preferences-Ant-Editor-Formatter page and uncheck box Use tab character insted of spaces. The problem might be that the new formatter settings will be applied only to the newly typed text. To apply it to existing sources one need to reformat text using Format or Correct indentation commands in editor view. Thanks. Ivan Popov Intel Middleware Products Division - On 4/19/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: What does a formatter profile do? (I tend to use IDEA more than Eclipse - comes from being a Mac user for so many years, where Eclipse was utterly unusable until recently...) I assume the same-ish as a code style in IDEA? In IDEA, by default use tabs is unchecked in the global code style of the project code style with a tab size of 4. (IOW, tab key turns into 4 chars...) geir Nathan Beyer wrote: For those who use Eclipse, this is fairly trivial to do with the Java editor. I've created a Formatter Profile (and tried to attach it), that can be imported and should setup this style of formatting. If you have the Web Tools, a similar format can be created for XML files as well. -Nathan -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 18, 2006 7:01 AM To: harmony-dev@incubator.apache.org Subject: Re: svn commit: r394890 - in /incubator/harmony/enhanced/classlib/trunk/modules: applet/make/common/ archive/make/common/ auth/make/common/ awt/make/common/ beans/make/common/ crypto/make/common/ jndi/make/common/ logging/make/common/ luni/make/commo Richard Liang wrote: Geir Magnusson Jr wrote: Wait - no tabs! no tabs! PLEASE! +1. But are there any way to release our pain from TABs? :-) Yes - most editors will convert tabs to spaces. I suppose if we agree on a no tabs rule, and find files w/ tabs, lets do a conversion, and check it in w/o any other mods, with the commit log entry of changing tabs to spaces or such geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
