Re: Component status pages
Zoe, I'm glad to update page for nio-channels component. zoe slattery wrote: 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? -- Paulex Yang China Software Development Lab IBM
Re: jira messages redirected to commits mailing list
Mikhail Loenko wrote: Actually there are important things that are to be tracked in JIRA. For example, questions of being non-compatible with either RI or spec. I personally don't care too much about which mailing list the JIRA issues are sent to, because Thunderbird can handle them easily and well. But I DO prefer to discuss on the mailing list, and JIRA can be used to only reflect the stage or result of the discussion(that's my understanding of status tracking, instead of discussion tracking :-) ), another reason I prefer writing email than commenting on JIRA is email is easier to be used as discussion - it can be read/replied/commented off line, the previous mail can be inline, it can use html format, etc. etc. ;-) . A sample is the JIRA issue 184 about TimeZone serialization compatibility, which itself is a concrete case, and I reply this JIRA to dev mailing list to discuss more common compatibility issue, and when we have some agreement on what to do, I will update the JIRA issue to reflect that. I'm fine in this way. 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. I agree with you that many JIRA issues are not as significant as some others, especially as reference for similar case later, I guess there are already some marker for this purpose, priority/type/component, etc. 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- -- Paulex Yang China Software Development Lab IBM
Re: [jchevm] Harmony Class Lib does Hello World on a GNU Classpath JVM
Weldon Washburn wrote:
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
Hi Weldon,
Well done!
Where did you actually run the test: Cygwin, Linux, or both?
Enrico
Re: Component status pages
I have updated the nio-channels page. Pls. refer to http://wiki.apache.org/harmony/NIO-CHANNELS But there is a very silly question, why several class names, such as FileChannel, CharBuffer, etc, are considered as hyper link automatically, while some other class name, such as Closeable are rendered as plain text? Actually there are no relevant pages available for these names, and I did nothing special to them. Help me! O:-) Paulex Yang wrote: Zoe, I'm glad to update page for nio-channels component. zoe slattery wrote: 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? -- Paulex Yang China Software Development Lab IBM
Re: Component status pages
FileChannel and CharBuffer are consider CamelCase by the wiki software where as names with only one upper case letter are not. Try prefixing them with a '~' character if you wish to prevent the wiki software making them links - e.g. '~FileChannel'. -Mark. On 3/9/06, Paulex Yang [EMAIL PROTECTED] wrote: I have updated the nio-channels page. Pls. refer to http://wiki.apache.org/harmony/NIO-CHANNELS But there is a very silly question, why several class names, such as FileChannel, CharBuffer, etc, are considered as hyper link automatically, while some other class name, such as Closeable are rendered as plain text? Actually there are no relevant pages available for these names, and I did nothing special to them. Help me! O:-)
Re: Component status pages
On Thursday 09 March 2006 11:41, Paulex Yang wrote: But there is a very silly question, why several class names, such as FileChannel, CharBuffer, etc, are considered as hyper link automatically, while some other class name, such as Closeable are rendered as plain text? Actually there are no relevant pages available for these names, and I did nothing special to them. Help me! O:-) Probably because the wiki software considers any word with embedded capitals to be a WikiName, and hence a link to a page of that name within the wiki. You'll have to consult the documentation for the wiki software to find how to work around this feature. (A good candidate for the most annoying thing ever invented, if you ask me). Have fun, Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369
Re: [jchevm] Harmony Class Lib does Hello World on a GNU Classpath JVM
On 3/9/06, Enrico Migliore [EMAIL PROTECTED] wrote: Hi Weldon, Well done! Where did you actually run the test: Cygwin, Linux, or both? I did all the work on Cygwin. I ran out of time for installing vmware and linux on my laptop. Enrico -- Weldon Washburn Intel Middleware Products Division
Re: [jira] Updated: (HARMONY-156) InputStreamReader.getEncoding() and OutputStreamWriter.getEncoding() should return a historical charset name.
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.
2) java/io/OutputStreamWriter.getEncoding().
You probably meant
if (!isOpen()) {
return null;
}
instead of
if (encoder == null) {
return null;
}
since this method returns null if the stream has been closed.
Thanks.
On 3/8/06, Paulex Yang (JIRA) [EMAIL PROTECTED] wrote:
[ http://issues.apache.org/jira/browse/HARMONY-156?page=all ]
Paulex Yang updated HARMONY-156:
Attachment: patch_156.txt
patch_156_test.txt
As no one has better idea than my prior proposal, i.e., save the mapping
between historical name and canonical name, I created the patch for this
solution. The affected package is luni/java.io.
--
Dmitry M. Kononov
Intel Managed Runtime Division
Re: Platform dependent code placement (was: Re: repo layout again)
Time to resurrect this thread again :) 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 of the native-src/win.IA32 and native-src/linux.IA32 directories and combined into native-src/shared. Once completed we will be in a good position to reorganise the code into whatever layout we choose, and refactor the makefiles/scripts to use gmake/ant across both platforms. I dont think previous posts on this thread really reached a conclusion, so Ill reiterate the previous suggestions: 1) Hierarchy of source - two suggestions put forward so far: - Keep architecture and OS names solely confined to directory names. So, for example, we could have: src\main\native\ shared\ unix\ windows\ windows_x86\ solaris_x86\ All windows_x86 specific code will be contained under that directory, any generic windows code will be under windows\, and code common to all platforms will be under shared\ (or whatever name). So when looking for a source/header file on, for example, windows x86 the compiler would first look in windows_x86, then windows, then common. - Alternatively, have directory names as above, but also allow the OS and arch to be mixed into file names. To quote Andreys previous mail [1]: Files in the source tree are selected for compilation based on the OS or ARCH attribute values which may (or may not appear) in a file or directory name. Some examples are: src\main\native\solaris\foo.cpp means file is applicable for whatever system running Solaris; src\main\native\win\foo_ia32.cpp file is applicable only for Windows / IA32; src\main\native\foo_ia32_em64t.cpp file can be compiled for whatever OS on either IA32 or EM64T architecture, but nothing else. Files will be selected using a regex expression involving the OS and arch descriptors. This is intended to cut down duplication between source directories. Personally I prefer the first system as it is simple to maintain, keeps file names consistent and concise and allows developers to easily keep track of function location. For example, as Graeme pointed out in [2], the developer will always know that hyfile_open() is defined in hyfile.c. In addition, I don't believe that the second system will give us much of a decrease in the number of duplicated files. For example, if a piece of code is unique to only linux and windows on x86, will the file be named foo_linux_windows_x86.c? How will the build scripts be able to determine whether this means all linux platforms plus windows_x86 or windows and linux only on x86? In these cases we will either end up duplicating foo_x86.c in the windows and linux directories or creating an extra directory called x86 which contains foo_windows_linux.c. Potentially we will either get similar amounts of duplication, or more directories than the first method, and because there is no hard rule on the layout (you can choose directory or filenames to include OS/arch) there is no guarantee where a developer will choose to put their code in these situations. 2) Build tools - there have been two previous suggestions: - Use gmake and VPATH to complement the first layout described above. This could lead to platform independent makefiles stored in the shared\ directory of each module that include platform specifics (such as build file lists, compiler flags etc) from a centralised set of resources. - Alternatively, use Ant to select the set of files to be compiled by employing regex expressions. This sits well with the second layout described above (although could also be applied to the first) and a regex expression has been described by Nikolay in [3]. I prefer the use of gmake here. We can use generic makefiles across platforms and pointing the compiler at the right files in the first layout above is as easy as setting VPATH to, for example, windows_x86:windows:shared. I think that complex regex expressions will be harder to maintain (and initially understand!). Opinions? Once we agree on ideas, perhaps we could put together a Wiki/website(?) page describing layout, tools and a list of OS/arch names to use. Oliver Deakin IBM United Kingdom Limited [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/[EMAIL PROTECTED] [2] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/[EMAIL PROTECTED] [3] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/[EMAIL PROTECTED]
Re: Which applications run using Harmony classes?
Hi Nathan Nathan Beyer wrote: Have you tried putting Xerces, Xalan and the xml-commons JARs in the bootclasspath? I believe the intent is to use that for the JAXP code anyway. No and yes. I haven't because I wasn't actually trying to run Tomcat with Harmony classes, I was just using the IBM SDK to see what classes Tomcat loads (whilst doing a few basic tasks) and then work out which of them we don't have in Harmony. You are completely right about the Xerces and Xalan ones, I don't expect them ever to be in Harmony SVN. Perhaps I should have taken them off the list. The reason for looking at class loads like this is that I think it gives us a good idea of what it's worth trying to run now and what should be left until we have a more complete implementation. Does this make sense? -Original Message- From: zoe slattery [mailto:[EMAIL PROTECTED] Sent: Monday, March 06, 2006 3:25 AM To: harmony-dev@incubator.apache.org Subject: Re: Which applications run using Harmony classes? I like Mark's answer best! Back to the subject though - I've updated the wiki (here http://wiki.apache.org/harmony/Apache_Tomcat) with the list of API classes that Tomcat loaded that aren't in SVN. Having Harmony-39 and Harmony-88 in SVN will make this list a lot shorter :-). Geir Magnusson Jr wrote: Mark Hindess wrote: On 03/03/06, Tim Ellison [EMAIL PROTECTED] wrote: What is 'perl' ? (answers in 15 words or fewer) What you choose when you want to code something useful in 15 words or fewer? A write-only, self-obfuscating programming language that relies on punctuation and side effects.
Re: enhanced/classlib/trunk/depends
Jean-frederic Clere wrote: 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? The README.txt contains the link to the ICU4J home where the binary jars may be downloaded from. You can also pick up source and build instructions from there if you want. Building the icu4j jar should not have to be done for Harmony. Best regards, George 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: How to deal with this kind of serialization compatibility issue?
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 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. Hi Paulex, To restrict the scope of the set of serializable types to be compatibility tested we could start by looking for those that are abstract types which get instantiated via factory methods. The abstract class java.util.TimeZone is a perfect example while concrete type java.util.SimpleTimeZone does successfully serialize/de-serialize across Harmony and the RI. Such a testing effort still sounds pretty daunting though. 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. Interestingly enough, the RI Javadoc specification for the java.util.TimeZone factory method does contain the telling phrase the source of the default TimeZone may vary with implementation. Sure, on its own that may not emphasise that a user could hit serialization/de-serialization problems if working across different implementations - but it hopefully does serve to alert users that the type of JRE does matter when invoking that method (and perhaps writing mission-critical applications that rely on storing the returned object in serialized form is not a great idea). At a very minimum, the quoted RI Javadoc (and equivalents throughout the rest of the Javadoc files) should be expanded to explain the potential serialization issue when a concrete type depends on the JRE. Best regards, George Thanks, Mikhail
Re: [jchevm] Harmony Class Lib does Hello World on a GNU Classpath JVM
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 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: Wow! Impressive achievment very cool. 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. Classpath supplies its own native methods for file I/O. That is, you can implement file I/O normally using normal native methods. This is not something the VM needs to be directly involved with. So the fix would be for classlib to implement this itself. There's no reason you couldn't write a gnu.classpath.Pointer class if you wanted to. There's no copyright on the package name :-) By the way jchevm's Thread.setPriority() doesn't work because I don't know how to implement it using POSIX. 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. This is use as part of the NIO implementation for direct buffers. A Pointer object simply contains an int or long that holds a void *. One last item. I don't know which SVN repository to place this work in. Any suggestions? You could create a branch of classlib in the sandbox. Cheers, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [jchevm] Harmony Class Lib does Hello World on a GNU Classpath JVM
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 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: Wow! Impressive achievment very cool. 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. Classpath supplies its own native methods for file I/O. That is, you can implement file I/O normally using normal native methods. This is not something the VM needs to be directly involved with. So the fix would be for classlib to implement this itself. I suspected this. But I could not figure out how to add a new entry into _JC_LIB_ENTRY. I tried but got a bunch of misc error messages so I gave up. If you give me some hints on how to add enties to _JC_LIB_ENTRY, I will take a second stab at it. There's no reason you couldn't write a gnu.classpath.Pointer class if you wanted to. There's no copyright on the package name :-) I just now wrote an Apache Harmony version of java.lang.Pointer and java.lang.Pointer32. It works fine. I put it in the Harmony/modules/kernel/src/main/java/java/lang directory. It can be move to another place and re-packaged once we figure out where it should go. By the way jchevm's Thread.setPriority() doesn't work because I don't know how to implement it using POSIX. 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. This is use as part of the NIO implementation for direct buffers. A Pointer object simply contains an int or long that holds a void *. One last item. I don't know which SVN repository to place this work in. Any suggestions? You could create a branch of classlib in the sandbox. Tim Ellison, Geir Magnusson, I could create a ClassLib branch in the sandbox and call it kernel_path. It would only contain the generic files needed to glue a GNU ready JVM to Harmony Class Lib. Thoughts? Cheers, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com -- Weldon Washburn Intel Middleware Products Division
RE: ITC's Contribution
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-: - SG CCLA (http://www.apache.org/licenses/cla-corporate.txt ): Signed by the CEO of ITC. The CCLA should list the team leaders as authorized contributors - Bulk Contribution Checklist (http://incubator.apache.org/harmony/bulk_contribution_checklist.txt): One for each package, signed by the team leader, and specifying the list of developers (authors) - ICLA (http://www.apache.org/licenses/icla.txt): One for each person designated as authorized contributor (or should it be one for each author?) - ACQ (http://incubator.apache.org/harmony/auth_cont_quest.txt ): One for each person designated as authorized contributor (or should it be one for each author?) Is this ok? where should we send this documents? Thanks, -Mensaje original- De: Tim Ellison [mailto:[EMAIL PROTECTED] Enviado el: Lunes, 06 de Marzo de 2006 01:54 p.m. Para: harmony-dev@incubator.apache.org Asunto: Re: ITC's Contribution Iris Gastañaga wrote: Hi all, On behalf of ITC (Cordoba Institute of Technology)from Argentina.I want to offer a code contribution of the following packages: - java.math(led by Daniel Fridlender) - java.crypto (led by Miguel Montes) - java.rmi (led by Daniel Gándara) Last year the ITC decided to start a clean-room java package development project; now we are proud to make this donation and we hope it be accepted as a valid contribution (which we believe it is). That is fantastic Iris! thanks. Having said this, I do have a few questions: a) Next Steps? which are the next steps? we have read the contribution policy and we are ok with that; we'll send aditional questions regarding documents to be signed on a separated email. We can help with a quick overview of the contribution requirements for acceptance -- that would be the logical next steps. Looks like the other questions have been pulled out into separate threads, so let's deal with them there. Regards, Tim b) Harmony 1.5? we have developed J2SE 1.5 compliant/dependant packages -following the specs of harmony project-; but we see that currently Harmony is not 1.5 but 1.4. Is there an schedule or plan to get Harmony J2SE 1.5? c) Some still missing components... we have checked some pre-conditions before making this announcement and we found that there are some components we need (i.e.: concurrent) which are not on Harmony yet. Is someone working on those missing components? we'll be waiting for comments, Sincerely, Ing. Iris Gastañaga -- Executive Director Instituto Tecnológico Córdoba Córdoba Business Tower, Piso 15 Tel: +54 (351) 5710022 / 23 www.fitc.unc.edu.ar --- PS: we will send mails with specific package information. PS1: we do know that java.math and java.crypto have already been donated, but we do believe our code is a valid donation. PS2: for each package we have developed a set of test cases (public api) that we are willing to donate too. -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: [jchevm] Harmony Class Lib does Hello World on a GNU Classpath JVM
Weldon Washburn wrote: Classpath supplies its own native methods for file I/O. That is, you can implement file I/O normally using normal native methods. This is not something the VM needs to be directly involved with. So the fix would be for classlib to implement this itself. I suspected this. But I could not figure out how to add a new entry into _JC_LIB_ENTRY. I tried but got a bunch of misc error messages so I gave up. If you give me some hints on how to add enties to _JC_LIB_ENTRY, I will take a second stab at it. You would not modify that code (or any other part of jchevm) at all. Instead, you'd build a JNI native library as part of classlib and then load in your Java code it via System.loadLibrary(). This is just the usual Java code with native library pattern. The _JC_LIB_ENTRY() stuff is only for native methods that are provided by jchevm itself, e.g., java.lang.VMThread.start(), Runtime.gc(), etc. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Component status pages
Or stop using the [EMAIL PROTECTED]@ wiki for documentation... :D Patches for website welcome! geir Mark Hindess wrote: FileChannel and CharBuffer are consider CamelCase by the wiki software where as names with only one upper case letter are not. Try prefixing them with a '~' character if you wish to prevent the wiki software making them links - e.g. '~FileChannel'. -Mark. On 3/9/06, Paulex Yang [EMAIL PROTECTED] wrote: I have updated the nio-channels page. Pls. refer to http://wiki.apache.org/harmony/NIO-CHANNELS But there is a very silly question, why several class names, such as FileChannel, CharBuffer, etc, are considered as hyper link automatically, while some other class name, such as Closeable are rendered as plain text? Actually there are no relevant pages available for these names, and I did nothing special to them. Help me! O:-)
Re: How to deal with this kind of serialization compatibility issue?
Geir 2006/3/7, Geir Magnusson Jr [EMAIL PROTECTED]: I see it as an opportunity. :) We should ask Sun what to do they are the go to people for compatibility questions, right? Does it mean that you will ask Sun? :) Thanks, Mikhail. geir George Harley wrote: Thanks Chris, your experience on this matter is very welcome. Even if it does make me feel a little depressed ;-) Best regards, George Chris Gray wrote: Hi George, I wonder what lessons other class library development teams have learned in this area ? I guess that our experience from Wonka can be summed up as serialization is a PITA. Most of the time the problem can be solved, you just never know where the next one will pop up. We advise our cutomers against using serialization as a way to exchange data between VMs - use XML, use Hessian, use anything except serialization. That goes for RMI too. I guess it's easier for us to take this line in an embedded environment than in the context of, say, J2EE. Good luck, Chris
Re: How to deal with this kind of serialization compatibility issue?
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) we should not do any tricks and create illusion for a user that we know how to deserialize it. Also I don't think that to be compatible means to provide compatible implementation of com.sun.* classes. IMHO, the best we can do in Harmony implementation is not to do the same serialization bug. I mean the following: factory methods of TimeZone class should return instances of SimpleTimeZone class. So Harmony implementation will produce serial form that will be deserializable on any other implementation. However I don't know whether it is possible or not to implement in this way. 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. IMHO, it is not the option. The word 'adapter' is used here only to soften the fact that we have to implement a set of com.sun.* classes. And definitely they won't be compatible. So without them we are not compatible and with them were are not still compatible :-) Why we should do this? 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.) Not quite clear what you mean. Do you suggest changing serialization framework? I mean that if it detects during deserialization, for example, sun.util.calendar.ZoneInfo it will substitute it with o.a.h.util.calendar.ZoneInfo. Right? Thanks, Stepan Mishura Intel Middleware Products Division On 3/8/06, Paulex Yang [EMAIL PROTECTED] 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 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 -- Thanks, Stepan Mishura Intel Middleware Products Division
[jchevm] generic Harmony_Class_Lib/GNU_Classpath adapter is on JIRA Harmony-192
Archie, 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. Thanks Weldon -- Weldon Washburn Intel Middleware Products Division
