On 10/5/06, Vladimir Ivanov wrote:
On 10/4/06, Stepan Mishura wrote:
Seems, that everybody thinking about separated test jar for each
module
(I
proposed one jar as first step onlyJ). Now, we should implement this.
If
you
need any help I'm a volunteer.
This won't work for all
On the 0x1F9 day of Apache Harmony Naveen Neelakantam wrote:
On Oct 4, 2006, at 12:53 AM, Egor Pasko wrote:
One more to say on the patch:
+//meetBest(Reduced, x) = Reduced
should be:
+//meetBest(Reduced, x) = Reduced
(just a comment,
Salikh,
I've applied this fix in r453130. But in future please raise a JIRA.
(As it happens I need this fix to workaround problems I was having
on x86_64 otherwise I'd have probably been more hesitant about applying
it.)
Regards,
Mark.
On 4 October 2006 at 17:25, Salikh Zakirov [EMAIL
On 5 October 2006 at 3:02, Naveen Neelakantam [EMAIL PROTECTED] wrote:
Mark (or whomever),
This patch should be applied. It fixes a bug introduced by another
one of my patches. Whoops.
Fixed. Thanks.
-Mark.
-
Mark Hindess wrote:
Salikh,
I've applied this fix in r453130. But in future please raise a JIRA.
(As it happens I need this fix to workaround problems I was having
on x86_64 otherwise I'd have probably been more hesitant about applying
it.)
Okay, thanks.
Hi Noel,
Does this still include the hardware portability layer? Any synergies with
APR? Does it include the AWT code?
And here is my reply to Noel's message:
Hi Noel,
The code runs on x86, ARM, MIPS, and PowerPC; basically it should run on any
normal 32-bit processor (with or without
Ok. There haven't been any shouts against it so. I'm going to split
the .java files that contain two classes and then dump the patternsets.
Regards,
Mark.
On 3 October 2006 at 11:27, Oliver Deakin [EMAIL PROTECTED] wrote:
Mark Hindess wrote:
On 28 September 2006 at 14:58, Alexey Petrenko
:-( Implementation-Version is (or maybe 'was' now) being set
dynamically. I don;t expect the impl version to be the same as the spec
version.
See the build-jar target in each module's build.xml that sets it to the
${svn.info}.
The Specification-Version: can be a property too.
Regards,
Tim
Now that we have javac, javah, javap (if Tim votes ;) and keytool, I'd
BTW, we have more tools indeed. I mean RMI tools:
rmic - java org.apache.harmony.rmi.compiler.Main
rmid - java org.apache.harmony.rmi.activation.Rmid
rmiregistry - java org.apache.harmony.rmi.registry.RegistryImpl
We can
Alexey Petrenko wrote:
We also need to keep Import-Package section up to date...
For sure, and (just to be clear to all) these are not just for Eclipse's
benefit, they are for our benefit as they are the definition of our
class library modularity. When you add a new Import or Export you are
Mikhail Loenko wrote:
Yes, please. When you submit a patch people will have a chance
to review and comment
Agreed - and please submit it via JIRA. Feel free to point to it on the
list.
Regards,
Tim
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
Hello Geir,
j.l.PackageTest fails because the package information were
set while processing the H-1651.
Could you please fix the test using the patch placed in H-1712?
Great thanks,
Serguei
+1
Rana Dasgupta wrote:
+1
And the JIRA has logging properties as well. On several threads now, email
patches have just caused more confusion, with participants asking if these
are examples or live code.
On 10/4/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
I do not like JIRA too,
Tim,
I got your point and mostly agree with you.
But in this case we really need some dependency checking routine
because now nobody checks them.
SY, Alexey
2006/10/5, Tim Ellison [EMAIL PROTECTED]:
Alexey Petrenko wrote:
We also need to keep Import-Package section up to date...
For sure,
Nathan Beyer wrote:
There may be value in doing this, but what's the increase in class file
overhead? Every new class that gets created for these locks ends up as
another class file that has to be stored (takes up drive space) and has to
be loaded (takes up memory in the class loader). Ever
Salikh,
out of curiosity, do you know why it happens that Intel Compiler
requires librt at build time to resolve symbols in run time, while gcc
works fine w/o this option.
Also parent system libset contains librt, but not being forwarded to
hythread (due to ant bug I believe), but if just copy
Alexey Petrenko wrote:
Tim,
I got your point and mostly agree with you.
Which bit do you disagree with g ?
But in this case we really need some dependency checking routine
because now nobody checks them.
Well the Eclipse-based people will be checking them (since we get
compiler errors for
Sure. Now I am running the tests on the patch to ensure that
modifications in beans are safe. Will submit when the tests will pass.
On 10/5/06, Tim Ellison [EMAIL PROTECTED] wrote:
Mikhail Loenko wrote:
Yes, please. When you submit a patch people will have a chance
to review and comment
On 10/4/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
Salikh Zakirov wrote:
The patch turned out to be exact duplicate of HARMONY-1571.
Besides, there exist a patch with fixes for unit tests: HARMONY-1574.
The following change is needed on top of already committed HARMONY-1551
to make DRLVM
Alexey Varlamov wrote:
2006/10/4, Salikh Zakirov [EMAIL PROTECTED]:
Tim Ellison 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
Alexei Zakharov wrote:
Now that we have javac, javah, javap (if Tim votes ;) and keytool, I'd
BTW, we have more tools indeed. I mean RMI tools:
rmic - java org.apache.harmony.rmi.compiler.Main
rmid - java org.apache.harmony.rmi.activation.Rmid
rmiregistry - java
Hello, JIT GC gurus!
I'd like to share my observations on HARMONY-1862 and move the
discussion from JIRA. Mikhail, Ivan, your opinions are extremely
valuable!
Mikhail Fursov commented on HARMONY-1682:
-
Ivan, I checked the test you sent
The test
We did this topic already g it's even referenced from the website
[1]. So at the risk of repeating my super-super-duper high level view...
Why are we considering putting logging into the class library
implementation?
Is it for our end-users? Do we expect them to turn on logging and look
at
On 5 October 2006 at 13:48, Ivan Volosyuk [EMAIL PROTECTED] wrote:
Readme is quite helpful. Yesterday, I used google to locate thouse lcms libra
ry.
IMHO, if the build system displayed the link to the README.txt it
could be much easier to deal with the issue.
Hmm... it should already? I
Hello,
Maybe it's worth to explicitly specify priorities for various kinds of
bugs? The advice that appears now near 'priority' drop-down in JIRA
list is general and not Harmony-specific. Bug submitters make decision
mostly by his/her intuition.
An example of rule set: VM hangs crashes -
Egor,
You are right that log contains only (mptr,base) pairs. The offset ==
MAX_INT is interpreted as unknown. In this case the correct base for a
managed pointer is chosen in runtime: the algorithm searches for the nearest
known base.
In the log for the GCMap codegenerator's stage base is
On 5 October 2006 at 14:37, Anton Luht [EMAIL PROTECTED] wrote:
Hello,
Maybe it's worth to explicitly specify priorities for various kinds of
bugs? The advice that appears now near 'priority' drop-down in JIRA
list is general and not Harmony-specific. Bug submitters make decision
mostly by
On 5 October 2006 at 13:57, Ivan Volosyuk [EMAIL PROTECTED] wrote:
On 10/4/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
Salikh Zakirov wrote:
The patch turned out to be exact duplicate of HARMONY-1571.
Besides, there exist a patch with fixes for unit tests: HARMONY-1574.
The
Nikolay Kuznetsov wrote:
out of curiosity, do you know why it happens that Intel Compiler
requires librt at build time to resolve symbols in run time, while gcc
works fine w/o this option.
Also parent system libset contains librt, but not being forwarded to
hythread (due to ant bug I
Well, I still think that logging is useful sometimes.
Is it for our end-users? Do we expect them to turn on logging and look
at the contents to discover problems in our code? or perhaps discover
problems in their usage of the API? Both of these seem like flawed
concepts.
Yes, exactly. For
Anton Luht wrote:
Hello,
Maybe it's worth to explicitly specify priorities for various kinds of
bugs? The advice that appears now near 'priority' drop-down in JIRA
list is general and not Harmony-specific. Bug submitters make decision
mostly by his/her intuition.
An example of rule set:
On 10/5/06, Mark Hindess [EMAIL PROTECTED] wrote:
On 5 October 2006 at 13:48, Ivan Volosyuk [EMAIL PROTECTED] wrote:
Readme is quite helpful. Yesterday, I used google to locate thouse lcms libra
ry.
IMHO, if the build system displayed the link to the README.txt it
could be much easier to
Just want to add:
cosmetic changes that do not affect the functionality - trivial
Regards,
2006/10/5, Anton Luht [EMAIL PROTECTED]:
Hello,
Maybe it's worth to explicitly specify priorities for various kinds of
bugs? The advice that appears now near 'priority' drop-down in JIRA
list is general
On the 0x1F9 day of Apache Harmony Mikhail Fursov wrote:
Egor,
You are right that log contains only (mptr,base) pairs. The offset ==
MAX_INT is interpreted as unknown. In this case the correct base for a
managed pointer is chosen in runtime: the algorithm searches for the nearest
known base.
I've tried to follow you suggestions. The result:
1. The fix for unimplemented
java.util.logging.LogManager.getLoggingMXBean could be simple, like:
return LoggingMXBeanImpl.getInstance()
But it bind logging module to LoggingMXBean implementation.
Probably more clean solution would be:
Patch for the TransferHandlerTest failure is here:
http://issues.apache.org/jira/browse/HARMONY-1723
On 10/5/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
2006/10/5, Oleg Khaschansky [EMAIL PROTECTED]:
I found the reason of this failure. It is an IntrospectionException
while executing a
On the 0x1F9 day of Apache Harmony Ivan Volosyuk wrote:
On 05 Oct 2006 17:09:35 +0700, Egor Pasko [EMAIL PROTECTED] wrote:
Hello, JIT GC gurus!
I'd like to share my observations on HARMONY-1862 and move the
discussion from JIRA. Mikhail, Ivan, your opinions are extremely
valuable!
On 10/5/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
Is this can be a problem? If the base pointer is optimized out and we
will find different object base?
--
Ivan
The base pointer for mptr with unknown offset must live as long as mptr is
alive.
The 'gcpoint' pass adds pseudo usages for such
Oleg,
+ we need to fix in beans the fact that the following code:
new PropertyDescriptor(propertyName, c.getClass(), 1, null);
will throw IntrospectionException on Harmony, but will return the
valid property descriptor with the getter method on RI.
Any thoughts on this? Or should I proceed with
Hello, Salikh,
I just suggest rules to be written explicitly. Every bug submitter
tends to think that his bug or his application is the most important -
some limits should be put to avoid 90% of bugs being major and
critical.
On 10/5/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
Anton Luht
On 5 October 2006 at 15:20, Ivan Volosyuk [EMAIL PROTECTED] wrote:
On 10/5/06, Mark Hindess [EMAIL PROTECTED] wrote:
On 5 October 2006 at 13:48, Ivan Volosyuk [EMAIL PROTECTED] wrote
:
Readme is quite helpful. Yesterday, I used google to locate thouse lcms l
ibra
ry.
IMHO, if
Guys,
I'm working on build files for Applet/ImageIO/Print modules contribution...
Number of print modules tests fails if there is no printer in the
system. Should I exclude such tests?
SY, Alexey
--
Alexey A. Petrenko
Intel Middleware Products Division
Hi,
I'm working on restoring cunit tests. I already made a good progress
in that direction. So I expect to have it done soon
Evgueni
On 10/4/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
On 10/4/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I assume you intend that only the latest patch
On 5 October 2006 at 16:39, Alexey Petrenko [EMAIL PROTECTED] wrote:
Guys,
I'm working on build files for Applet/ImageIO/Print modules contribution...
Number of print modules tests fails if there is no printer in the
system. Should I exclude such tests?
Yes. Please.
I got impatient
Alexey,
Agree. I haven't noticed that RI doesn't accept invalid write method.
Then its behavior looks illogical. Actually, I asked about comments
especially because I expected a feedback from beans authors. Thank
you.
On the other hand, why don't we allow Harmony to accept invalid names
and
I'm mostly finished... Running tests...
So you can stop :)
Sorry that it took me so much time. I'm a little bit ill now. Flu...
SY, Alexey
2006/10/5, Mark Hindess [EMAIL PROTECTED]:
On 5 October 2006 at 16:39, Alexey Petrenko [EMAIL PROTECTED] wrote:
Guys,
I'm working on build files for
The priority of the bug could be the priority of the scenario this bug
affects.
So, we need to select some applications/scenarios and if one of these
applications failed - the bug is blocker or critical.
Major as default priority is OK (imo) because it's in the middle of the
list.
On 10/5/06,
On 5 October 2006 at 14:02, Mark Hindess [EMAIL PROTECTED] wrote:
On 5 October 2006 at 16:39, Alexey Petrenko [EMAIL PROTECTED] w
rote:
Guys,
I'm working on build files for Applet/ImageIO/Print modules contribution...
Number of print modules tests fails if there is no printer in
Easiest way will be to move JpegEncoder.c from awt to imageio module.
Since awt does not really use it.
SY, Alexey
2006/10/5, Mark Hindess [EMAIL PROTECTED]:
On 5 October 2006 at 14:02, Mark Hindess [EMAIL PROTECTED] wrote:
On 5 October 2006 at 16:39, Alexey Petrenko [EMAIL PROTECTED] w
I'd say leave the TODOs alone, at least until we're in a phase where
such polishing up is desired.
Agreed. I've already posted a lot of
// XXX investigate
messages to myself to be read in the future.
Regards,
2006/10/4, Alex Blewitt [EMAIL PROTECTED]:
I use TODOs a lot in my code to remind
You are not alone
2006/10/4, Tim Ellison [EMAIL PROTECTED]:
First time running the AWT/Swing tests for a while. On r452910 I see
the following (one and only) failure on IA32 WinXP:
java.lang.NullPointerException at
On 5 October 2006 at 20:05, Mikhail Fursov [EMAIL PROTECTED] wrote:
The priority of the bug could be the priority of the scenario this bug
affects.
So, we need to select some applications/scenarios and if one of these
applications failed - the bug is blocker or critical.
Major as default
Tim Ellison wrote:
Alexey Petrenko wrote:
We also need to keep Import-Package section up to date...
For sure, and (just to be clear to all) these are not just for Eclipse's
benefit, they are for our benefit as they are the definition of our
class library modularity. When you add a new
On 10/5/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
On 10/5/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
Is this can be a problem? If the base pointer is optimized out and we
will find different object base?
--
Ivan
The base pointer for mptr with unknown offset must live as long as mptr is
Stepan Mishura wrote:
On 10/5/06, Tim Ellison wrote:
Alexey Petrenko wrote:
We also need to keep Import-Package section up to date...
For sure, and (just to be clear to all) these are not just for Eclipse's
benefit, they are for our benefit as they are the definition of our
class library
To maintain unbroken traceability we should commit the original
contribution first then massage it. No objection to the plan.
Regards,
Tim
Mark Hindess wrote:
On 5 October 2006 at 14:02, Mark Hindess [EMAIL PROTECTED] wrote:
On 5 October 2006 at 16:39, Alexey Petrenko [EMAIL PROTECTED] w
Hi!
Currently DRLVM build system suffers from a deficiency,
which gets in the way quickly if you experiment a lot with patches.
If you apply a patch that creates a new file, and build DRLVM,
and then unapply the patch, and rebuild again,
the stale .obj file will still get linked to the
indeed :)
Alexei Zakharov wrote:
Now that we have javac, javah, javap (if Tim votes ;) and keytool, I'd
BTW, we have more tools indeed. I mean RMI tools:
rmic - java org.apache.harmony.rmi.compiler.Main
rmid - java org.apache.harmony.rmi.activation.Rmid
rmiregistry - java
Before you do that... you would be putting similar information in the
build.xml file? Or am I misunderstanding something? having it in the
patternset does make it easy to find stuff :)
geir
Mark Hindess wrote:
Ok. There haven't been any shouts against it so. I'm going to split
the .java
can we get a green light from Andrey and any others in the conversation?
geir
Evgueni Brevnov wrote:
Hi,
I'm working on restoring cunit tests. I already made a good progress
in that direction. So I expect to have it done soon
Evgueni
On 10/4/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
Oh, for a #define :)
Tim Ellison wrote:
Nathan Beyer wrote:
There may be value in doing this, but what's the increase in class file
overhead? Every new class that gets created for these locks ends up as
another class file that has to be stored (takes up drive space) and has to
be loaded (takes
I added all that info into the README file when I did it on windows last
week.
Did I forget to commit it?
Ivan Volosyuk wrote:
Readme is quite helpful. Yesterday, I used google to locate thouse lcms
library.
IMHO, if the build system displayed the link to the README.txt it
could be much
Alex Astapchuk wrote:
Tim Ellison wrote:
Alex Astapchuk wrote:
Hi Stepan, all,
I think the spec. statement: A LoginContext should not be used to
authenticate more than one Subject. was taken too strict: reusing
LoginContext object to get the same set of credentials seemed odd.
The decision
Mark, if you don't care, I'm happy to do it as I'm running through DRLVM
JIRA chains now. Let me know by simply un- or re-assigning
geir
Mark Hindess wrote:
On 5 October 2006 at 13:57, Ivan Volosyuk [EMAIL PROTECTED] wrote:
On 10/4/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
Salikh
Tim Ellison wrote:
We did this topic already g it's even referenced from the website
[1]. So at the risk of repeating my super-super-duper high level view...
Why are we considering putting logging into the class library
implementation?
Darn it! I was hoping that I could beat you to this,
Agreed.
I think that we should outline a set of guidelines, but also realize
that the priority is like beauty - it's in the eyes of the reporter.
I tend to troll through DRLVM JIRAs and do small things like comment or
link, and one thing I'll add to my work is resetting priority based on
On 5 October 2006 at 15:03, Tim Ellison [EMAIL PROTECTED] wrote:
To maintain unbroken traceability we should commit the original
contribution first then massage it. No objection to the plan.
Agreed. I mentioned it because the build code that Alexey is working on
is easier with the new
Salikh Zakirov wrote:
Hi!
Currently DRLVM build system suffers from a deficiency,
which gets in the way quickly if you experiment a lot with patches.
If you apply a patch that creates a new file, and build DRLVM,
and then unapply the patch, and rebuild again,
the stale .obj file will still
Mark Hindess wrote:
On 5 October 2006 at 10:05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Before you do that... you would be putting similar information in the
build.xml file? Or am I misunderstanding something? having it in the
patternset does make it easy to find stuff :)
I'll be
Hi Evgueni,
On 10/4/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
Hi All,
I have attached updated patch to the JIRA. It should resolve remain
concerns. Andrey, could you give a green light now?
Thanks for updating the patch! I agree it it can be committed, at
least signatures look good. 5
It will not easier actually...
Because JpegEncoder.c from awt need few fixes too :)
2006/10/5, Mark Hindess [EMAIL PROTECTED]:
On 5 October 2006 at 15:03, Tim Ellison [EMAIL PROTECTED] wrote:
To maintain unbroken traceability we should commit the original
contribution first then massage it.
woo hoo! here we go...
Andrey Chernyshev wrote:
Hi Evgueni,
On 10/4/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
Hi All,
I have attached updated patch to the JIRA. It should resolve remain
concerns. Andrey, could you give a green light now?
Thanks for updating the patch! I agree it it
If no one objects I'll generify javax.swing to improve API indicators.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Ivan, could this enumeration scenario be possible?
1) JIT reports a base to GC
2) GC relocates the base and updates references.
3) JIT reports MPTR, looks for the base, founds the patched base on the
stack and the resulting offset becomes invalid?
The previous GC (gcv4) did not relocate object
On 5 October 2006 at 18:48, Alexey Petrenko [EMAIL PROTECTED] wrote:
It will not easier actually...
Because JpegEncoder.c from awt need few fixes too :)
I thought I'd fixed it an hour ago in r453231. ;-)
-Mark.
2006/10/5, Mark Hindess [EMAIL PROTECTED]:
On 5 October 2006 at 15:03, Tim
Yep, I've seen that already :)
SY, Alexey
2006/10/5, Mark Hindess [EMAIL PROTECTED]:
On 5 October 2006 at 18:48, Alexey Petrenko [EMAIL PROTECTED] wrote:
It will not easier actually...
Because JpegEncoder.c from awt need few fixes too :)
I thought I'd fixed it an hour ago in r453231. ;-)
Mark,
I've finished with the build files. At least I hope so :)
Check the HARMONY-1729 issue.
I've also added a comment to HARMONY-1609.
SY, Alexey
2006/10/5, Mark Hindess [EMAIL PROTECTED]:
On 5 October 2006 at 16:39, Alexey Petrenko [EMAIL PROTECTED] wrote:
Guys,
I'm working on build
Chris Gray wrote:
Hi Noel,
Does this still include the hardware portability layer? Any synergies with
APR? Does it include the AWT code?
And here is my reply to Noel's message:
Hi Noel,
The code runs on x86, ARM, MIPS, and PowerPC; basically it should run on any
normal 32-bit
Stefano Mazzocchi wrote:
Chris Gray wrote:
Chris,
I personally think it would be *very* nice to have Wonka and friends
donated to the Harmony Project, if only as a starting point for a very
portable and embeddable JVM.
While Harmony is principally aimed at Java Standard Edition, it is not a
+1
On 3 October 2006 at 12:34, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
BCC and ACQs in place.
[ ] +1 Yes, accept the contribution
[ ] -1 No, don't. reason :
As usual, 3 days or until all committers vote, or there is an
objection/request for continuance
Alexey (Ivanov), Alexey (Petrenko), All,
Could anyone please volunteer to resolve this issue
(http://issues.apache.org/jira/browse/HARMONY-100)? Not only it has a
very nice number, but also blocks a fair amount of unit tests.
This shouldn't be incredibly hard - Tim added an excellent comment to
Chris Gray wrote:
On Thursday 05 October 2006 18:00, Geir Magnusson Jr. wrote:
Don't forget that you can have an embeddable SE - it doesn't have to be ME.
Yes, but a full SE nowadays is pretty big. JavaME CDC is basically a defined
subset of SE at the package level, and this is what Wonka
On 5 October 2006 at 17:21, Alexey Petrenko [EMAIL PROTECTED] wrote:
Easiest way will be to move JpegEncoder.c from awt to imageio module.
Since awt does not really use it.
Yes. That's what I did. ;-) (And is why I noticed it was broken.)
-Mark.
2006/10/5, Mark Hindess [EMAIL PROTECTED]:
+1
2006/10/3, Geir Magnusson Jr. [EMAIL PROTECTED]:
BCC and ACQs in place.
[ ] +1 Yes, accept the contribution
[ ] -1 No, don't. reason :
As usual, 3 days or until all committers vote, or there is an
objection/request for continuance
Apologies for drifting off-topic...
Geir Magnusson Jr. wrote:
Stefano Mazzocchi wrote:
Chris Gray wrote:
Chris,
I personally think it would be *very* nice to have Wonka and friends
donated to the Harmony Project, if only as a starting point for a very
portable and embeddable JVM.
While
So what happens to the patch on HARMONY-1723. Do you (Oleg Alexey)
think we should not fix it that way now?
Regards,
Tim
Oleg Khaschansky wrote:
Alexey,
Agree. I haven't noticed that RI doesn't accept invalid write method.
Then its behavior looks illogical. Actually, I asked about
Dear committers,
I have noticed that the following related issues
http://issues.apache.org/jira/browse/HARMONY-1309
http://issues.apache.org/jira/browse/HARMONY-1670
contain patches already - thanks to Alexey Varlamov! These patches are
quite safe to integrate - they even didn't
So what happens to the patch on HARMONY-1723.
My opinion is that it is OK. Consider the following:
1. Applications bounded to the RI behavior (e.g. obtaining the
descriptors for read-only properties without construction of getter
name) won't fail.
2. Construction of the default getter/setter
FWIW I counted 35 cases in the entire class library.
Tim
Tim Ellison wrote:
Nathan Beyer wrote:
There may be value in doing this, but what's the increase in class file
overhead? Every new class that gets created for these locks ends up as
another class file that has to be stored (takes up
Alexey,
OK, we will check this issue tomorrow. Could you add [drlvm][jit] prefix
next time reporting JIT issues, so we can find and fix such issues faster?
On 10/6/06, Fedotov, Alexei A [EMAIL PROTECTED] wrote:
Egor, Alex,
Please, could you volunteer to look into
Artem, Andrey, Nikolay,
Let me attract your attention the following recent issue:
http://issues.apache.org/jira/browse/HARMONY-1669.
Please, could any of you volunteer to make a patch? Thank you in
advance.
With best regards,
Alexei Fedotov,
Intel Middleware Products Division
Hello, Ivan!
You wrote,
why my authorship was discarded from interpreter.cpp?
The authorship is not easily discarded - there are times when others are
painfully trying to recall who have written that code. :-) Could you
please look into the following issue with the interpreter, reported by
2006/10/5, Mark Hindess [EMAIL PROTECTED]:
On 5 October 2006 at 19:51, Alexey Petrenko
[EMAIL PROTECTED] wrote:
Mark,
I've finished with the build files. At least I hope so :)
Check the HARMONY-1729 issue.
I've also added a comment to HARMONY-1609.
Excellent!
This is trivial but I
Hi, Nadya,
I tried to build DRLVM, faced the issue from the thread below, and filed a JIRA
issue: https://issues.apache.org/jira/browse/HARMONY-1730. Does the patch worth
to be applied to the README.txt?
With best regards,
Alexei Fedotov,
Intel Middleware Products Division
-Original
BTW,
I really enjoyed the last item of the Quick Start section:
7. If building the DRLVM fails, read this README and follow building
instructions to the point.
A hardcore programmer can loop infinitely here. :-)
With best regards,
Alexei Fedotov,
Intel Middleware Products Division
Yes. It's a test.
Fedotov, Alexei A wrote:
BTW,
I really enjoyed the last item of the Quick Start section:
7. If building the DRLVM fails, read this README and follow building
instructions to the point.
A hardcore programmer can loop infinitely here. :-)
With best regards,
I managed to unpack a Pack200 file completely today for the first
time, so that by the end of it there were no bytes left in the queue.
Unfortunately, it wasn't a spectacularly exciting archive -- just one
interface with no methods (about as exciting as
java.lang.Serializable, in fact) but I
Congratulations! Excellent!
geir
Alex Blewitt wrote:
I managed to unpack a Pack200 file completely today for the first
time, so that by the end of it there were no bytes left in the queue.
Unfortunately, it wasn't a spectacularly exciting archive -- just one
interface with no methods (about
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Tim Ellison wrote:
We did this topic already g it's even referenced from the website
[1]. So at the risk of repeating my super-super-duper high level
view...
Why are we considering putting logging into
I have been unable to figure out why I can't get the drlvm to run
helloworld. The classlib with Intel's VM works fine.
So now I thought I'd just see if I could download the binary and execute it
(JRE), but it is behaving the same way (I guess this is to be expected, but
I just wanted to
1 - 100 of 104 matches
Mail list logo
