On 2/19/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Mikhail Loenko wrote:
What is the goal of spec-compatibility for exceptions?
1. Existing applications that work well on Sun's Java might fail on Harmony.
Right - this is a problem. People will say that we're broken. It's not
a
On 2/19/06, karan malhi [EMAIL PROTECTED] wrote:
Geir Magnusson Jr wrote:
Well, I don't really know if Sun would do that. There is an expert
group that Sun has to deal with...
But if it did happen, yes, we'd have to fix our code.
I agree. Whatever experience I've had with java till
Hi Archie and Ivan,
Archie Cobbs wrote:
Today I've made changes to eliminate the requirement that
_JC_FULL_ALIGNMENT
be at most sizeof(_jc_word), so this will fix the assertion in heap.c.
hope that doesn't sacrifice any of the features of jchevm
As for the failure to exit properly, this
Anton
still no answer to: What is the goal of that firm spec compatibility?
Are you sure that if some usage scenario does not make sense for you
and for all progressive people in the world then there no application working
this way?
Think of the following: we release Harmony, people will try
Hi James,
in case if you are not aware yet I'd like to mention the HARMONY-39
contribution
contains the full implementation for java.math package (both BigInteger
BigDecimal).
Thanks,
Vladimir Gorr,
Intel Middleware Products Division.
On 2/18/06, James Pluck [EMAIL PROTECTED] wrote:
Geir
Geir,
As far as you deleted drl.policyminor adjustments should be made for java.security file and ant script files. (I don't know whether you keep this in mind or not, so please take this as friend reminder. Also I attached a patch file to fix some places I've noticed)
Thanks,Stepan MishuraIntel
[
http://issues.apache.org/jira/browse/HARMONY-70?page=comments#action_12367017 ]
Vladimir Strigun commented on HARMONY-70:
-
Look like this issue already have been fixed in Harmony-42. I can't reproduce
it with the latest sources.
On 2/20/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
Anton
still no answer to: What is the goal of that firm spec compatibility?
Are you sure that if some usage scenario does not make sense for you
and for all progressive people in the world then there no application working
this way?
Well seems like we all agree with the general approach.
But...
:)
I do not agree with the specific case you describe: NPE vs. IAE.
I can imagine a programmer who does not read the spec, who
does not want to check for null, who just makes 'catch NPE' somewhere
And his app would work well on RI
It might also be worth nothing that if you are licensed to use the
tck, there is an appeal process, so it may be possible to make sun
accept deviation from the spec or unreasonable claims in the spec, on
their part, on a case by case basis.
But i suppose the real test is how well it runs existing
On 2/20/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
Well seems like we all agree with the general approach.
Yes. Agree.
But...
:)
I do not agree with the specific case you describe: NPE vs. IAE.
I can imagine a programmer who does not read the spec, who
does not want to check for null,
[
http://issues.apache.org/jira/browse/HARMONY-64?page=comments#action_12367024 ]
Tim Ellison commented on HARMONY-64:
Svetlana,
We have decided to defer this fix until the next official release of ICU4JNI
becomes available. Let us know if this is a
[ http://issues.apache.org/jira/browse/HARMONY-70?page=all ]
Tim Ellison resolved HARMONY-70:
Resolution: Duplicate
Thanks Vladimir.
Marking resolved as part of HARMONY-42.
java.io.FileInputStream.close() must close channel associated with this
[ http://issues.apache.org/jira/browse/HARMONY-70?page=all ]
Tim Ellison closed HARMONY-70:
--
java.io.FileInputStream.close() must close channel associated with this
FileInputStream
On 2/20/06, Gerry Steele [EMAIL PROTECTED] wrote:
It might also be worth nothing that if you are licensed to use the
tck, there is an appeal process, so it may be possible to make sun
accept deviation from the spec or unreasonable claims in the spec, on
their part, on a case by case basis.
I agree Anton, these are the right guiding principles and the proof will
be in running apps.
Regards,
Tim
Anton Avtamonov wrote:
On 2/20/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
Well seems like we all agree with the general approach.
Yes. Agree.
But...
:)
I do not agree with the
On 2/20/06, Anton Avtamonov [EMAIL PROTECTED] wrote:
On 2/20/06, Gerry Steele [EMAIL PROTECTED] wrote:
It might also be worth nothing that if you are licensed to use the
tck, there is an appeal process, so it may be possible to make sun
accept deviation from the spec or unreasonable claims
[
http://issues.apache.org/jira/browse/HARMONY-64?page=comments#action_12367029 ]
Svetlana Samoilenko commented on HARMONY-64:
Tim, I have no objection. Let's wait.
java.nio.charset.Charset.forName(String name) does not throw
On 2/20/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
How will we verify Harmony with all existing apps in the world?
Certainly there is no way to verify Harmony with all existing apps
ourselves. But, it looks like we do have a bug reporting system which
would allow Harmony users to let us know
/linux.IA32/icu4c-3.4-harmony.zip
into
/home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/native-src/linux.IA32
make-clean:
make-all:
timestamp:
[echo] build-date=20060220
[echo] build-time=20060220_1104)
[echo] on platform=Linux version=2.6.8-2-386 arch=x86
[echo
java.text.DecimalFormat does not parse infinite values correctly
Key: HARMONY-106
URL: http://issues.apache.org/jira/browse/HARMONY-106
Project: Harmony
Type: Bug
Reporter: Richard Liang
In Java
As mentioned in Java 5.0 New Features:
The DecimalFormat class has been enhanced to format and parse BigDecimal
and BigInteger values without loss of precision. Formatting of such
values is enhanced automatically; parsing into BigDecimal needs to be
enabled using the setParseBigDecimal
I would support Mikhail. If we are aware of bug in RI there might be a few
cases. First, we suppose we're really better than RI not having this bug.
The second one is the case being discussed. When it basically does not
matter that much but we're considering being either spec or bug compatible.
In my opinion we should not wait when Harmony users let us know about our
incompatibility.
We need to hurry and to eliminate this as soon as possible. Otherwise we
will not be successful.
All existent (well-known) applications have been already tuned for RI.
Therefore we also need to carry for
Enrico Migliore wrote:
Archie Cobbs wrote:
Today I've made changes to eliminate the requirement that
_JC_FULL_ALIGNMENT
be at most sizeof(_jc_word), so this will fix the assertion in heap.c.
hope that doesn't sacrifice any of the features of jchevm
Nope.. it's all gain and no pain :-)
Hello, Enrico
2) in order to proceed, let's align our development environment in terms
of source code modifications. In fact, to build jchevm, just like you,
I had
to add some declarations in some header files, and modify the pread()
call into a read(). My proposal is the following:
let's
snowdosker wrote:
Hello, Enrico
2) in order to proceed, let's align our development environment in
terms
of source code modifications. In fact, to build jchevm, just like
you, I had
to add some declarations in some header files, and modify the pread()
call into a read(). My proposal is
Archie, Geir and Stefano,
could you please take a look at the following assertion and correct it
if it's wrong:
It's worth to remember, that the goal of porting JCHEVM to Cygwin/Windows,
is to enable us, and the people interested, to have a development
environment on Windows,
in order to
Mark Hindess wrote:
Hi,
Is there any interest in having build status emails sent to this list?
Well we've discussed this privately, but for the record yes! I'd like
to see build results posted to the dev list when the build is
broken/repaired.
I'm building classlib trunk with continuum and
Thanks, I had initially read over the additional restriction on the
first character.
This strikes me as one of those cases where the reference impl. wins
over the specification. I think Svetlana's test was written to the
spec. If we discover an app that relies upon isSupported throwing an
[ http://issues.apache.org/jira/browse/HARMONY-98?page=all ]
Tim Ellison reassigned HARMONY-98:
--
Assign To: Tim Ellison
java.util.BitSet.clear(int toIndex,int fromIndex) throws unexpected
IndexOutOfBoundsException when toIndex=fromIndex
[ http://issues.apache.org/jira/browse/HARMONY-98?page=all ]
Tim Ellison resolved HARMONY-98:
Resolution: Fixed
Svetlana,
Fixed in LUNI module java.util.BitSet at repo revision 379184.
Please check that this fully resolves your problem.
[ http://issues.apache.org/jira/browse/HARMONY-51?page=all ]
Tim Ellison reassigned HARMONY-51:
--
Assign To: Tim Ellison
java.io.Writer : write(String) should write String as atomic operation.
Enrico Migliore wrote:
Archie, Geir and Stefano,
could you please take a look at the following assertion and correct it
if it's wrong:
It's worth to remember, that the goal of porting JCHEVM to Cygwin/Windows,
is to enable us, and the people interested, to have a development
[ http://issues.apache.org/jira/browse/HARMONY-102?page=all ]
Tim Ellison reassigned HARMONY-102:
---
Assign To: Tim Ellison
java.util.Date.parse(String) throws java.lang.IllegalArgumentException for
legal string
[ http://issues.apache.org/jira/browse/HARMONY-102?page=all ]
Tim Ellison resolved HARMONY-102:
-
Resolution: Fixed
Patch looks good - -thank you Vladimir.
Svetalana,
Fixed in LUNI module java.util.Date at repo revision 379197.
Please check this
removing unused targets/variables from linux makefiles
--
Key: HARMONY-108
URL: http://issues.apache.org/jira/browse/HARMONY-108
Project: Harmony
Type: Improvement
Components: Classlib
Reporter: Mark
[ http://issues.apache.org/jira/browse/HARMONY-108?page=all ]
Mark Hindess updated HARMONY-108:
-
Attachment: harmony.remove.unused.targets.and.variables.diff
(Do deletions really count as a contribution. ;-)
removing unused targets/variables from
reducing the verbose auto-generated variable names in linux makefiles
-
Key: HARMONY-109
URL: http://issues.apache.org/jira/browse/HARMONY-109
Project: Harmony
Type: Improvement
Components:
[ http://issues.apache.org/jira/browse/HARMONY-109?page=all ]
Mark Hindess updated HARMONY-109:
-
Attachment: harmony.reduce.variables.diff
reducing the verbose auto-generated variable names in linux makefiles
fixing the clean targets in linux makefiles
---
Key: HARMONY-110
URL: http://issues.apache.org/jira/browse/HARMONY-110
Project: Harmony
Type: Improvement
Components: Classlib
Reporter: Mark Hindess
Priority:
[ http://issues.apache.org/jira/browse/HARMONY-110?page=all ]
Mark Hindess updated HARMONY-110:
-
Attachment: harmony.fix.clean.targets.diff
fixing the clean targets in linux makefiles
---
Key:
On 2/17/06, Tim Ellison [EMAIL PROTECTED] wrote:
do you have any examples (i.e. snippets of a non-trivial Ant script)
that show what it would end up like? I'm trying to figure out in my own
head whether it would be a few general regex selectors, or a load of
them! I think you may be do it
Mark Hindess mark.hindess at googlemail.com writes:
Is there any interest in having build status emails sent to this list?
I'm building classlib trunk with continuum and it would be simple for
me to have messages like the following sent to the list whenever the
status of our builds change.
/linux.IA32/icu4c-3.4-harmony.zip
into
/home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/native-src/linux.IA32
make-clean:
make-all:
timestamp:
[echo] build-date=20060220
[echo] build-time=20060220_1104)
[echo] on platform=Linux version=2.6.8-2-386 arch=x86
[echo
Stuart Ballard wrote:
Mark Hindess mark.hindess at googlemail.com writes:
Is there any interest in having build status emails sent to this list?
I'm building classlib trunk with continuum and it would be simple for
me to have messages like the following sent to the list whenever the
status of
Tim Ellison wrote:
Enrico Migliore wrote:
Archie, Geir and Stefano,
could you please take a look at the following assertion and correct it
if it's wrong:
It's worth to remember, that the goal of porting JCHEVM to Cygwin/Windows,
is to enable us, and the people interested, to have a
thanks for the pointer
Fernando Cassia wrote:
FYI:
http://fobs.sourceforge.net/
http://sourceforge.net/project/showfiles.php?group_id=105646package_id=117443release_id=352645
FOBS is an object oriented wrapper for *ffmpeg* library. Build easily object
oriented applications that work with
Will it use a maven repository? This sounds like a lot of the
functionality in Maven. Whether you like Maven or not, the fact that
there are large repositories of jars is great, so I hope your friend
will take advantage of that.
David Tanzer wrote:
A friend of mine is currently developing a
This actually sounds a lot like Ivy to me. We used jpackage to
accomplish a good portion of this back at redhat, but at Peopleclick,
we are moving towards an ivy-centered approach.
Ryan
On 2/20/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Will it use a maven repository? This sounds like a
I need to read the whole thread (will do it on plane tomorrow) but just
a couple of quick notes...
Vladimir Gorr wrote:
In my opinion we should not wait when Harmony users let us know about our
incompatibility.
We need to hurry and to eliminate this as soon as possible. Otherwise we
will not
I glanced through a local server code from HARMONY-57 contribution without
looking into implementation details and ... this made me think. I catch hold
of the following:
1) The server contains some testing code that looks not good for me
2) It is not as simple as I expected - my impression was
classlib snapshot target
Key: HARMONY-111
URL: http://issues.apache.org/jira/browse/HARMONY-111
Project: Harmony
Type: New Feature
Components: Classlib
Reporter: Mark Hindess
Priority: Trivial
We need a snapshot target to make
[ http://issues.apache.org/jira/browse/HARMONY-111?page=all ]
Mark Hindess updated HARMONY-111:
-
Attachment: harmony.snapshot.target.diff
classlib snapshot target
Key: HARMONY-111
URL:
On 21/02/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Mark Hindess wrote:
Hi,
Is there any interest in having build status emails sent to this list?
I'm building classlib trunk with continuum and it would be simple for
me to have messages like the following sent to the list
55 matches
Mail list logo
