Re: Platform move to LUNI causing issues?
I can see why this might be a problem. Hopefully Tim upload a new snapshot later. In the meantime, you could try "ant -f make/build.xml snapshot" to make one yourself. Regards, Mark. On 3/9/06, Nathan Beyer <[EMAIL PROTECTED]> wrote: > > Ever since the "Platform" class (and others??) changed/moved to the LUNI > module I can't run against the last SNAPSHOT build (from Feb.). I just keep > getting this error. > > > > Exception in thread "main" java/lang/UnsatisfiedLinkError: > org/apache/harmony/luni/platform/OSMemory.getPointerSizeImpl()I > >at org/apache/harmony/luni/platform/OSMemory. > (OSMemory.java:64) > >at java/lang/J9VMInternals.initializeImpl (Native Method) > >at java/lang/J9VMInternals.initialize (J9VMInternals.java:153) > >at > org/apache/harmony/luni/platform/OSComponentFactory.getMemorySystem > (OSComponentFactory.java:38) > >at org/apache/harmony/luni/platform/Platform. > (Platform.java:32) > >at java/lang/J9VMInternals.initializeImpl (Native Method) > >at java/lang/J9VMInternals.initialize (J9VMInternals.java:153) > >at java/io/FileOutputStream. (FileOutputStream.java:47) > >at java/lang/System. (System.java:55) > >at java/lang/J9VMInternals.initializeImpl (Native Method) > >at java/lang/J9VMInternals.initialize (J9VMInternals.java:153) > >at java/lang/ClassLoader.initializeClassLoaders (ClassLoader.java:78) > >at java/lang/Thread.initialize (Thread.java:359) > >at java/lang/Thread. (Thread.java:157) > > JVMJ9VM015W Initialization error for library jclclear_23(14): JVMJ9VM009E > J9VMDllMain failed > > HMYEXEL062E Internal VM error: Failed to create Java VM > > FAILED. > > > > Maybe I'm completely off and I'm just missing something; please let me know. > If what I need is a new build of some of the native components, which is > what I suspect, I would like to kindly ask for a new SNAPSHOT build, if it's > not too much trouble. > > > > Thanks, > > -Nathan > > > > > -- Mark Hindess <[EMAIL PROTECTED]> IBM Java Technology Centre, UK.
Re: Component status pages
2006/3/8, zoe slattery <[EMAIL PROTECTED]>: > Hey - looks great Nathan! I'll tidy up the JLM one to look similar > > Paulex - it looks to me as though you could create a similar page for > the NIO, is that right? > > Vladimir - is it you who is mainly looking at security? How about a > similar page on what you are doing? I'm volunteering to make a page for security/crypto/x-net/auth/related providers Thanks, Mikhail
Re: jira messages redirected to commits mailing list (was: [jira] Updated: (HARMONY-188) ...)
Actually there are important things that are to be tracked in JIRA. For example, questions of being non-compatible with either RI or spec. And as far as the mail traffic on the dev-list is doubling every month [1] it would be great to make it possible to separate those JIRA issues that describe minor bugs/fixes from these ones that have conceptual value. Is it possible? Thanks, Mikhail. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/ 2006/3/7, S. Meslin-Weber <[EMAIL PROTECTED]>: > On Tue, Mar 07, 2006 at 09:19:54AM -0800, Craig Blake wrote: > > Sweet, many thanks. > > +1, I wasn't being flooded but it's nice to be able to separate these > flows without client-side filters. > > Steph > > -- > > Stephane Meslin-Weber Email: [EMAIL PROTECTED] > Senior Software Engineer Web: http://odonata.tangency.co.uk > > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.1 (GNU/Linux) > > iD8DBQFEDcGV5QGfd9PDUN0RAhcUAJ9FFfB5zsxEiDxo0r/UkRCHobAU8ACfZGy2 > 9gq36aAlp5OfoHW/hyoyU4s= > =jI+O > -END PGP SIGNATURE- > > >
Platform move to LUNI causing issues?
Ever since the "Platform" class (and others??) changed/moved to the LUNI module I can't run against the last SNAPSHOT build (from Feb.). I just keep getting this error. Exception in thread "main" java/lang/UnsatisfiedLinkError: org/apache/harmony/luni/platform/OSMemory.getPointerSizeImpl()I at org/apache/harmony/luni/platform/OSMemory. (OSMemory.java:64) at java/lang/J9VMInternals.initializeImpl (Native Method) at java/lang/J9VMInternals.initialize (J9VMInternals.java:153) at org/apache/harmony/luni/platform/OSComponentFactory.getMemorySystem (OSComponentFactory.java:38) at org/apache/harmony/luni/platform/Platform. (Platform.java:32) at java/lang/J9VMInternals.initializeImpl (Native Method) at java/lang/J9VMInternals.initialize (J9VMInternals.java:153) at java/io/FileOutputStream. (FileOutputStream.java:47) at java/lang/System. (System.java:55) at java/lang/J9VMInternals.initializeImpl (Native Method) at java/lang/J9VMInternals.initialize (J9VMInternals.java:153) at java/lang/ClassLoader.initializeClassLoaders (ClassLoader.java:78) at java/lang/Thread.initialize (Thread.java:359) at java/lang/Thread. (Thread.java:157) JVMJ9VM015W Initialization error for library jclclear_23(14): JVMJ9VM009E J9VMDllMain failed HMYEXEL062E Internal VM error: Failed to create Java VM FAILED. Maybe I'm completely off and I'm just missing something; please let me know. If what I need is a new build of some of the native components, which is what I suspect, I would like to kindly ask for a new SNAPSHOT build, if it's not too much trouble. Thanks, -Nathan
[jchevm] Harmony Class Lib does "Hello World" on a GNU Classpath JVM
Archie,
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 the two application
threads. This is behavior I would expect. I use System.out.write()
because System.out.println() does not work yet. A summary follows:
Mods to JCHEVM to get it to work
1)
I was not able to find the _JC_LIB_ENTRY that is intended for
read/writing files. I gave up and "borrowed"
JCNI_java_lang_VMThread_nativeSetPriority(). Instead of actually
changing thread priority, it now does a "fprintf(stdout, "%s",
&priority); fflush(stdout);" Perhaps you can tell me what native
method I should be using.
2)
I commented out some stuff in bootstrap.c that was dragging in
specific gnu classpath *.class files like "Lgnu/classpath/Pointer;"
We should discuss the best solution for this item.
Harmony Class Lib that were modified to get it to work:
Runtime.java -- expected "wrapper" code. e.g., add VMRuntime.exit() to
Runtime.exit()
Method.java, Field.java, Constructor.java -- minor mods
System.java -- added VMSystem.setOut, setErr... etc
ThreadGroup.java -- wrappers
Class.java -- wrappers
Object.java -- wrappers
String.java -- implemented a very simple intern()
Thread.java -- added a bunch of fields that JCHEVM accesses, added
code to start() to create ThreadGroup.root if it does not already
exist
Throwable.java -- wrappers
ClassLoader.java -- commented out "abstract" keyword on class
definition (too lazy to create a sub-class), added fields that JCHEVM
accesses, added code getSystemClassLoader to actually create an object
and stuff it in systemClassLoader if it does not already exist. added
a bunch of wrapper code.
OSMemory -- hacked out a bunch of stuff that was in the way
OSFileSystem -- add an ugly hack in writeImpl() to revector chars to
Thread.setPriority()
One last item. I don't know which SVN repository to place this work
in. Any suggestions?
Thanks
Weldon
##
class Hello extends Thread {
public static void main(String args[])
{
byte [] ba = new byte[64];
ba [0] = 'H'; ba [1] = 'e'; ba [2] = 'l'; ba [3] = 'l'; ba [4] = 'o';
ba [5] = ' '; ba [6] = 'W'; ba [7] = 'o'; ba [8] = 'r'; ba [9] =
'l'; ba[10] = 'd'; ba[11] = ' ';
Thread tr = new Hello();
tr.start();
while (true) {
for (int qq = 0; qq < 12; qq++) {
System.out.write(ba[qq]);
}
}
}
public void run() {
while(true) {
System.out.write('*');
}
}
}
--
Weldon Washburn
Intel Middleware Products Division
Re: enhanced/classlib/trunk/depends
Tim Ellison wrote: Jean-frederic Clere wrote: Mark Hindess wrote: Using "touch .now; sleep 2; (cd make; ant) ; find depends ... \! -anewer .now" on both builds shows that the only files that aren't accessed by either build are the README files and: depends/files/java.security That probably isn't needed since the build uses: modules/security/src/java.home/lib/security/java.security instead. But that's the only one that's obviously redundant. Yep... I would prefer to classlib depends directory a readme that tells classlib depends on: CU4C version 3.4 (how to get and install it). ICU4JNI FDLIBM zlib Like this? http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/depends/oss/README.txt?view=markup The README.txt doesn't tell how depends/jars/icu4j_3_4.jar is build, does it? Cheers Jean-Frederic Regards, Tim Cheers Jean-Frederic Regards, Mark. On 04/03/06, Jean-frederic Clere <[EMAIL PROTECTED]> wrote: Hi, There are a lot of objects in this repos directory, do we really need them? Cheers Jean-Frederic -- Mark Hindess <[EMAIL PROTECTED]> IBM Java Technology Centre, UK.
Re: ITC's Contribution
I don't think that you can do full j.u.c w/o support from the vm. Are you saying that what is there works w/ the oswego code? It ok if its not complete... We can continue w it once we get a v5 vm. Note to all - no need to only contribute things that are complete. We're also glad to have incomplete things in svn that people are working on / contributing to here in the project Geir -Original Message- From: Daniel Gandara [mailto:[EMAIL PROTECTED] Sent: Wed Mar 08 12:26:18 2006 To: harmony-dev@incubator.apache.org Subject:Re: ITC's Contribution >> Tim Ellison wrote: >> i.e. have you tried running it with the original code (EDU.oswego.cs.dl) >> from Doug's website or only the concurrent utils in 5.0 (JSR166)? >> > Daniel Gandara wrote: > we have only tried with the concurrent utils in 5.0, but we will try with > Doug's and see how it behaves, I'll let you know. As promised, we've checked EDU.oswego.cs.dl.util.concurrent package ( http://g.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html) and while it works beautifully, it seems to not be compliant with the specs for java.util.concurrent (e.g. it is missing some pieces, such as ThreadPoolExecutor, etc). Therefore, I am hesitant of adapting our harmony-compliant package to it, as it may not be acceptable by Harmony once we are done. What do you think? As stated above, we've checked with JSR166 (http://gee.cs.oswego.edu/dl/concurrency-interest/index.html ) and we are ok with it, since it complies with the spec. However, I am not sure we can use this as part of Harmony, can we? Daniel
Re: ITC's Contribution
Tim Ellison wrote: i.e. have you tried running it with the original code (EDU.oswego.cs.dl) from Doug's website or only the concurrent utils in 5.0 (JSR166)? Daniel Gandara wrote: we have only tried with the concurrent utils in 5.0, but we will try with Doug's and see how it behaves, I'll let you know. As promised, we've checked EDU.oswego.cs.dl.util.concurrent package ( http://g.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html) and while it works beautifully, it seems to not be compliant with the specs for java.util.concurrent (e.g. it is missing some pieces, such as ThreadPoolExecutor, etc). Therefore, I am hesitant of adapting our harmony-compliant package to it, as it may not be acceptable by Harmony once we are done. What do you think? As stated above, we've checked with JSR166 (http://gee.cs.oswego.edu/dl/concurrency-interest/index.html ) and we are ok with it, since it complies with the spec. However, I am not sure we can use this as part of Harmony, can we? Daniel
Re: enhanced/classlib/trunk/depends
Mark Hindess wrote: On 3/7/06, Jean-frederic Clere <[EMAIL PROTECTED]> wrote: Well I am complaining the svn contains binary files that could be "easly" rebuild... Should I propose an additional ant target to build those components? Done... (for Linux for the moment), please comment Would you intend for this to be executed as part of the build - e.g. replacing the current zlib unzip step with a download and unzip step? Or as a once only pre-requisite step? My idea is replacing the unzip steps... And I am thinking in other platforms then i386. I'd be a little concerned at the icu "sudo make install" step. You might be overwriting someone's existing install which they might not be expecting. My Debian install already has icu in /usr and adding different version in /usr/local is just going to lead to problems since other applications will be expecting the version in /usr but might - due to /usr/local/bin/icu-config being first in the path - get the harmony installed version. Agreed, sudo is just a quick hack, there are 2 options: - check for existing and if not found build and install it. - install in a local directory (like $HOME/install). Long term, I'd like to see the dependencies use existing installed versions of packages where possible. For instance, making use of zlib that is a standard component of all major linux distributions. (I have a patch to remove zlib from the linux natives already if anyone cares. I don't think it really helps unless we also fix the windows story.) In the short term, the current setup is simple and helps control differences, which avoids confusion that may be created by picking up different versions of these dependencies. Regards, Mark. -- Mark Hindess <[EMAIL PROTECTED]> IBM Java Technology Centre, UK.
Re: Component status pages
Hey - looks great Nathan! I'll tidy up the JLM one to look similar Paulex - it looks to me as though you could create a similar page for the NIO, is that right? Vladimir - is it you who is mainly looking at security? How about a similar page on what you are doing? Nathan Beyer wrote: -Original Message- From: zoe slattery [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 07, 2006 7:50 AM To: harmony-dev@incubator.apache.org Subject: Component status pages (was:Re: any donations expected for awt and swing?) Tim Ellison wrote: Geir Magnusson Jr wrote: Tim Ellison wrote: Probably best to put the 'concerted work in progress' description on the wiki, so anyone can join in; the website status page was intended to be more of a current state of the code overview. We should also start to set ourselves some goals, in terms of applications to run, etc. Why not have "started" on the webpage, and then a like to the wiki page if there is one? Or just encourage people to ask here on the dev list... Yes, that would be fine. If somebody wants to hack the wiki for module status pages, I'll volunteer to point to the website to them. To start with (because it is easier for people to update) I've replicated Tim's table on the Wiki (here:http://wiki.apache.org/harmony/component_development_status). I've linked one component (j.l.mangement) to a seperate page and marked it as "started". How about other people marking up the areas that they are working in? [Nathan Beyer] I added a LUNI page [1]. I've been trying to implement and stub out all of the missing Java 5 stuff, so I've put some of my information up there. [1] http://wiki.apache.org/harmony/LUNI Regards, Tim If you want to make a start on the wiki page that would be good, or if anyone else has an idea for tracking intent... It's also worth mentioning that I don't believe we should be exclusive about areas of work within, and contribution to, Harmony. Absolutely. While I understand that the goal is to minimize redundant work, we may find ourselves in the situation of having more than one implementation of the same APIs (we already saw this happen with 'security' and 'security2' contributions). This is no bad thing as it allows us to evaluate the best technical option (quickly) and proceed with the combined group of experts collaborating on a single code base. I hope we can continue to do so 'harmoniously'. Choice and competition is good. This isn't "live or die" competition, but "we can choose best of breed" competition, and we all benefit. There are no losers. geir Regards, Tim karan malhi wrote: Hi, I am writing the interfaces for the javax.accessibility package. Some of the interfaces are dependent on classes from the awt package. Are we expecting any donations for awt, swing packages? If donations are not expected then what approach should I take? Should I start writing stuff for awt and swing (on which accessibility depends on) so that accessibility classes compile during a build in harmony? Please guide me here. Secondly, once a volunteer starts working on a "Missing" module as stated on http://incubator.apache.org/harmony/subcomponents/classlibrary/status.html , should the status be changed to something else like "Work in progress" or something?
[classlib] modular builds
I've started to lay down some build scripts within each module for people who use the command line (as opposed to Eclipse) for development. These 'module builds' assume that you have a working Harmony JRE in the deploy/jre directory, and the associated VM overlaid. Steps for this 'bootstrapping' build should be familiar, and are described on the website[1]. Once you have the initial Harmony JRE built you can work in a single module and compile (using the Harmony JRE & Eclipse compiler) and test changes to just that module. So, for example, if I want to work in NIO, I can 'cd' into modules/nio and hack on the source code and tests in there, compile the NIO code by typing 'ant' in modules/nio/make, and test by typing 'ant test' in that same dir. NB: The compile step replaces the nio.jar in the deploy/jre/lib/boot directory (so if you really screw up you'll have to revert and run the global build again!) [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/build_classlib.html Regards, Tim p.s. it is still a work in progress -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: Location of ResourceBundle classes for javax.accessibility.AccessibleBundle
That package name looks good -- thanks Karan. (sorry for the slow response) Tim karan malhi wrote: > Since nobody objected to this package structure, I will just assume the > package to be org.apache.harmony.accessibility.internal > > Paulex Yang wrote: > >> I'm not sure myself, but I personally think that is fine. >> >> There is also a "Resources" directory in every source folder, I have >> no idea what it is used for. Anyone can help? >> >> karan malhi wrote: >> >>> Thanks Paulex, >>> >>> What about ResourceBundles specific to a package like for example >>> javax.accessibility. Should we put the ResourceBundles in >>> org.apache.harmony.accessibility.internal ? >>> >>> Paulex Yang wrote: >>> Karan, karan malhi wrote: > Hi, > > The javax.accessibility.AccessibleBundle class requires a default > ResourceBundle. > > 1. Which package would we put the default resource bundle classes in? Currently the resource bundles are located in http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/org/apache/harmony/luni/internal/locale/ I think the classes without locale in its name is default bundles, for example, "Country" is a default one. > 2. What locales are supported by Harmony? try java.util.Locale.getAvailableLocales() :) >>> >> >> > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: enhanced/classlib/trunk/depends
On 3/7/06, Jean-frederic Clere <[EMAIL PROTECTED]> wrote: > > Well I am complaining the svn contains binary files that could be > "easly" rebuild... Should I propose an additional ant target to build > those components? > Done... (for Linux for the moment), please comment Would you intend for this to be executed as part of the build - e.g. replacing the current zlib unzip step with a download and unzip step? Or as a once only pre-requisite step? I'd be a little concerned at the icu "sudo make install" step. You might be overwriting someone's existing install which they might not be expecting. My Debian install already has icu in /usr and adding different version in /usr/local is just going to lead to problems since other applications will be expecting the version in /usr but might - due to /usr/local/bin/icu-config being first in the path - get the harmony installed version. Long term, I'd like to see the dependencies use existing installed versions of packages where possible. For instance, making use of zlib that is a standard component of all major linux distributions. (I have a patch to remove zlib from the linux natives already if anyone cares. I don't think it really helps unless we also fix the windows story.) In the short term, the current setup is simple and helps control differences, which avoids confusion that may be created by picking up different versions of these dependencies. Regards, Mark. -- Mark Hindess <[EMAIL PROTECTED]> IBM Java Technology Centre, UK.
Re: luni test script tweaks
Geir Magnusson Jr wrote:
> So compare these two... First as is now in SVN :
>
> http://people.apache.org/~geirm/test_report_alltests/html/
>
> And as it was in SVN (I just locally reverted the build.xml in
> luni/common/ to do this...)
>
> http://people.apache.org/~geirm/test_report_indiv/html/
>
> The latter has more information. It lets you view by package, and by
> test class, which is a useful unit of measure. It also churns out more
Yes, much better -- I'll undo the undo-undo. Though when I look at the
XML file generated from the suite version it *does* include all that
class info too:
...
...
but it seems to be lost when generating the html? Why is that?
> We may be able to get the same out of using a test suite, but IIRC, I
> tried a few week ago when I set this up, and wasn't able to... It's
> hard to imagine that there isn't a way...
Yes. Like you said before, it would be good to get the best of both.
At this point I don't see how we can augment the 'dynamic' test suite
generated by Ant's .
Regards,
Tim
>>> [EMAIL PROTECTED] wrote:
Author: tellison
Date: Tue Mar 7 10:08:47 2006
New Revision: 383950
URL: http://svn.apache.org/viewcvs?rev=383950&view=rev
Log:
Use the test suite, and put the results in the reporting dir
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml
URL:
http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml?rev=383950&r1=383949&r2=383950&view=diff
==
---
incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml
(original)
+++
incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml
Tue Mar 7 10:08:47 2006
@@ -1,111 +1,99 @@
-
-
-
-
- -
-
- -
-
->>> -srcdir="${hy.luni.src.main.java}"
-destdir="${hy.luni.bin.main}"
-source="${source.ver}"
-debug="${java.debug.option}">
-
-
-
-
-
-
-
-
- -
->>> manifest="${hy.luni}/META-INF/MANIFEST.MF">
-
-
-
-
- -
-
-
-
-
->>> - destdir="${hy.luni.bin.test}"
- sourcepath=""
- source="${source.ver}"
- debug="${java.debug.option}">
-
-
-
-
-
-
-
-
-
-
-
- ->>> value="../../../../target/test_report" />
-
-
->>> -forkmode="once"
-printsummary="withOutAndErr"
-errorproperty="test.error"
-showoutput="on"
-dir="${hy.luni.bin.test}"
-jvm="${hy.target}/jre/bin/java">
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
- -
- - -
-
-
-
-
+
+
+
+
+ +
+
+ +
+
+>>> +srcdir="${hy.luni.src.main.java}"
+destdir="${hy.luni.bin.main}"
+source="${source.ver}"
+debug="${java.debug.option}">
+
+
+
+
+
+
+
+
+ +
+>>> manifest="${hy.luni}/META-INF/MANIFEST.MF">
+
Re: [jira] Resolved: (HARMONY-178) java.text.DateFormat$Field's contructor may replace predefined consts with new value in cache
It is fine, thank you, Tim.
Tim Ellison (JIRA) wrote:
[ http://issues.apache.org/jira/browse/HARMONY-178?page=all ]
Tim Ellison resolved HARMONY-178:
-
Resolution: Fixed
Paulex,
Thanks for the patches. I added a copyright statement to the test and updated
the test suite.
Applied to TEXT module java.text.DateFormat at repo revision 383878.
Please check that the patch was applied as you expected.
java.text.DateFormat$Field's contructor may replace predefined consts with new
value in cache
-
Key: HARMONY-178
URL: http://issues.apache.org/jira/browse/HARMONY-178
Project: Harmony
Type: Bug
Reporter: Paulex Yang
Assignee: Tim Ellison
Attachments: java.text.DateFormat.patch, java.text.DateFormatFieldTest.patch
DataFormat$Field will cache some constants to be searched by method
ofCalendarField(int), but the predefined consts should not be replaced.
the testcases is as below:
import java.text.DateFormat;
import java.util.Calendar;
import junit.framework.TestCase;
public class DataFormatFieldTest extends TestCase{
public void test_Constructor2() {
MyField field = new MyField("day of month", Calendar.ERA);
DateFormat.Field realField = DateFormat.Field
.ofCalendarField(Calendar.ERA);
assertSame("Modified calendar field with the same field number",
DateFormat.Field.ERA, realField);
}
static class MyField extends DateFormat.Field {
protected MyField(String fieldName, int calendarField) {
super(fieldName, calendarField);
}
protected String getName() {
return super.getName();
}
}
}
Run on RI 5.0, test case passes.
Run on Harmony, test case fail with message:
junit.framework.AssertionFailedError: Modified calendar field with the same field number
expected same: was
not:
--
Paulex Yang
China Software Development Lab
IBM
Re: How to deal with this kind of serialization compatibility issue?
On Tuesday 07 March 2006 14:38, Geir Magnusson Jr wrote: > This is somewhat terrifying, isn't it? Are there really references to > com.sun.* in serialized API objects? This *has* to be a bug in the > whole spec if so... If you ask me, the serialization spec *is* a bug. There are just two many ways to break serialization compatibility while remaining binary compatible, and that ain't right. -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded & Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369
Re: How to deal with this kind of serialization compatibility issue?
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 example from the JIRA issue that started this thread, refers to "sun.util.calendar.ZoneInfo" yes, and as I mentioned before, the TimeZone is composited by other serializable class, so that all these classes cannot be serialization compatible, feel like something as cancer :( Can we list all the popular applications that exchange by serialized objects and identify which objects do they send/receive? Rather than investigating almost infinite and uncertain(i.e. how to define popular?) applications, I'd like to test all the serializable class in JSE, at least it is a certain and limited set, we can just find all these kind of incompatibilities one by one, and take some actions. Currently, we have three options: 1. let it be, and speak it loudly in Harmony JavaDoc 2. try to compatible with RI, by creating some adapter with RI's serializable class name, i.e. com.sun.*, etc, and the behavior is even not necessarily compatible with RI. we can even separate them all to a new component named as "compatibility", so that it is easily modify them when RI changes its mind and improve. Not sure if it is legally fine. 3. also try to compatible with RI, by maintaining pairs in ObjectInputStream, this approach maybe has less legal risk? (I have no idea in fact.) Any other good ideas? And before all of this, I cannot agree with Geir more - we should make Sun be aware of this issue. Thanks, Mikhail -- Paulex Yang China Software Development Lab IBM
