George Harley wrote:
Hi Mikhail (again),
Just a couple of brief observations about the SerializationTest.java
code as it stands in SVN today :
1) The reference/golden .dat files for Serializable classes in a given
module could be added under the module's src/test/resources directory
(in sub
On 3/9/06, Oliver Deakin <[EMAIL PROTECTED]> wrote:
> Time to resurrect this thread again :)
We'll have to try to kill it properly this time. ;-)
> With the work that Mark and I have been doing in HARMONY-183/155/144/171
> we will be at a point soon where all the shared code has been taken out
>
"Magnusson, Geir" wrote
I don't think that you can do full j.u.c w/o support from the vm.
I agree on that.
Are you saying that what is there works w/ the oswego code?
No, our (java.rmi) code does not work with it; the oswego code
does not support generics and it is not compliant with the spe
Hi Mikhail (again),
Just a couple of brief observations about the SerializationTest.java
code as it stands in SVN today :
1) The reference/golden .dat files for Serializable classes in a given
module could be added under the module's src/test/resources directory
(in sub-folders corresponding
On 3/10/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
>
> Anyway we can think about redundant initialization as a bad style,
In Java at least, for the natives I submitted a JIRA to fix some of
initializations in the natives (HARMONY-185). Would you say they are
redundant there too? Personally I
On 3/10/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
> not sure what you mean here Weldon, that stuff is regular class library
> native code, not VM-specific at all. They may use JNI calls into the
> VM, and/or the VMI interface to get the portlib etc. but the same code
> should work ok on all VMs.
2006/3/10, Mikhail Loenko <[EMAIL PROTECTED]>:
> Anyway we can think about redundant initialization as a bad style,
I think that all redundant tasks are bad style...
--
Alexey A. Petrenko
Intel Middleware Products Division
Mark and Chris
Thank you very much for your warm heart. I checked out Wiki's online
help, and it is true, the WikiName will be rendered as link
automatically, but unluckily the "~" prefix doesn't work:(. I find two
solutions from the document
1. insert six consecutive single quotes, like this:
On Fri, Mar 10, 2006 at 11:41:11AM -0600, Archie Cobbs wrote:
> Weldon Washburn wrote:
> >>Either solution is OK with me, but I'd much prefer #1 because it's
> >>cleaner code and I'd rather not start adding hacks at this point that
> >>move us away from the current common API.
> >
> >I agree that #
Weldon Washburn wrote:
Either solution is OK with me, but I'd much prefer #1 because it's
cleaner code and I'd rather not start adding hacks at this point that
move us away from the current common API.
I agree that #1 is the cleanest, easiest technical approach. The
difficulty is convincing an
Mikhail Loenko wrote:
2006/3/9, George Harley <[EMAIL PROTECTED]>:
...
Such a testing effort still sounds pretty daunting though.
BTW, there is a framework for serialization testing which is currently
in the security module:
modules/security/test/common/unit/org/apache/harmony/securit
On 3/10/06, Archie Cobbs <[EMAIL PROTECTED]> wrote:
> Weldon Washburn wrote:
> > Please take a look at bootstrap.c It would be great if we can do the
> > final integration in the next 2 days while this code is still fresh in
> > my mind.
>
> Looks reasonable, you just commented out or changed the
Tim Ellison wrote:
Iris Gastañaga wrote:
Hi Tim,
We have read the contribution policy and we are ready to sign
the following documents -we've questions on some of them, so please
advice-:
I'll try to help, but with the standard disclaimer that IANAL, so you
need to be comfortable with th
Iris Gastañaga wrote:
> Hi Tim,
> We have read the contribution policy and we are ready to sign
> the following documents -we've questions on some of them, so please
> advice-:
I'll try to help, but with the standard disclaimer that IANAL, so you
need to be comfortable with the terms and cond
not sure what you mean here Weldon, that stuff is regular class library
native code, not VM-specific at all. They may use JNI calls into the
VM, and/or the VMI interface to get the portlib etc. but the same code
should work ok on all VMs.
Regards,
Tim
Weldon Washburn wrote:
> Class Lib developer
Class Lib developers,
To make porting Harmony Class Lib to non-Harmony JVMs easier, it would
be great if all the java code that declares native methods was in one
place. For the JCEVM port, I added most of the required native method
declarations directly to the kernel directory. I suggest moving
Weldon Washburn wrote:
Please take a look at bootstrap.c It would be great if we can do the
final integration in the next 2 days while this code is still fresh in
my mind.
Looks reasonable, you just commented out or changed the classes
and methods that would not load yet.
What's the plan for
Could be time to do another snapshot, but like Mark says, you can also
rebuild from scratch.
Let me know if you still have problems.
Regards,
Tim
Mark Hindess wrote:
> I can see why this might be a problem. Hopefully Tim upload a new
> snapshot later. In the meantime, you could try "ant -f mak
Weldon Washburn wrote:
> On 3/9/06, Archie Cobbs <[EMAIL PROTECTED]> wrote:
>> Weldon Washburn wrote:
>>> I can now run the below multithread Hello.java on JCHEVM using Apache
>>> Harmony Class Library. The output toggles between clumps of "Hello
>>> World" and clumps of "*" as WindowsXP schedules
On Fri, Mar 10, 2006 at 04:37:16AM -0800, Leo Simons wrote:
> On Wed, Mar 08, 2006 at 03:49:36PM -0800, Weldon Washburn wrote:
> > I can now run the below multithread Hello.java on JCHEVM using Apache
> > Harmony Class Library.
>
> Cool!
>
contratulations from my side as well, excellent work!
c
On Wed, Mar 08, 2006 at 03:49:36PM -0800, Weldon Washburn wrote:
> I can now run the below multithread Hello.java on JCHEVM using Apache
> Harmony Class Library.
Cool!
> Runtime.java -- expected "wrapper" code. e.g., add VMRuntime.exit() to
> Runtime.exit()
> Method.java, Field.java, Constructor.
Hi Mikhail!
On Thu, Mar 09, 2006 at 10:34:46AM +0600, Mikhail Loenko wrote:
> Actually there are important things that are to be tracked in JIRA.
Err...here's that rule again:
Really Important Things MUST Go In SVN And/Or Onto The Public Mailing List
For example, with the accepting of externa
On 3/10/06, Paulex Yang <[EMAIL PROTECTED]> wrote:
>
> > 1) java/io/InputStreamReader.
> > getHistoricalName(String name) should not be public I think.
> >
> the getHistoricalName(String) is not method of InputStreamReader, but a
> method of package private internal class
> InputStreamReader.Histor
Paulex,
see my comments below.
On 3/10/06, Paulex Yang <[EMAIL PROTECTED]> wrote:
>
> Stepan Mishura wrote:
> > Hi Paulex,
> >
> >
> >> Currently, we have three options:
> >> 1. let it be, and speak it loudly in Harmony JavaDoc
> >>
> >>
> >
> > I'd choose this option. It is open and honest - if
I have discovered this issue when I was investigating why
my implementation of I don't remember what demonstrates
10x worse performance then I expected.
I had a class with empty constructor and a dozen of private fields
initialized by null.
I used JRockit 1.5 - rather a modern VM.
AFAIK JLS does
Mikhail,
It's great that we consider performance of the API lib. Let me give
you just a couple of things to keep in mind in addition to your
observation.
Firstly, it all depends on the VM implementation which executes the
code. For modern VMs, bytecode is far from what is actually executed,
unles
Kononov,
Thank you to point out these. My comments below.
Dmitry M. Kononov wrote:
Paulex,
I have some thoughts about the patch. It looks good but the following two
things:
1) java/io/InputStreamReader.
getHistoricalName(String name) should not be public I think.
the getHistoricalName(Stri
Richard Liang wrote:
Stepan Mishura wrote:
Hi Paulex,
Currently, we have three options:
1. let it be, and speak it loudly in Harmony JavaDoc
I'd choose this option. It is open and honest - if we get unknown
class for
deserialization (say sun.util.calendar.ZoneInfo or
com.someCompan
Paulex Yang wrote:
Stepan Mishura wrote:
Hi Paulex,
Currently, we have three options:
1. let it be, and speak it loudly in Harmony JavaDoc
I'd choose this option. It is open and honest - if we get unknown
class for
deserialization (say sun.util.calendar.ZoneInfo or
com.someCompanyN
Geir - I'm not really sure how this would work. The wiki is good because
it's quick, (relatively) easy to update and people who don't have
committer status can say what they are doing. The web pages are good for
information that doesn't change so fast, but I think they'd just be
constantly out
Mikhail Loenko wrote:
Hello
May be it is obvious and everybody knows it from babyhood, but anyway...
Everybody knows that this two examples of code do the same:
class test {
public Object field = null;
}
and
class test {
public Object field;
}
But if you disassemble these two classes,
2006/3/9, George Harley <[EMAIL PROTECTED]>:
...
> Such a testing effort still sounds pretty daunting though.
BTW, there is a framework for serialization testing which is currently
in the security module:
modules/security/test/common/unit/org/apache/harmony/security/test/SerializationTest.java
I
Stepan Mishura wrote:
Hi Paulex,
Currently, we have three options:
1. let it be, and speak it loudly in Harmony JavaDoc
I'd choose this option. It is open and honest - if we get unknown class for
deserialization (say sun.util.calendar.ZoneInfo or
com.someCompanyName.util.MyTimeZone)
George Harley wrote:
Paulex Yang wrote:
Mikhail
Mikhail Loenko wrote:
2006/3/7, Geir Magnusson Jr <[EMAIL PROTECTED]>:
This is somewhat terrifying, isn't it? Are there really references to
com.sun.* in serialized API objects?
Yes, there are.
For example, TimeZone.ser produced by the
Stepan Mishura wrote:
Hi Paulex,
Currently, we have three options:
1. let it be, and speak it loudly in Harmony JavaDoc
I'd choose this option. It is open and honest - if we get unknown class for
deserialization (say sun.util.calendar.ZoneInfo or
com.someCompanyName.util.MyTimeZone)
35 matches
Mail list logo
