Re: Harmony on QNX
Hi Rodney I've just taken svn snapshot, built classlib, ran Eclipse on it (plus J9), open a number of files, made sync with repository. Do you like me to try some special scenario? Thanks, Mikhail 2006/5/30, Rodney Dowdall [EMAIL PROTECTED]: Hello I've been investigating the possible use of Harmony on QNX. We would like to use it, along with the QNX j9 VM, to run our self-hosted Eclipse based tools. I was looking through the code today and while it would be some work, I think the port should be relatively straightforward. What I am afraid of is that I would get the port done only to find that it cannot run Eclipse. The statement that leads me to believe that Harmony isn't mature enough to run a full blown Eclipse is the following from the Harmony website: This contribution is sufficient to run Ant and the Eclipse Java compiler, to provide a basic self-hosting environment. IBM also made a version of their J9 VM available http://www.ibm.com/developerworks/java/jdk/harmony for use by the project in evaluating this contribution. I realize this is a fairly old statement, but I would just like to know if Harmony would be able to accomplish what I am hoping it can. Thanks, Rodney - 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: Harmony on QNX
Mikhail and Rodney, I heard that Geir and Tim had demoed Eclipse with Harmony on JavaOne? Mikhail Loenko wrote: Hi Rodney I've just taken svn snapshot, built classlib, ran Eclipse on it (plus J9), open a number of files, made sync with repository. Do you like me to try some special scenario? Thanks, Mikhail 2006/5/30, Rodney Dowdall [EMAIL PROTECTED]: Hello I've been investigating the possible use of Harmony on QNX. We would like to use it, along with the QNX j9 VM, to run our self-hosted Eclipse based tools. I was looking through the code today and while it would be some work, I think the port should be relatively straightforward. What I am afraid of is that I would get the port done only to find that it cannot run Eclipse. The statement that leads me to believe that Harmony isn't mature enough to run a full blown Eclipse is the following from the Harmony website: This contribution is sufficient to run Ant and the Eclipse Java compiler, to provide a basic self-hosting environment. IBM also made a version of their J9 VM available http://www.ibm.com/developerworks/java/jdk/harmony for use by the project in evaluating this contribution. I realize this is a fairly old statement, but I would just like to know if Harmony would be able to accomplish what I am hoping it can. Thanks, Rodney - 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] -- 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]
Re: [jira] Closed: (HARMONY-455) java.util.Formatter.format() is not implemented
Mikhail, I think Richard is going to attach his next part of the fix, isn't he? If so, we should keep this issue open until he provides the whole fix, that is, all its parts. On 5/30/06, Mikhail Loenko (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/HARMONY-455?page=all ] Mikhail Loenko closed HARMONY-455: -- verified by Richard java.util.Formatter.format() is not implemented --- -- Dmitry M. Kononov Intel Managed Runtime 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: Harmony on QNX
I also saw Tim do a demo of Eclipse running on Harmony at EclipseCon '06, so it seemed in pretty good shape. However, that was running the JDT; whilst the CDT is likely to be in similar position, you might find that one or two APIs are needed for CDT but not JDT :-) Having said that, the fixes in the API are likely to be minimal if any, and exercising the build against more tools is a good way of finding where the holes are :-) Alex. On 30/05/06, Paulex Yang [EMAIL PROTECTED] wrote: Mikhail and Rodney, I heard that Geir and Tim had demoed Eclipse with Harmony on JavaOne? Mikhail Loenko wrote: Hi Rodney I've just taken svn snapshot, built classlib, ran Eclipse on it (plus J9), open a number of files, made sync with repository. Do you like me to try some special scenario? Thanks, Mikhail 2006/5/30, Rodney Dowdall [EMAIL PROTECTED]: Hello I've been investigating the possible use of Harmony on QNX. We would like to use it, along with the QNX j9 VM, to run our self-hosted Eclipse based tools. I was looking through the code today and while it would be some work, I think the port should be relatively straightforward. What I am afraid of is that I would get the port done only to find that it cannot run Eclipse. The statement that leads me to believe that Harmony isn't mature enough to run a full blown Eclipse is the following from the Harmony website: This contribution is sufficient to run Ant and the Eclipse Java compiler, to provide a basic self-hosting environment. IBM also made a version of their J9 VM available http://www.ibm.com/developerworks/java/jdk/harmony for use by the project in evaluating this contribution. I realize this is a fairly old statement, but I would just like to know if Harmony would be able to accomplish what I am hoping it can. Thanks, Rodney - 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] -- 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]
Re: [jira] Closed: (HARMONY-455) java.util.Formatter.format() is not implemented
Dmitry, I'll go on attach the following parts soon, it doesn't matter if this one is closed, I'll raise another JIRA if necessary. Dmitry M. Kononov wrote: Mikhail, I think Richard is going to attach his next part of the fix, isn't he? If so, we should keep this issue open until he provides the whole fix, that is, all its parts. On 5/30/06, Mikhail Loenko (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/HARMONY-455?page=all ] Mikhail Loenko closed HARMONY-455: -- verified by Richard java.util.Formatter.format() is not implemented --- -- 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]
Re: Harmony on QNX
On the 0x179 day of Apache Harmony Rodney Dowdall wrote: Hello I've been investigating the possible use of Harmony on QNX. We would like to use it, along with the QNX j9 VM, to run our self-hosted Eclipse based tools. I was looking through the code today and while it would be some work, I think the port should be relatively straightforward. What I am afraid of is that I would get the port done only to find that it cannot run Eclipse. The statement that leads me to believe that Harmony isn't mature enough to run a full blown Eclipse is the following from the Harmony website: This contribution is sufficient to run Ant and the Eclipse Java compiler, to provide a basic self-hosting environment. IBM also made a version of their J9 VM available http://www.ibm.com/developerworks/java/jdk/harmony for use by the project in evaluating this contribution. I realize this is a fairly old statement, but I would just like to know if Harmony would be able to accomplish what I am hoping it can. which version of Eclipse did you try? does modern Eclipse (3.1.x) run on QNX at all? they say: ...But Eclipse has dropped support for QNX becauee QNX doesn't support the Java engine that newer versions of Eclipse need. http://developers.slashdot.org/comments.pl?sid=96011cid=8234728 Actually, I did not run any single application on QNX, sorry :) -- Egor Pasko, Intel Managed Runtime 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: Ant build | IOException
2006/5/30, Nathan Beyer [EMAIL PROTECTED]: but based on the missing tools.jar error, I would suggest getting either the Sun or BEA JDK (the JRE isn't enough) for Linux to run Ant with for the build. This warning simply means that ant can not find tools.jar which contains javac by default. But you can use any java compiler you like. Eclipse compiler for example. Please refer ant documentation: http://ant.apache.org/manual/CoreTasks/javac.html So you do not really need SUN or BEA JDK to build Harmony. As for running the build, I believe the best practice is to be in the classlib root folder Harmony build works OK from make directory. From: Anoop kumar V [mailto:[EMAIL PROTECTED] Sent: Monday, May 29, 2006 9:37 PM To: harmony-dev@incubator.apache.org Subject: Ant build | IOException Hi, I am a n00b wanting to contribute to Harmony. All I have done so far (code-wise) is checkout the harmony code (revision 410710) from svn and run ant from ~/Harmony/make folder. But I am running into errors: I am using GCJ on Ubuntu5.10. [EMAIL PROTECTED]:~/Harmony/make$ ant Unable to locate tools.jar. Expected to find it in /usr/lib/jvm/java- 1.4.2-gcj-4.0-1.4.2.0/lib/tools.jar Buildfile: build.xml clean: clean-bin: [delete] /home/anoop/Harmony/build not found. clean: clean-layout: [delete] /home/anoop/Harmony/deploy not found. clean: init: windows-properties: linux-properties: properties: clean-overlay-oss: make-clean: BUILD FAILED /home/anoop/Harmony/make/build.xml:76: The following error occurred while executing this line: /home/anoop/Harmony/native-src/build.xml:121: Execute failed: java.io.IOException: java.io.IOException: No such file or directory Try to use ant -verbose. It will help to understand which exact command ant is trying to run. -- Alexey A. Petrenko 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: Ant build | IOException
Let us know how you get on, or if you need more help Anoop.
Regards,
Tim
Anoop kumar V wrote:
Hi,
I am a n00b wanting to contribute to Harmony.
All I have done so far (code-wise) is checkout the harmony code (revision
410710) from svn and run ant from ~/Harmony/make folder.
But I am running into errors:
I am using GCJ on Ubuntu5.10.
[EMAIL PROTECTED]:~/Harmony/make$ ant
Unable to locate tools.jar. Expected to find it in /usr/lib/jvm/java-
1.4.2-gcj-4.0-1.4.2.0/lib/tools.jar
Buildfile: build.xml
clean:
clean-bin:
[delete] /home/anoop/Harmony/build not found.
clean:
clean-layout:
[delete] /home/anoop/Harmony/deploy not found.
clean:
init:
windows-properties:
linux-properties:
properties:
clean-overlay-oss:
make-clean:
BUILD FAILED
/home/anoop/Harmony/make/build.xml:76: The following error occurred while
executing this line:
/home/anoop/Harmony/native-src/build.xml:121: Execute failed:
java.io.IOException: java.io.IOException: No such file or directory
The line 121 in the error above is this:
dir=${target.platform}
in the block:
!-- =
target: make-clean
= --
target name=make-clean depends=properties
exec failonerror=true
executable=${make.command}
dir=${target.platform}
arg line=clean /
/exec
/target
Can someone please point me what is the obvious-wrong I am doing?
Should I use Sun / Bea java for the build? And can I do development for
Harmony using some IDE like IntelliJ IDEA? And Should I not run the default
ant target if I am just going to do java work?
--
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]
Re: [classlib] JNDI provider's dependency on logging
Mikhail Loenko wrote: Hi Tim 2006/5/30, Tim Ellison [EMAIL PROTECTED]: I've just imported the HARMONY-256 contribution of a DNS provider for JNDI into our repository. That provider introduces a new dependency between JNDI and LOGGING that we didn't have before. IIRC we agreed that we would not scatter logging calls throughout our Would you please log an agreement in [1]? Yes, once I have given people a chance to object if they want to. Regards, Tim Thanks, Mikhail [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/agreements.html implementation code, so unless I hear an objection I'll start to unpick that dependency and make JNDI independent of LOGGING. Regards, Tim -- 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] -- 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]
Re: Ant build | IOException
Anoop kumar V wrote: Hi, I am a n00b wanting to contribute to Harmony. We're all newbies at some point, so don't worry about that :) All I have done so far (code-wise) is checkout the harmony code (revision 410710) from svn and run ant from ~/Harmony/make folder. But I am running into errors: I am using GCJ on Ubuntu5.10. There's your problem, I suspect, as I don't think anyone has tried using GCJ. [SNIP] Can someone please point me what is the obvious-wrong I am doing? Should I use Sun / Bea java for the build? And can I do development for Harmony using some IDE like IntelliJ IDEA? And Should I not run the default ant target if I am just going to do java work? While you should be able to self-host now using the J9 evaluation VM from IBM, others have noted it might be easier if you just go get the distro from Sun or BEA and start with that while you come up to speed. Yes, you can use IntelliJ - everyone can use the tools that are best for them, and the project will remain IDE neutral. :) As for the default ant target, you should run that to build the native libraries. We've been talking about making a development kit available that has those precompiled, but I think it's worth your while getting it to build from top to bottom at least once. Welcome, and thanks for volunteering :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib] java.io.File doesn't work with non-latin names
Hi, I just faced the problem that java.io.File doesn't properly work with the file names which has non-latin chars (I tried Russian, of course :-) ) on Windows. The minimal code to reproduce is: File russianDir = new File(c:\\temp\\\u0440\u0443\u0441_dir); russianDir.mkdirs(); System.out.println(isCreated = + russianDir.isDirectory()); which prints out false. The very important thing here is that Control Panel Regional And Language Options Regional Options tab Standards and formats setting is set to English US. All other regional settings (location, language for non-unicode programs) are set to Russian. If I switch Standards and formats to Russian everything works fine. Similar problem with other extended unicode chars. I looked through both mailing list and JIRA and found lots encoding-related issues, but not sure if my case is covered or not. Could the experts please look and decide should I submit new JIRA issue or not? If it is already tracked could you please point out its JIRA index? Wishes, -- Anton Avtamonov, 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: [classlib] JNDI provider's dependency on logging
Alexei Zakharov wrote:
This provider includes full-featured DNS client as part of its
functionality and has rather complex logic. It tries to establish big
number of networks connections and highly depends on network
conditions. In the case of perfomance degradation it is very usefull
for system admins to understand the provider's activity. If the
provider hangs while connecting to some unreachable server it is
important that the name of such server can be extracted from the log
and added to the server's black list. And so on.
In other words, DNS provider needs to log no less than any other
complex network application.
I agree with your last sentence. There are lots of modules in Harmony
now that contain non-trivial logic, and we can debug, trace, and
understand that code using existing tools.
For this provider I don't think it is useful to have calls out to
java.util.logging. We have much more flexibility if we are conservative
about the modules we use to implement a given area of functionality.
e.g. from DNSName.java:
...
try {
k = this.compareTo(name);
} catch (ClassCastException e) {
// impossible case
ProviderMgr.logger.log(Level.SEVERE, impossible case, e);
}
...
Regards,
Tim
2006/5/30, Geir Magnusson Jr [EMAIL PROTECTED]:
I agree with you. Why does it need to log?
geir
Tim Ellison wrote:
I've just imported the HARMONY-256 contribution of a DNS provider for
JNDI into our repository. That provider introduces a new dependency
between JNDI and LOGGING that we didn't have before.
IIRC we agreed that we would not scatter logging calls throughout our
implementation code, so unless I hear an objection I'll start to unpick
that dependency and make JNDI independent of LOGGING.
Regards,
Tim
--
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]
Re: [classlib] JNDI provider's dependency on logging
I can guarantee best performance and no yammering by removing the logging code ;-) Seriously, VMs know exactly which methods are being executed and their arguments, if we need trace or debug we can get lots of information from there. The logging statements are the equivalent of printf's in the code to see what is happening. Regards, Tim Geir Magnusson Jr wrote: I don't mind the dependency as much as I worry about the performance and the idea that our classlibraries might yammer out to stdout or logging infrastructure to the surprise of the users geir Zakharov, Vasily M wrote: Tim, I see your point of removing extra inter-dependencies between the modules, however I'm surprized by the idea of removing dependencies on Logging. Logging is a package specifically created to organize and structurize logging and debugging output, and I see using it as a good side of implementation of any component, as it provides the capability of having rich and detailed debugging output that can be switched on and off using standard means. Removing logging calls from Harmony components will make those components harder to debug and develop in future. Is it what we want? Vasily Zakharov Intel Middleware Products Division -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 30, 2006 3:51 PM To: harmony-dev Subject: [classlib] JNDI provider's dependency on logging I've just imported the HARMONY-256 contribution of a DNS provider for JNDI into our repository. That provider introduces a new dependency between JNDI and LOGGING that we didn't have before. IIRC we agreed that we would not scatter logging calls throughout our implementation code, so unless I hear an objection I'll start to unpick that dependency and make JNDI independent of LOGGING. Regards, Tim - 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]
Re: [classlib] JNDI provider's dependency on logging
Tim Ellison wrote:
Alexei Zakharov wrote:
This provider includes full-featured DNS client as part of its
functionality and has rather complex logic. It tries to establish big
number of networks connections and highly depends on network
conditions. In the case of perfomance degradation it is very usefull
for system admins to understand the provider's activity. If the
provider hangs while connecting to some unreachable server it is
important that the name of such server can be extracted from the log
and added to the server's black list. And so on.
In other words, DNS provider needs to log no less than any other
complex network application.
I agree with your last sentence. There are lots of modules in Harmony
now that contain non-trivial logic, and we can debug, trace, and
understand that code using existing tools.
For this provider I don't think it is useful to have calls out to
java.util.logging. We have much more flexibility if we are conservative
about the modules we use to implement a given area of functionality.
e.g. from DNSName.java:
...
try {
k = this.compareTo(name);
} catch (ClassCastException e) {
// impossible case
ProviderMgr.logger.log(Level.SEVERE, impossible case, e);
}
...
Is this your suggestion, or the way it is now?
geir too lazy to look
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] java.io.File doesn't work with non-latin names
Hi Anton (not seen you for a while!) Probably best to raise it in JIRA anyway, and we can close it as a duplicate if it is already covered. Otherwise it may get lost on the list. (just cut-n-paste your note into JIRA) Regards, Tim Anton Avtamonov wrote: Hi, I just faced the problem that java.io.File doesn't properly work with the file names which has non-latin chars (I tried Russian, of course :-) ) on Windows. The minimal code to reproduce is: File russianDir = new File(c:\\temp\\\u0440\u0443\u0441_dir); russianDir.mkdirs(); System.out.println(isCreated = + russianDir.isDirectory()); which prints out false. The very important thing here is that Control Panel Regional And Language Options Regional Options tab Standards and formats setting is set to English US. All other regional settings (location, language for non-unicode programs) are set to Russian. If I switch Standards and formats to Russian everything works fine. Similar problem with other extended unicode chars. I looked through both mailing list and JIRA and found lots encoding-related issues, but not sure if my case is covered or not. Could the experts please look and decide should I submit new JIRA issue or not? If it is already tracked could you please point out its JIRA index? Wishes, -- 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]
Re: [classlib] JNDI provider's dependency on logging
the idea that our classlibraries might yammer out to stdout or logging
infrastructure to the surprise of the users
If we use standard logging infrastructure from java.util.logging
package we have powerful mechanism to control the logging process. We
can turn off logging for all components anytime. We can turn it back
anytime. IMHO it does not affect the performance so much. Please look
at the following piece of code from DNS provider:
DEBUG logging:
if (LogConst.DEBUG) {
ProviderMgr.logger.fine(Current question: + curQuestion.toString());
}
Where LogConst is declared as
public static final boolean DEBUG = true;
While we debug and test our application we have DEBUG variable set to
true. When the application is ready to release we change DEBUG to
false by modifying the source like this:
public static final boolean DEBUG = false;
After doing that Java compiler will not generate any bytecode for
everything between parentheses:
if (LogConst.DEBUG) {
...
// this code will be skipped by the compiler
...
}
However, IMHO we still need to have some non-debug logging (in case
with DNS provider for logging high-level details about provider's
activity). I can't see many benefits in moving this to
System.out.println().
As for avoiding this type of logging completely - this does not seem
to be a good idea IMHO.
2006/5/30, Geir Magnusson Jr [EMAIL PROTECTED]:
I don't mind the dependency as much as I worry about the performance and
the idea that our classlibraries might yammer out to stdout or logging
infrastructure to the surprise of the users
geir
Zakharov, Vasily M wrote:
Tim,
I see your point of removing extra inter-dependencies between the
modules,
however I'm surprized by the idea of removing dependencies on Logging.
Logging is a package specifically created to organize and structurize
logging and debugging output, and I see using it as a good side of
implementation
of any component, as it provides the capability of having rich and
detailed
debugging output that can be switched on and off using standard means.
Removing logging calls from Harmony components will make those
components
harder to debug and develop in future. Is it what we want?
Vasily Zakharov
Intel Middleware Products Division
-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 30, 2006 3:51 PM
To: harmony-dev
Subject: [classlib] JNDI provider's dependency on logging
I've just imported the HARMONY-256 contribution of a DNS provider for
JNDI into our repository. That provider introduces a new dependency
between JNDI and LOGGING that we didn't have before.
IIRC we agreed that we would not scatter logging calls throughout our
implementation code, so unless I hear an objection I'll start to unpick
that dependency and make JNDI independent of LOGGING.
Regards,
Tim
--
Alexei Zakharov,
Intel Middleware Product 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: [classlib] JNDI provider's dependency on logging
Geir Magnusson Jr wrote: Is this your suggestion, or the way it is now? That's how it is now. There are other cases of logging too that show the workings of the code. Regards, Tim -- 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]
Re: JIRA messages on the commit list
On 30 May 2006 at 7:20, Magnusson, Geir [EMAIL PROTECTED] wrote: There very well could be. How long ago did you commit? HARMONY-532 was created just after 13:00 (GMT) - it is now nearly 14:30 (GMT). -Mark. --=20 Geir Magnusson Jr SSG/MPD [EMAIL PROTECTED] +1 203 665 6437 =20 -Original Message- From: Mark Hindess [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 30, 2006 7:23 AM To: Apache Harmony Dev List Subject: JIRA messages on the commit list =20 =20 Maybe I'm just impatient, but I'm wondering why create/update messages for HARMONY-532/533/534 haven't appeared on the commit list. Usually, they appear pretty quickly. Is there a problem? =20 Regards, Mark. =20 =20 =20 =20 =20 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] =20 - 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: Harmony on QNX
Thanks everyone for responding. In an effort to save emails I'm just going to lump my responses in to one email. Geir: Thanks for the response. I just wanted to know if it had been done on one of the other hosts. If has worked on the other hosts, then I figure it should be doable on QNX. Tim: We are interested. It's been awhile since we've been able to use J9 on QNX to run our Eclipse tools. We have a solution in place right now, but we would like to have the option of using J9. If we can use harmony that would be great. For now, I'm just going to see if I can get the natives to compile for QNX and then I'll go from there. Egor: Yep, 3.1 will run on QNX if you use Aonix's VM for QNX. That is our current solution. We are investigating the use of J9 through Harmony as our official Java story is IBM's J9. Eclipse dropped QNX support when a publicly available VM to run it went away. Paulex and Alex: Thanks for the info. I wasn't sure if Harmony had been used to run Eclipse. If it's been used in a demo than that is a good start as far as I am concerned. Mikhail: Thanks for running a test. No special test case is required. Just wanted to see if it was possible. Thanks for the positive feedback. I'm new to the whole mailing list thing and I wasn't sure what kind of response I was going to receive concerning this. I'll keep in touch ( especially if I have problems :-) ). Rodney Geir Magnusson Jr wrote: I don't think that we could honestly make an authoritative statement about the outcome... That said, I'm sure that if you ran into trouble, you'd get quite a bit of assistance from people around here getting you over the finish line! We're here to help. geir Rodney Dowdall wrote: Hello I've been investigating the possible use of Harmony on QNX. We would like to use it, along with the QNX j9 VM, to run our self-hosted Eclipse based tools. I was looking through the code today and while it would be some work, I think the port should be relatively straightforward. What I am afraid of is that I would get the port done only to find that it cannot run Eclipse. The statement that leads me to believe that Harmony isn't mature enough to run a full blown Eclipse is the following from the Harmony website: This contribution is sufficient to run Ant and the Eclipse Java compiler, to provide a basic self-hosting environment. IBM also made a version of their J9 VM available http://www.ibm.com/developerworks/java/jdk/harmony for use by the project in evaluating this contribution. I realize this is a fairly old statement, but I would just like to know if Harmony would be able to accomplish what I am hoping it can. Thanks, Rodney - 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: [classlib] JNDI provider's dependency on logging
Right. Good. (More in another message) Tim Ellison wrote: Geir Magnusson Jr wrote: Is this your suggestion, or the way it is now? That's how it is now. There are other cases of logging too that show the workings of the code. Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JIRA messages on the commit list
Odd. JIRA could very well have fallen over somehow I'll go look... Mark Hindess wrote: On 30 May 2006 at 7:20, Magnusson, Geir [EMAIL PROTECTED] wrote: There very well could be. How long ago did you commit? HARMONY-532 was created just after 13:00 (GMT) - it is now nearly 14:30 (GMT). -Mark. --=20 Geir Magnusson Jr SSG/MPD [EMAIL PROTECTED] +1 203 665 6437 =20 -Original Message- From: Mark Hindess [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 30, 2006 7:23 AM To: Apache Harmony Dev List Subject: JIRA messages on the commit list =20 =20 Maybe I'm just impatient, but I'm wondering why create/update messages for HARMONY-532/533/534 haven't appeared on the commit list. Usually, they appear pretty quickly. Is there a problem? =20 Regards, Mark. =20 =20 =20 =20 =20 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] =20 - 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: [classlib] JNDI provider's dependency on logging
Tim,
e.g. from DNSName.java:
I agree, this is not the best example of using logger. :) However, you
can find much better examples of using logger in Resolver.java.
Seriously, VMs know exactly which methods are being executed and their
arguments, if we need trace or debug we can get lots of information from
there. The logging statements are the equivalent of printf's in the
code to see what is happening.
I agree that we can extract low-level information from VM. But this
cannot replace high-level logs like:
connected to server1.blah.blah.com
incomplete answer was received from server2.example.org
redirecting to new workzone X
and so on.
It requires great efforts to extract high level stuff from low level
info. Removing logs probably increase the performance a little bit.
But this also dramatically increase debug and maintenance costs of the
system. Harmony in our case. We just need to consider what do we need
more.
2006/5/30, Tim Ellison [EMAIL PROTECTED]:
For this provider I don't think it is useful to have calls out to
java.util.logging. We have much more flexibility if we are conservative
about the modules we use to implement a given area of functionality.
e.g. from DNSName.java:
...
try {
k = this.compareTo(name);
} catch (ClassCastException e) {
// impossible case
ProviderMgr.logger.log(Level.SEVERE, impossible case, e);
}
...
Regards,
Tim
--
Alexei Zakharov,
Intel Middleware Product 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: [classlib] rmi2.1.4?
ITC's rmi is 5.0 compliant and dependent, but we realized that Harmony was 1.4; so, since our package made use of still not available 5.0 features (like j.u.c) , we decide to deploy a 1.4 version of the code, in which we remove all 5.0 dependencies. I believe that's the reason why rmi2.1.4 is there any advance with getting j.u.c? - Original Message - From: Geir Magnusson Jr [EMAIL PROTECTED] To: harmony-dev@incubator.apache.org Sent: Tuesday, May 30, 2006 11:51 AM Subject: [classlib] rmi2.1.4? why? - 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: [classlib] rmi2.1.4?
Daniel Gandara wrote: ITC's rmi is 5.0 compliant and dependent, but we realized that Harmony was 1.4; so, since our package made use of still not available 5.0 features (like j.u.c) , we decide to deploy a 1.4 version of the code, in which we remove all 5.0 dependencies. I believe that's the reason why rmi2.1.4 Can we resolve down to 1 version of RMI and cull goodness from the rest? is there any advance with getting j.u.c? According to Doug, we should just be able to use what we want from there. IIRC, Doug's assertion is that since this was the first implementation of j.u.c, and it was done in the public view, it therefore cannot be influenced by some other version, since there wasn't any other versions around. I'll start a new thread and we'll see if we can get doug to comment. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] java.io.File doesn't work with non-latin names
On 5/30/06, Tim Ellison [EMAIL PROTECTED] wrote: Hi Anton (not seen you for a while!) Yeah, I was busy with Swing contribution preparation :-) Probably best to raise it in JIRA anyway, and we can close it as a duplicate if it is already covered. Otherwise it may get lost on the list. (just cut-n-paste your note into JIRA) Done. Tracked as https://issues.apache.org/jira/browse/HARMONY-535 Thank you for the response! -- Anton Avtamonov, 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: jchevm status?
Archie, I tried to build Ivan's mods. I get a bunch of javac compiler errors starting with, java.lang.reflect.Constructor is not abstract and does not override abstract method isSynthetic()... Unfortunately, I have zero time to spend on this project right now. I looked at Ivan's mods. They seem reasonable and valuable. Please use your best judgement on applying the patches to the code. I don't want to slow down forward progress on the gnuclasspathadapter project. It would be great if someone jumps in and take this project forward. On 5/22/06, Archie Cobbs [EMAIL PROTECTED] wrote: Weldon Washburn wrote: Please hold off the check-in for a few days. I would like to try Ivan's mods on my machine to make certain they are complete. The intention is to reduce the chance of secondary patch-up check-ins and the related blizzard of emails. No problem.. I'll wait for both (a) your confirmation and (b) Apache contributor license thingie. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Weldon Washburn 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]
[classlib] logging from within our implementation
Seems like there is an important issue here, but the discussion can't seem to escape out of the thicket of the example. 1) Should we allow any logging from within the classlibrary? 2) How should we do it? There are a bunch of ways for the second question... using j.u.l, using IOC and injecting our own logging target to reduce dependencies and make people think before logging, using aspects? Comments? We probably should try to get to a conclusion in general... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OPEN] what to start with? (was Re: OPEN Specification)
On 5/30/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Etienne Gagnon wrote: Hi Anton, Are you proposing that all Harmony JVMs must abide by the OPEN proposal? I won't attempt to speak for Anton, but IMO, no. Right now, any JVM that works w/ Harmony classlib must simply support the class library's virtual machine interface. Let's think of the proposed OPEN spec as a starting point for the discussions about the modular JVM concept, I guess nobody assumed every JVM must abide by it. However, those VM's which are OPEN compliant would probably benefit at some point from the ability to share the components between each other. If yes, I think that some process has to be put in place to present and discuss each of this proposal's part, and dedicate time to do so. IMO, I don't think that everyone (in the JVM sub-communityof Harmony) can simply read through this proposal and be able to make an enlightened decision about it. I think that each point would gain much from being presented along the motivation behind it. Yes, I think that we'll need lots of discussion around this proposal. One possible approach to the discussion process could be to pick up some simple part of VM (how about class loader?), and then try to compare the existing interface for that part in DRLVM and SableVM. From this comparison we could build up a first OPEN interface for this part, and then extend it to some bigger component, then go to other parts, consider other VM's e.t.c. until we get the whole picture. How does that approach sound? BTW, does SableVM assume some component/pluggability model around it? It would be interesting to see how far is it from the proposed OPEN concepts, what works in the OPEN specifically for SableVM and what doesn't, e.t.c. Thank you, Andrey Chernyshev Intel Middleware Products Division In the future, can we prefix subject lines related to this with [OPEN] or such so poeple interested in the subject can easily identify threads related to 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: [classlib] logging from within our implementation
Geir Magnusson Jr wrote: Seems like there is an important issue here, but the discussion can't seem to escape out of the thicket of the example. 1) Should we allow any logging from within the classlibrary? Just in case there was any doubt from my earlier postings... I think we should not be explicitly logging debug info as part of our class library implementation. 2) How should we do it? There are a bunch of ways for the second question... using j.u.l, using IOC and injecting our own logging target to reduce dependencies and make people think before logging, using aspects? Both j.u.l and IoC would require code in the implementation to perform the logging actions (or check the guard). Putting this logic throughout the class library will IMHO result in module coupling, code bloat and overall performance degradation (or no logging!). Adding logging statements is expecting the class library developer to decide /a priori/ what debug|trace info is useful to the person trying to resolve a problem. Existing debug|trace tools work with the runtime to figure out the pertinent information as you are interested in it. (The only caveat being 'flight data recorder' type trace where the trace points are typically very low overhead and always on). Comments? We probably should try to get to a conclusion in general... The logging info being proposed is developer-oriented. I hope that people are not expecting our users to understand our developer trace info -- we, as developers, have better tools than printf to figure out what is happening. Regards, Tim -- 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]
Re: [DRLVM] build process improvement
The VM and the classlib will be parallel trees, for example... harmony/enhanced/classlib harmony/enhanced/whatevernameforVM Besides XXXVM and classlib trees, are we going to have some place for the things which can be shared between VM and classlib? For example, where do we put common include files like jni.h which have to be used both by VM and classlib during compilation, do we keep them in every XXXVM and classlib tree, or somewhere else? Another example: suppose one day VM and classlib decide to share the code from the modules like port, zip support, thread e.t.c.. What should be the right location for these modules, should they be a part of VM or a part of classlib? Thanks, Andrey. On 5/25/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Andrey Chernyshev wrote: On 5/23/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Andrey Chernyshev wrote: Returning back to the subject of this discussion, I guess it should be relatively easy to modify the DRLVM building system such that it would get the binary HDK from web and use it for compilation of a single module. I don't understand this sentence. Do you mean a classlibrary module or a DRLVM module? It could be both actually, the building script produces complete JRE combined from a set of classlib modules and a set of VM modules. There is no much distinction between VM or classlib, all modules are built using the same set of rules. Though all modules are currently compiled, it should be possible to take some of them in a binary form from HDK snapshot. I find it hard to see why we'd want to couple them in the long run. The VM and the classlib will be parallel trees, for example... harmony/enhanced/classlib harmony/enhanced/whatevernameforVM Thanks, Andrey. And this approach would assume that the HDK snapshots include the DRLVM as well (?) :) Assuming we accept DRLVM as our basis for our VM, yes. We can also include JCHEVM whenever it converts from GNU Classpath :) 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
Geir Magnusson Jr wrote: Tim Ellison wrote: Geir Magnusson Jr wrote: Seems like there is an important issue here, but the discussion can't seem to escape out of the thicket of the example. 1) Should we allow any logging from within the classlibrary? Just in case there was any doubt from my earlier postings... I think we should not be explicitly logging debug info as part of our class library implementation. In any form? Right -- no explicit logging in any form. 2) How should we do it? There are a bunch of ways for the second question... using j.u.l, using IOC and injecting our own logging target to reduce dependencies and make people think before logging, using aspects? Both j.u.l and IoC would require code in the implementation to perform the logging actions (or check the guard). Putting this logic throughout the class library will IMHO result in module coupling, code bloat and overall performance degradation (or no logging!). Right - that's why I was thinking of the latter. i.e. aspects? Something that would have no runtime overhead, yet allow us to capture more information other than just execution path and stack values :) Adding logging statements is expecting the class library developer to decide /a priori/ what debug|trace info is useful to the person trying to resolve a problem. Existing debug|trace tools work with the runtime to figure out the pertinent information as you are interested in it. (The only caveat being 'flight data recorder' type trace where the trace points are typically very low overhead and always on). Comments? We probably should try to get to a conclusion in general... The logging info being proposed is developer-oriented. I hope that people are not expecting our users to understand our developer trace info -- we, as developers, have better tools than printf to figure out what is happening. I have to admit that I don't agree w/ better as a universally general statement, Well I guess it is a POV, but give me a java-aware debugger and trace tools over printf any day. as debug statements can include information provided by the developer not immediately obvious. I would claim that there are tools that can provide the statement value info 'live' rather than having to encode them into the class library code directly. Is there some kind of aspect framework we can use? Then for develeopers, they have to implicitly do something to get the stuff to come out, it's not a runtime cost for anyone else, and the stuff stays in the codebase for use later? Aspects can be applied to the code without any explicit modification to the class library logic, so there is nothing to 'stay in the codebase'. Regards, Tim -- 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]
Re: [classlib] logging from within our implementation
Just to be clear, I certainly sympathize with Tim and support getting rid of implementation debug logging in the long term. Maybe the way to compromise/phrase it is agree that when a package is done, we will pitch all the logging? I can see why having logging around while things are being developed is helpful, and committing to SVN is ok since we want people to commit early and often, and having to pull out logging would be a disincentive for someone working on something big. Does this help? At the end we are going to dump any logging debris that have any performance or other burden like increase in dependencies geir Geir Magnusson Jr wrote: Tim Ellison wrote: Geir Magnusson Jr wrote: Seems like there is an important issue here, but the discussion can't seem to escape out of the thicket of the example. 1) Should we allow any logging from within the classlibrary? Just in case there was any doubt from my earlier postings... I think we should not be explicitly logging debug info as part of our class library implementation. In any form? 2) How should we do it? There are a bunch of ways for the second question... using j.u.l, using IOC and injecting our own logging target to reduce dependencies and make people think before logging, using aspects? Both j.u.l and IoC would require code in the implementation to perform the logging actions (or check the guard). Putting this logic throughout the class library will IMHO result in module coupling, code bloat and overall performance degradation (or no logging!). Right - that's why I was thinking of the latter. Something that would have no runtime overhead, yet allow us to capture more information other than just execution path and stack values :) Adding logging statements is expecting the class library developer to decide /a priori/ what debug|trace info is useful to the person trying to resolve a problem. Existing debug|trace tools work with the runtime to figure out the pertinent information as you are interested in it. (The only caveat being 'flight data recorder' type trace where the trace points are typically very low overhead and always on). Comments? We probably should try to get to a conclusion in general... The logging info being proposed is developer-oriented. I hope that people are not expecting our users to understand our developer trace info -- we, as developers, have better tools than printf to figure out what is happening. I have to admit that I don't agree w/ better as a universally general statement, as debug statements can include information provided by the developer not immediately obvious. Is there some kind of aspect framework we can use? Then for develeopers, they have to implicitly do something to get the stuff to come out, it's not a runtime cost for anyone else, and the stuff stays in the codebase for use later? 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: [classlib] logging from within our implementation
I can agree that libraries like java.util and java.math probably will not need any logging on the production stage. But some parts of the classlib look more like applications rather than libraries. Providers can be the good example. And logging for such apps can be considered as part of UI. Let's say UI for advanced users. Such app will lost its usefulness if logging is completely removed. A lot of applications use logging. All enterprise servers extensively use logging in spite of the fact that performance is very important for j2ee. 2006/5/30, Gregory Shimansky [EMAIL PROTECTED]: On Tuesday 30 May 2006 22:59 Tim Ellison wrote: The logging info being proposed is developer-oriented. I hope that people are not expecting our users to understand our developer trace info -- we, as developers, have better tools than printf to figure out what is happening. I have to admit that I don't agree w/ better as a universally general statement, Well I guess it is a POV, but give me a java-aware debugger and trace tools over printf any day. Hello Tim I don't want to start any flame, but want to show an example of an application (yes it is not a class library, just a big java application) which has a lot of logging hardcoded into it. It is Eclipse :) Maybe java-aware debugger didn't help eclipse developers all the time as much as tracing did. -- Gregory Shimansky, Intel Middleware Products Division -- Alexei Zakharov, Intel Middleware Product 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: [classlib] logging from within our implementation
On Wednesday 31 May 2006 00:09 Ivan Volosyuk wrote: I am not sure, we can say someday: Yes, the code is absolutely bug free! Remove the logging! I have a suggestion, which can help leave logging in place while still having no impact on performance. The logging can be used for debuging of features and will be removed in release version. It require some changes to build system though. The idea is quite simple: we can use C preprocessor directives in java files. When building the preprocessor will be executed before java compiler (if the source-file's timestamp was changed). Thus we can have logger-free release builds and debug builds with full weight logging. I have a simpler suggestion which doesn't require any tools foreign to java. Make classlib debugging infrastructure internal class, not java.util.logging, but an internal wrapper to classes in java.util.logging. And in release version all its methods should be empty. Any good behaving optimizing runtime would inline empty methods into nothing and therefore no performance impact would be made. -- Gregory Shimansky, 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: [classlib] logging from within our implementation
2006/5/31, Gregory Shimansky [EMAIL PROTECTED]:
On Wednesday 31 May 2006 00:09 Ivan Volosyuk wrote:
I am not sure, we can say someday: Yes, the code is absolutely bug
free! Remove the logging!
I have a suggestion, which can help leave logging in place while still
having no impact on performance. The logging can be used for debuging
of features and will be removed in release version. It require some
changes to build system though.
The idea is quite simple: we can use C preprocessor directives in java
files. When building the preprocessor will be executed before java
compiler (if the source-file's timestamp was changed). Thus we can
have logger-free release builds and debug builds with full weight
logging.
I have a simpler suggestion which doesn't require any tools foreign to java.
Make classlib debugging infrastructure internal class, not java.util.logging,
but an internal wrapper to classes in java.util.logging. And in release
version all its methods should be empty.
Any good behaving optimizing runtime would inline empty methods into nothing
and therefore no performance impact would be made.
Excelent! This is much better and simplier.
public final class CLogger {
public static void msg(Object... ) {..}
}
Hmm, I see one drawback of this approach: arguments will still be
evaluated even if logger itself will be empty. So, some care needed to
maintain performance with such logger.
--
Ivan
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[classlib] restructuring deploy dir
FYI I'm currently working with HARMONY-469 : Refactor deploy directory layout into HDK shape It adds a /jdk/ directory into the deploy/jre path to enable development against an 'HDK' that has been discussed recently. The patch touches all the modules. Regards, Tim -- 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]
Re: [classlib] logging from within our implementation
On 30/05/06, Chris Gray [EMAIL PROTECTED] wrote: If the implementation is an empty method and is final, a straightforward static flow analysis will show that the evaluation of the arguments can also be optimised away. Not necessarily. Evaluation of arguments may have side-effects, and therefore even if the call to the logging gets optimised away, the evaluation may not be. It's better to have an array of Strings and let the logger do the concatenation rather than have a single Object/String and performing the concatenation, because then the logger can do the concatenation through stream manipulation rather than in-memory copying. That said, I don't think there's a great benefit of having logging in production code once it's complete, and I think that an aspect would be a better way of compiling with debugging code in. Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AWT, Java2D and SWING contribution
On 5/30/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: YAY! +1 :-) - robert
[DRLVM] adding write barriers to Jitrino.JET
All,
I have been looking at DRLVM contained in JIRA Harmony-438. As far as
I can tell, it does not have write barrier support. Write barrier
support is pretty much required for high performance garbage
collectors. In anticipation of using DRLVM with modern GCs like MMTK,
I'd like to add write barrier support.
DRLVM contains a simple JIT called Jitrino.JET in addition to a highly
optimizing JIT. The simple JIT seems to be a better choice for
starting the write barrier work.
Looking at Jitrino.JET sources, it looks like the best place to add
write barriers is in cg_ia32.cpp: Compiler::gen_st() {...} Does
this seem right?
Also, I have looked for documentation on Jitrino.JET but have not been
able to locate it. It would be nice see some graphic documentation on
how the compiler spill/fills between the stack and registers. And
also how the compiler deals with the live ranges of reference
variables. In specific how root set enumeration works. While not
absolutely essential for hacking in write barriers, it will help a
bunch during the debug stage.
Thanks
--
Weldon Washburn
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: [classlib] java.util.concurrency
Nathan Beyer wrote: I was browsing Doug's Concurrency interest page [1] and noticed that the code is available in a CVS repository and all of the j.u.c class are copyrighted with a Creative Commons public domain license [2]. Yes, that's been Doug's claim and my motivation for using the code from there. We'd have to examine it from the POV of the ACQ for any issues like that, but I wouldn't imagine we'd have any large problems. The TCK source seems to be there as well. Assuming this is an acceptable license by Apache terms, it would seem we could use this code. Assuming we can take the code, we could incorporate that TCK code into our normal test suite. Additionally, there is a pre-built JAR [3], which could possible be used for development purposes if dropped into the bootclasspath. Give it a whirl :) let us know :) geir Note, some of the code seems to include maintenance updates that are above the Java 5 RI. -Nathan [1] http://gee.cs.oswego.edu/dl/concurrency-interest/ [2] http://creativecommons.org/licenses/publicdomain [3] http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166.jar -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 30, 2006 9:29 AM To: harmony-dev@incubator.apache.org Cc: Doug Lea Subject: [classlib] java.util.concurrency I'm cc-ing Doug on this because I'm certain he doesn't read our list anymore. Doug, can you opine regarding the ability for this project to use your code for our implementation of j.u.c, keeping in mind our rules ensuring that we don't use any copyrighted material or other IP for which we don't have permission? 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]
RE: [classlib] java.util.concurrency
Here's an early analysis using the code at Doug's site. Assumptions: * Use the code tagged JSR166_PFD [1], as this seems to be the Java 5 spec version. The HEAD has some new code that depends on Java 6 APIs, like Deque. * Only use and look at the code that contains a header declaring a public domain license. Results: * java.util.concurrent - Only two or three classes don't compile. The two missing dependencies are System.nanoTime and java.util.PriorityQueue, which we'd have to write. Note that the java.util.AbstractQueue is in this repository as public domain, so that should help. * java.util.concurrent.atomic - None of these classes compile, as they are dependent on a VM specific atomic locking mechanism that Harmony would have to provide. * java.util.concurrent.locks - Only two classes don't compile, as they are also dependent on some VM specific locking mechanisms. Thoughts: * System.nanoTime() could be stubbed out and possibly temporarily implemented as a pass through to System.currentTimeMillis(). * Once a java.util.PriorityQueue implementation is completed, a concurrent module could be seeded with the java.util.concurrent package and this would provide a good start. * Layout a VM Java API for the necessary locking methods, which could be part of luni-kernel or a separate concurrent-kernel. Someone with a bit more VMI hacking would probably have some better thought here, but I thought I viable patch might be to provide a simple Java implementation of this locking that uses traditional Java locking. Obviously this would slightly defeat the point of the atomic locks, but it could provide a functional test basis. Please reply with any comments. -Nathan [1] http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/?only_with_tag=JSR166_PF D -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 30, 2006 6:49 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib] java.util.concurrency Nathan Beyer wrote: I was browsing Doug's Concurrency interest page [1] and noticed that the code is available in a CVS repository and all of the j.u.c class are copyrighted with a Creative Commons public domain license [2]. Yes, that's been Doug's claim and my motivation for using the code from there. We'd have to examine it from the POV of the ACQ for any issues like that, but I wouldn't imagine we'd have any large problems. The TCK source seems to be there as well. Assuming this is an acceptable license by Apache terms, it would seem we could use this code. Assuming we can take the code, we could incorporate that TCK code into our normal test suite. Additionally, there is a pre-built JAR [3], which could possible be used for development purposes if dropped into the bootclasspath. Give it a whirl :) let us know :) geir Note, some of the code seems to include maintenance updates that are above the Java 5 RI. -Nathan [1] http://gee.cs.oswego.edu/dl/concurrency-interest/ [2] http://creativecommons.org/licenses/publicdomain [3] http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166.jar -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 30, 2006 9:29 AM To: harmony-dev@incubator.apache.org Cc: Doug Lea Subject: [classlib] java.util.concurrency I'm cc-ing Doug on this because I'm certain he doesn't read our list anymore. Doug, can you opine regarding the ability for this project to use your code for our implementation of j.u.c, keeping in mind our rules ensuring that we don't use any copyrighted material or other IP for which we don't have permission? 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
I have a question. Consider scenario: JRE has java.security configuration file that includes list of providers. At some (usually start-up) time this file is being loaded and parsed. Then providers are loaded too and list of available algorithms is created. Some algorithms or even whole providers might require native libraries, those libraries could be unavailable at the moment of load attempt. If the libraries are unavailable we have the following options: 1. Do not include algorithm that requires unavailable libraries into the list of available algorithms. 2. Do not include whole provider 3. Terminate VM It is reasonabe that 12 are supplemented with some logging. RI seems to do #2 plus logging. What should we do if logging is prohibited? Thanks, Mikhail 2006/5/31, Geir Magnusson Jr [EMAIL PROTECTED]: Tim Ellison wrote: Geir Magnusson Jr wrote: The logging info being proposed is developer-oriented. I hope that people are not expecting our users to understand our developer trace info -- we, as developers, have better tools than printf to figure out what is happening. I have to admit that I don't agree w/ better as a universally general statement, Well I guess it is a POV, but give me a java-aware debugger and trace tools over printf any day. To be clear [again], don't get caught on printf, because no one is advocating that, I believe. 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]
[VOTE] Acceptance of HARMONY-438 : DRL Virtual Machine Contribution
I have received the ACQs and the BCC for Harmony-438, so I can assert that the critical provenance paperwork is in order and in SVN. Please vote to accept or reject this codebase into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below) Lets let this run a minimum of 3 days unless a) someone states they need more time or b) we get all committer votes before then. I think that getting this into SVN and letting people supply patches against SVN will be productive... geir - 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] Acceptance of HARMONY-438 : DRL Virtual Machine Contribution
+1 from me Geir Magnusson Jr wrote: I have received the ACQs and the BCC for Harmony-438, so I can assert that the critical provenance paperwork is in order and in SVN. Please vote to accept or reject this codebase into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below) Lets let this run a minimum of 3 days unless a) someone states they need more time or b) we get all committer votes before then. I think that getting this into SVN and letting people supply patches against SVN will be productive... 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: [VOTE] Acceptance of HARMONY-438 : DRL Virtual Machine Contribution
+1 2006/5/31, Geir Magnusson Jr [EMAIL PROTECTED]: +1 from me Geir Magnusson Jr wrote: I have received the ACQs and the BCC for Harmony-438, so I can assert that the critical provenance paperwork is in order and in SVN. Please vote to accept or reject this codebase into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below) Lets let this run a minimum of 3 days unless a) someone states they need more time or b) we get all committer votes before then. I think that getting this into SVN and letting people supply patches against SVN will be productive... 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]
Re: [classlib] millions of rmi tests
2006/5/30, Geir Magnusson Jr [EMAIL PROTECTED]:
Mikhail Loenko wrote:
I've tried to integrate rmi2 tests to rmi module, and found some odd
things.
Let's take a look for example at TestActivationGroupDesc.java
it has 5158 test methods, most of which are very similar.
For example it has 855 tests that invoke constructor with various
parameters
and check that new did not return null and no exception was thrown:
Can 'new' actually return null? My read of the JLS says that it won't.
it should be a bug in VM to return null. So comparing to null is not necessary
in the API tests.
Compare
public void
testActivationGroupDescStringStringMarshalledObjectPropertiesCommandEnvironment006()
{
try{
Properties p= new Properties();
assertNotNull(msgNotNull, new ActivationGroupDesc(null , null ,
new MarshalledObject(new Double(23.4)) , new
Properties() ,
new ActivationGroupDesc.CommandEnvironment(Hola la,
new String[0])));
} catch (Throwable e) {
fail(msgNoException+e);
}
}
and
public void
testActivationGroupDescStringStringMarshalledObjectPropertiesCommandEnvironment007()
{
try{
Properties p= new Properties();
assertNotNull(msgNotNull, new ActivationGroupDesc(null , null ,
new MarshalledObject(new Double(23.4)) , new
Properties() ,
new ActivationGroupDesc.CommandEnvironment(, null)));
} catch (Throwable e) {
fail(msgNoException+e);
}
}
This is how the constructor under test looks like:
public ActivationGroupDesc(String className, String codebase,
MarshalledObject data, Properties props,
ActivationGroupDesc.CommandEnvironment env) {
this.className = className;
this.location = codebase;
this.data = data;
this.props = props;
this.env = env;
}
It seems that instead of those million test cases we need just a few
that would verify that getXXX() methods return what was passed into
constructor
plus possibly some tests that pass 'suspicious' parameters like null.
Thoughts?
I don't agree that would be enough - having tests that assualt the CTORs
w/ combinations of crap to see what happens isn't a bad thing. Not a
fun thing to write, but certainly not something I vote on throwing away
if someone wrote it already.
They were not written, they were generated. And I suspect that if we change
some options to test generator then it can generate as many tests as you have
free space on your hard drive. Do we need them all in the test suite?
My question is given that so far we had ~7500 tests against all the API do
we need 5000+ tests against a single trivial constructor?
Why do you see a problem?
The problem is test execution time.
I think that it's misleading to trust only that getters return what's
passed in...
Sorry, I did not catch
Thanks,
Mikhail
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]
